{"id":558,"date":"2025-10-19T17:16:35","date_gmt":"2025-10-19T17:16:35","guid":{"rendered":"https:\/\/codingwithramin.com\/?p=558"},"modified":"2025-10-19T17:23:47","modified_gmt":"2025-10-19T17:23:47","slug":"beyond-manual-indexing-building-intelligent-sharepoint-agents-part-3-delegated-permissions-and-enterprise-security","status":"publish","type":"post","link":"https:\/\/codingwithramin.com\/?p=558","title":{"rendered":"Beyond Manual Indexing: Building Intelligent SharePoint Agents \u2013 Part 3: Delegated Permissions and Enterprise Security"},"content":{"rendered":"\n

In Part 1<\/a>, we explored the fundamental shift from manual SharePoint indexing to Azure AI Foundry’s SharePoint grounding tool. In Part 2<\/a>, we built a complete, production-ready SharePoint agent system with multiple agent types.<\/p>\n\n\n\n

Now it’s time to tackle the most critical aspect of enterprise SharePoint AI agents: proper identity passthrough and delegated permissions<\/strong>. This is where many implementations fall short in real-world scenarios, and where the true power of Microsoft 365 Copilot API’s identity integration becomes apparent.<\/p>\n\n\n\n

The Enterprise Permission Challenge<\/h2>\n\n\n\n

When I implemented my first SharePoint agent using the basic setup from Part 2, I quickly discovered a significant limitation during enterprise testing. The agent was accessing SharePoint using the application’s service principal identity, not the actual user’s identity. This meant:<\/p>\n\n\n\n

    \n
  • Security Risk<\/strong>: Users could potentially access documents they shouldn’t have permission to see<\/li>\n\n\n\n
  • Compliance Issues<\/strong>: Audit trails showed the service account accessing documents, not individual users<\/li>\n\n\n\n
  • Limited Functionality<\/strong>: The agent couldn’t respect user-specific permissions, site access, or department-level restrictions<\/li>\n\n\n\n
  • Enterprise Blocker<\/strong>: IT security teams rejected the solution due to permission bypass concerns<\/li>\n<\/ul>\n\n\n\n

    The solution? Delegated permissions with On-Behalf-Of (OBO) authentication<\/strong> – letting the SharePoint agent act as the authenticated user rather than as a service account.<\/p>\n\n\n\n

    Understanding Delegated Permissions vs Application Permissions<\/h2>\n\n\n\n

    Before diving into implementation, let’s clarify the two permission models:<\/p>\n\n\n\n

    Application Permissions (What We Built in Part 2)<\/h3>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
      \n
    • Agent uses its own identity to access SharePoint<\/li>\n\n\n\n
    • Same access level for all users<\/li>\n\n\n\n
    • Simpler to implement but less secure<\/li>\n\n\n\n
    • Not suitable for enterprise environments with strict permission requirements<\/li>\n<\/ul>\n\n\n\n

      Delegated Permissions (Enterprise-Grade Approach)<\/h3>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
        \n
      • Agent impersonates the authenticated user<\/li>\n\n\n\n
      • Respects individual user permissions<\/li>\n\n\n\n
      • Maintains proper audit trails<\/li>\n\n\n\n
      • Requires more complex authentication flow<\/li>\n<\/ul>\n\n\n\n

        Here’s what happens behind the scenes:<\/p>\n\n\n\n

          \n
        1. User Authentication<\/strong>: User authenticates with device code flow and gets an access token scoped for Azure AI Foundry<\/li>\n\n\n\n
        2. Agent Creation<\/strong>: Azure AI Foundry creates the agent with the user’s context embedded in the token<\/li>\n\n\n\n
        3. SharePoint Access<\/strong>: When the SharePoint grounding tool makes requests, Microsoft 365 Copilot API automatically respects the user’s SharePoint permissions<\/li>\n<\/ol>\n\n\n\n

          Key Insight<\/strong>: We don’t need to explicitly request SharePoint <\/strong>or Microsoft Graph<\/strong> permissions because the SharePoint grounding tool leverages Microsoft 365 Copilot API, which already has access to SharePoint and handles identity passthrough internally. The user’s existing SharePoint permissions are automatically respected.<\/p>\n\n\n\n

          Prerequisites for Delegated Permissions<\/h3>\n\n\n\n

          Beyond the requirements from Parts 1 and 2, you’ll need:<\/p>\n\n\n\n

            \n
          • Azure AD App Registration<\/strong> with delegated Azure AI Foundry permissions<\/li>\n\n\n\n
          • Device Code Flow Support<\/strong> (enable public client flows)<\/li>\n\n\n\n
          • Microsoft 365 Copilot License<\/strong> for each user (still required)<\/li>\n\n\n\n
          • Client Secret<\/strong> for OBO token exchange<\/li>\n<\/ul>\n\n\n\n

            Step 1: Azure AD App Registration Setup<\/h2>\n\n\n\n

            First, we need to configure our Azure AD application to support delegated permissions instead of application permissions.<\/p>\n\n\n\n

            1.1 Update App Registration Permissions<\/h3>\n\n\n\n

            In your Azure AD App Registration:<\/p>\n\n\n\n

              \n
            1. Navigate to API Permissions<\/strong><\/li>\n\n\n\n
            2. Remove any Application permissions<\/strong> for SharePoint<\/li>\n\n\n\n
            3. Select Add a permission<\/strong><\/li>\n\n\n\n
            4. Select APIs my organization uses<\/strong><\/li>\n\n\n\n
            5. Search Azure Machine Learning Services<\/strong> and select it<\/li>\n\n\n\n
            6. Add user_impersonation <\/strong>permission<\/li>\n<\/ol>\n\n\n\n
              \"\"<\/figure>\n\n\n\n
              \"\"<\/figure>\n\n\n\n

              Note<\/strong>: We don’t need SharePoint or Microsoft Graph permissions because the SharePoint grounding tool handles all SharePoint access through Microsoft 365 Copilot API, which respects the user’s existing permissions automatically.<\/p>\n\n\n\n

              1.2 Generate Client Secret<\/h3>\n\n\n\n

              Even with delegated permissions, you’ll need a client secret for the OBO flow:<\/p>\n\n\n\n

                \n
              1. Navigate to Certificates & secrets<\/strong><\/li>\n\n\n\n
              2. Create a new Client secret<\/strong><\/li>\n\n\n\n
              3. Copy the secret value (you won’t see it again!)<\/li>\n<\/ol>\n\n\n\n

                1.3 Enable Public Client Flows<\/h3>\n\n\n\n

                For console applications with device code flow:<\/p>\n\n\n\n

                  \n
                1. Go to Authentication<\/strong> tab<\/li>\n\n\n\n
                2. Under Advanced settings<\/strong>, enable Allow public client flows<\/strong><\/li>\n\n\n\n
                3. Add Mobile and desktop applications <\/strong>platform and then add redirect URI: http:\/\/localhost<\/strong><\/code> (required for device code flow)<\/li>\n<\/ol>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n

                  Step 2: Add MSAL Dependencies<\/h2>\n\n\n\n

                  Add Microsoft.Authentication.WebAssembly.Msal<\/strong> package to your solution.<\/p>\n\n\n\n

                  Step 3: Device Code Authentication Service<\/h2>\n\n\n\n

                  IMPORTANT: Through testing, the correct permission scope for Azure AI Foundry delegated authentication is https:\/\/ai.azure.com\/user_impersonation<\/strong><\/code>. This is the most important configuration detail for success.<\/p>\n\n\n\n

                  Create a new authentication service that works perfectly with console applications:<\/p>\n\n\n\n

                  C#<\/span>