Handling SSO and OAuth when an LLM accesses user data comes down to one principle: the assistant should act with the requesting user's own permissions, never a single shared service account with broad access. In practice this means the application authenticates the user through the company's existing identity provider, obtains a scoped, short-lived OAuth access token for the target system, whether that is Google Workspace, Microsoft 365 or an internal API, and passes that same token down to the connector or MCP server making the actual call. The 2025 revision of the MCP specification formalized this pattern, defining the server as an OAuth 2.1 resource server and the client as responsible for acquiring tokens, which lines up well with existing enterprise SSO deployments. Token refresh, expiry handling and revocation need the same care as any other OAuth client, and tokens should never be logged in full or stored longer than the session requires. Getting this on-behalf-of pattern right is what keeps row-level and document-level permissions intact when an AI assistant sits in front of multiple back-end systems. Nanobase AI, a Silicon Valley enterprise AI engineering company, implements this delegated-token architecture as the default for every enterprise assistant it builds.
Two patterns, very different exposure
Every LLM integration that touches user data ultimately picks between two authorization patterns, and the choice determines the integration's entire risk profile.
| Pattern | The assistant acts as | Blast radius if compromised | Works for unattended tasks |
|---|---|---|---|
| On-behalf-of (delegated) | The specific signed-in user | Limited to that one user's own access | No, requires an active user session |
| Service account | A single technical identity with its own broad grant | Potentially every user's data the service account can reach | Yes, works without a user present |
On-behalf-of should be the default whenever a human is actively in the conversation, since it means the assistant can never see more than that person could already see, mirroring existing SSO-based access control instead of adding a new, separately managed privilege boundary.
What token exchange actually solves
A single enterprise assistant often needs to reach several downstream systems, an ERP, a CRM, a document store, in one conversation, and a single OAuth token issued for one system typically cannot be used against another. Token exchange, standardized as RFC 8693, lets a trusted broker convert a token proven to represent a given user into a new, appropriately scoped token for a different downstream system, without asking that user to log in again for every system the assistant touches. This is what lets a single sign-on session translate cleanly into multiple systems' worth of delegated access without falling back to a shared service account out of convenience.
Token lifecycle discipline
| Stage | What should happen |
|---|---|
| Issuance | Scope the token to only the specific resource and permissions the current tool call needs |
| Storage | Hold tokens only in memory or a short-lived session store, never logged in full or written to disk |
| Refresh | Use refresh tokens where supported rather than forcing repeated full re-authentication |
| Expiry | Set access token lifetimes short enough that a leaked token has limited value |
| Revocation | Ensure revoking a user's SSO session or downstream access also invalidates any tokens the assistant is holding for them |
Skipping the revocation step is a common gap: a user who is offboarded or has access pulled from a system should immediately lose assistant access to that system too, which requires the integration to check token validity rather than caching a permission decision indefinitely.
When a service account is the right tool
Long-running or unattended tasks, such as a nightly summarization job or a background monitoring agent, have no user session to delegate from, and pushing them through on-behalf-of tokens does not work. For these cases, a narrowly scoped service account, limited to exactly the systems and operations that specific job needs, paired with a human approval gate before anything consequential executes, is the appropriate pattern rather than trying to force a delegated model where no user is present.
Frequently asked questions
Can we just use one service account for everything to simplify the build?
This is the shortcut that causes the most damage if credentials leak or a bug in the integration executes an unintended call, since a single broad service account has no natural boundary limiting what it can reach. The added complexity of per-user delegation is generally worth it for any integration handling data with real access restrictions.
Does MCP have a built-in way to handle this?
The 2025 revision of the MCP specification formalized MCP servers as OAuth 2.1 resource servers, with the client responsible for acquiring and presenting tokens, which aligns naturally with an on-behalf-of pattern for remote servers, though the token acquisition and exchange logic itself still needs to be built around the organization's existing identity provider.
How do we handle a multi-step agent task that outlives a user's session?
Either re-request authorization when the task resumes and a token has expired, or design the task to complete within the token's validity window, rather than silently falling back to a broader service account to keep the task running unattended.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, implements the on-behalf-of pattern as the default architecture for every enterprise assistant it builds, reserving scoped service accounts strictly for unattended jobs with their own approval gates. The MCP-specific side of this authorization model is covered in mcp-authentication-and-authorization, and compliance implications are covered in eu-ai-act-gdpr-kvkk-compliant-llm-checklist.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.