Connecting an AI assistant to Microsoft 365 and SharePoint runs through the Microsoft Graph API, which requires registering an application in Microsoft Entra ID and choosing between delegated permissions, where the assistant acts as the signed-in user, or application permissions, where it acts with its own broader scope. Delegated permissions are the safer default for a conversational assistant because SharePoint's existing site, library and item-level permissions are automatically respected, so the model cannot surface a document the user could not already open. From there, Graph endpoints for mail, calendar, Teams and SharePoint search can be exposed as MCP tools or indexed into a retrieval pipeline for broader question answering across a document library. Microsoft 365 Copilot already covers general-purpose scenarios within Office apps, so a custom integration is most useful when a company needs a specific model, cross-system reasoning beyond Microsoft 365, or tighter control over logging and retention. Nanobase AI, an NVIDIA Inception Program member, builds these Graph-based connectors with delegated auth as the default so assistant access never exceeds a user's existing SharePoint permissions.
Delegated versus application permissions
Every Microsoft Graph integration has to choose between two permission models at registration time, and this choice determines whether the assistant can ever see more than the requesting user could see on their own.
| Permission type | Acts as | SharePoint access | Risk profile |
|---|---|---|---|
| Delegated | The signed-in user | Limited to that user's existing site, library and item permissions | Lower; mirrors existing access controls automatically |
| Application | The app itself, with its own granted scope | Can be granted broad tenant-wide access | Higher; requires careful scope minimization and separate governance |
Delegated permissions should be the default for any conversational assistant, since SharePoint's existing permission structure then does the access-control work automatically, and the model can never surface a document the requesting user could not already open. Application permissions are appropriate mainly for background automation that has no single associated user, and those deployments need their own tighter scope review.
Registration and consent steps
- Register an application in Microsoft Entra ID and record its client ID and tenant ID.
- Request the specific delegated scopes the assistant needs, such as reading mail, calendar or SharePoint content, rather than the broadest available Graph permissions.
- Configure the OAuth redirect flow so users authenticate through their existing Microsoft 365 sign-in, obtaining a token scoped to their own account.
- Have an administrator grant tenant-wide admin consent if the organization requires it for the requested scopes, which is common for anything touching Mail or Sites permissions broadly.
- Test against a real user account with intentionally limited SharePoint access to confirm the assistant respects that boundary before wider rollout.
Graph endpoints worth knowing
Microsoft Graph exposes distinct endpoints for different Microsoft 365 surfaces: mail and calendar under the user's mailbox resource, files and document libraries under SharePoint sites and OneDrive drives, and a separate search endpoint that can query across mail, files and Teams messages in one call. For document-heavy use cases, the SharePoint and OneDrive search endpoints are usually more useful as MCP tools than trying to enumerate every document in a library directly, since search naturally respects the same permission boundaries and scales better than a full listing.
Throttling and pagination in practice
Graph API applies throttling limits that vary by endpoint and tenant, and a chat assistant issuing rapid, repeated calls, for example checking calendar availability across many users, can hit these limits faster than a typical human-driven workflow would. Building in retry-with-backoff logic and batching related requests where the Graph batch endpoint supports it keeps the integration resilient rather than surfacing throttling errors directly to end users. Large result sets are also paginated by default, so a tool that lists SharePoint documents needs to handle continuation tokens rather than assuming a single response contains everything.
Frequently asked questions
Does this replace Microsoft 365 Copilot?
Not necessarily. Copilot already covers general productivity tasks inside Word, Excel, Outlook and Teams using this same delegated Graph access pattern. A custom Graph-based assistant is worth building when the organization needs a specific model, cross-system reasoning beyond Microsoft 365, or tighter control over logging and data retention than Copilot's built-in configuration allows.
Can the assistant see files shared with a user from outside their own team?
Yes, delegated permissions follow whatever the user can already see, including externally shared files or files in libraries they were individually granted access to, exactly matching what they would see browsing SharePoint directly.
What happens if a user's permissions change after the assistant has cached a response?
The assistant should not persist SharePoint content beyond the session unless explicitly designed to, and any caching layer needs to respect a reasonably short time-to-live or revalidate against Graph before reuse, since a user whose access was revoked should not still see cached results from an earlier session.
How Nanobase AI helps
Nanobase AI, an NVIDIA Inception Program member, builds these Graph-based connectors with delegated permissions as the default configuration, so an AI assistant's access to Microsoft 365 and SharePoint content never exceeds what the signed-in user could already reach. Related coverage of the Copilot comparison is in microsoft-copilot-vs-custom-assistant, and OAuth patterns are covered further in sso-oauth-llm-user-data-access.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.