Agent to SaaS API Access Patterns Guide: Choosing Service Accounts, Delegation or Per-User Tokens

When an AI agent calls a SaaS API, the credential pattern chosen at build time decides whether one bad prompt reaches one user's data or the whole tenant. SaaS platforms offer three broad ways for software to get in: an identity the agent owns (an app-only service account or bot), tenant-wide delegation where an administrator lets the app act as any user, and per-user tokens obtained through each user's own OAuth consent. Each platform names and configures these differently, so a pattern that is safe on one can be far broader on another. This guide maps the three patterns onto five common SaaS APIs, gives the setting names that narrow each one, and sets out how to choose, roll out and monitor them. It is for identity architects, platform engineers and security reviewers approving agent integrations. For the conceptual comparison of agent-owned and on-behalf-of identities, see AI Agent Service Accounts vs On-Behalf-Of Access; this page goes one level down, into the platforms.

Platforms are listed alphabetically throughout; the order is not a ranking. Platform facts were checked against each vendor's public documentation in November 2026.

Key takeaways

• There are three patterns, not two. App-only identity, tenant-wide delegation (impersonation) and per-user tokens carry very different blast radii; tenant-wide delegation is the one most often granted without a review.
• Effective access is an intersection or a union, and you need to know which. Per-user tokens on Microsoft Graph and GitHub are limited to what both the app and the user can do; Exchange Online application grants add up as a union across Entra ID and Exchange RBAC.
• Scope the resource, not only the permission. Use resource selection (GitHub App repository selection, Exchange management scopes, Salesforce permission sets on the integration user) so an app-only grant covers named data, not the whole tenant.
• Short-lived tokens are available almost everywhere: turn them on. Expiring GitHub user tokens, Slack token rotation and one-hour Google service account tokens shrink the value of a stolen token.
• The token store is the real target. Refresh tokens and client secrets held by the agent platform are what attackers steal, as stored integration OAuth tokens showed in 2025; vault them, monitor their use and plan their revocation.

The three access patterns

Every SaaS integration an agent uses falls into one of three patterns. The labels differ by platform, but the security properties are consistent.

• Pattern A, app-only identity: the agent authenticates as itself (client credentials, a bot token, a GitHub App installation, a Salesforce integration user). Access is whatever was granted to that identity, with no user in the loop. Right for organisational work that belongs to no single person, such as triaging a shared queue.
• Pattern B, tenant-wide delegation: an administrator authorises the app once to act as any user in the tenant, usually by naming the user in a signed assertion. Google Workspace domain-wide delegation and the Salesforce JWT bearer flow with admin pre-authorisation are the clearest examples. The app gets per-user context with no per-user consent, which is convenient and very broad.
• Pattern C, per-user tokens: each user signs in and consents, and the agent receives a token bound to that user (Microsoft Graph delegated permissions, GitHub App user access tokens, Slack user tokens). The agent can do only what that user can do, and only within the consented scopes. OWASP LLM06 Excessive Agency recommends that actions taken for a user run on downstream systems in the context of that specific user, with the minimum privileges necessary.

Platform by platform

Each platform below gets the same treatment: what each pattern is called, the settings that narrow it, and the customer-side configuration to check. These are customer-controlled settings under the shared responsibility model.

GitHub

• Pattern A: a GitHub App acting as itself through an installation access token. GitHub Apps use fine-grained permissions (for example read-only repository contents) and the installing owner chooses which repositories the app can reach. The app is not tied to a user account and stays installed if the installer leaves.
• Pattern C: a GitHub App user access token. GitHub documents that this token "only has permissions that both the user and the app have", and actions show that the app performed them. By default it expires after 8 hours, with a refresh token valid for 6 months.
• Settings to check: keep the "expire user authorization tokens" optional feature on (GitHub strongly encourages expiring tokens); install with "Only select repositories"; prefer GitHub Apps over OAuth apps for agents, because OAuth app tokens do not expire until revoked and reach every repository the user can.
• See the GitHub and GitHub Actions Security Guide and How to audit GitHub Apps and OAuth apps in an organisation.

Google Workspace

• Pattern A: a Google Cloud service account calling APIs with its own identity, for resources shared with it or owned by it.
• Pattern B: domain-wide delegation. A super administrator adds the service account's client ID and comma-separated OAuth scopes under Admin console, Security, Access and data control, API controls, Domain-wide delegation. The app then names a user in the JWT sub claim. Google notes it cannot reach data the impersonated user cannot reach, and that service accounts are not subject to Workspace domain policies such as external sharing restrictions, so apply those rules in the agent's own logic.
• Pattern C: standard OAuth consent by each user, governed by the Admin console app access controls.
• Settings to check: grant only the scopes needed (Google's own advice); keep the JWT exp within the one-hour maximum; prefer keyless service account authentication over downloaded private keys; review apps installed from the Marketplace, which receive their permissions automatically.
• See the Google Workspace Domain-Wide Delegation Security Guide and Google Workspace Security Guide.

Microsoft 365 (Microsoft Graph)

• Pattern A: application permissions (app roles) through the client credentials flow. Only a Privileged Role Administrator or Global Administrator can consent to them, and an app with an application permission can reach any data the permission covers.
• Pattern C: delegated permissions. Effective access is the intersection of the granted scopes and the user's own permissions. Where an agent's API tier calls Graph for a user, the on-behalf-of flow (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, requested_token_use=on_behalf_of) exchanges the incoming user token, whose audience must be the agent's own API; it works only for user principals.
• Resource scoping for Pattern A: RBAC for Applications in Exchange Online assigns roles such as Application Mail.Read with a management scope or administrative unit, and Test-ServicePrincipalAuthorization shows whether a given mailbox is in scope. Grants are a union with Entra ID consent, so remove the unscoped Entra Mail.Read consent or the scope has no effect. Use .Selected style permissions and resource-specific consent where the API offers them.
• See the Microsoft 365 Security Guide, Entra ID Applications and Consent Guide and How to find high-privilege Microsoft Graph application permissions.

Salesforce

• Pattern A: the OAuth 2.0 client credentials flow on an external client app with an assigned integration user. Tokens are issued on behalf of that user with no refresh token; scopes are set on the app, not in the request. Anyone holding the consumer key and secret can get a token, so Salesforce advises rotating the secret periodically and at once if exposed, and calling the My Domain URL.
• Pattern B: the JWT bearer flow with the permitted users policy "Admin approved users are pre-authorized". The JWT sub carries a username and access follows profiles and permission sets. The flow never issues a refresh token, and an optional jti claim lets Salesforce reject replayed assertions.
• Pattern C: the web server (authorisation code) flow, where each user approves the app.
• Settings to check: give the integration user a minimum-access profile plus a dedicated permission set; limit which users are pre-authorised through permission sets rather than broad profiles; send credentials in the Authorization header or POST body, never in query strings.
• See the Salesforce Security Guide and How to review Salesforce connected apps and integration users.

Slack

• Pattern A: bot tokens (xoxb-), which represent a bot tied to an app installed in a workspace and survive deactivation of the installing user. Slack's documentation says bot tokens are "usually for the best".
• Pattern C: user tokens (xoxp-), which act on behalf of a member with that member's access; writes appear as if made by the user. Use them only where the agent must act as the person.
• App-level tokens: xapp- tokens represent the app across all installations; with opt-in rotation they become short-lived xoxe.xapp- tokens that expire after 12 hours.
• Settings to check: request granular scopes only; turn on token rotation for bot and user tokens, noting that Slack states it cannot be turned off once on, so build refresh handling first; move any legacy bot tokens, which use the deprecated umbrella bot scope, to granular bot tokens.
• See the Slack Enterprise Security Guide and Slack Tokens Security Guide.

Choosing a pattern

1. Does the task belong to one user? If the agent drafts that user's reply, reads that user's files or files that user's ticket, use Pattern C. It gives a natural ceiling: the agent can never exceed the user.
2. Does it run with no user present, or across many users? Use Pattern A, scoped to named resources. A shared support inbox is a scoped mailbox, not Mail.Read across the tenant.
3. Is Pattern B being proposed? Ask what Pattern C or a resource-scoped Pattern A cannot do. Accept tenant-wide delegation only with a written owner, the smallest scope list, a user population limited where the platform allows (Salesforce permission sets), and a review date.
4. Does the agent need its own identity visible in the user's token? Where the platform supports it, prefer tokens that record both the user and the acting app. OAuth Token Exchange (RFC 8693) defines an act claim for this; see the OAuth Token Exchange and Delegation Guide.
5. Is the action high impact? No pattern replaces approval. Deleting records, sending external email or changing permissions should pass a human or policy check, see the Human-in-the-Loop for AI Agents Guide.

Small versus large organisations: a small team with one agent and one SaaS tenant can run Pattern C for assistants and one scoped bot for shared work, reviewed quarterly. A large estate needs an agent registry that records, per agent, the platform, pattern, scopes, resource scope, credential location and owner, so that hundreds of grants stay reviewable. See the AI agent registry.

Protecting the credentials each pattern creates

The agent runtime should hold only short-lived access tokens fetched at call time from a broker; refresh tokens and secrets stay in the broker. See the AI Agent Credential Lifecycle and Rotation Guide and OAuth Refresh Token Rotation and Expiry Guide. Agents that reach SaaS through MCP servers should follow the MCP Authorisation Specification Guide, which forbids passing the client's token straight through to upstream APIs.

Implementing and migrating

1. Inventory current grants. Export Google domain-wide delegation entries, Entra ID application permission grants, Salesforce external client apps and integration users, Slack installed apps and tokens, and GitHub App installations. Tag each one used by an agent.
2. Classify each grant as Pattern A, B or C and record the resource scope. Flag every unscoped Pattern A grant on mail, files or CRM objects, and every Pattern B grant.
3. Pilot the target pattern with one agent and a test group: create the scoped app identity or per-user flow alongside the old grant, compare results, and use platform test tools such as Test-ServicePrincipalAuthorization to confirm scope boundaries before cut-over.
4. Cut over and remove the old grant. On Microsoft 365 remove the Entra consent after adding scoped Exchange RBAC; on Google remove the delegation entry; on Salesforce rotate the old consumer secret.
5. Roll back by re-enabling the previous grant from your recorded export, for a fixed window only, with the owner's sign-off. Never leave both grants live after the window.
6. Re-certify agent grants quarterly with the owner, using the inventory from step 1.

Detection and measurement

• Log sources: Google Workspace Admin audit (delegation changes) and token audit events; Entra ID audit logs for consent and app role assignments plus sign-in logs for service principals; Salesforce login history and event monitoring for integration users; Slack audit logs for app installs and token events; GitHub organisation audit log for app installations and permission changes.
• Alert on: a new tenant-wide delegation or application permission grant; a scope added to an existing agent app; an agent credential used from a new network location or outside the agent platform; bulk exports by an integration user; a spike in impersonated users per hour. ATT&CK tracks token theft as T1528 Steal Application Access Token and its use as T1550.001 Application Access Token; added app credentials map to T1098.001 Additional Cloud Credentials.

Common failure patterns

• Tenant-wide grant for a single-user assistant. An email assistant gets Mail.Read application permission or domain-wide delegation for Gmail, so one injected prompt can read any mailbox. OWASP names this a form of excessive permissions.
• Scoping that does not apply. An Exchange management scope is added while the unscoped Entra consent remains, so the union still grants every mailbox.
• Stored integration tokens treated as configuration. In the Salesloft Drift breach, OAuth tokens held by a third-party chat integration were taken from its cloud environment and used to export CRM records from hundreds of customer tenants and read some Google Workspace mail. The customer-side lessons: inventory integration tokens, scope them, watch for bulk exports and revoke after a vendor incident.
• Non-expiring tokens by default choice. GitHub OAuth app tokens, legacy Slack bot tokens or downloaded service account keys left in place for agents, when expiring and rotating options exist.
• Shared integration user across agents. One Salesforce integration user or one bot token serving several agents removes attribution and makes revocation all or nothing. See Shared credentials between AI agents.
• Secrets in the context window. Tokens pasted into prompts, tool output or agent memory can be echoed back to users or other tools.

Framework mapping

Practitioner checklist

• Record every agent's SaaS grants with platform, pattern (A, B or C), scopes, resource scope, credential location and owner.
• Default assistants acting for one user to per-user tokens with the minimum scopes.
• Scope every app-only grant on mail, files or CRM to named resources, and remove any unscoped grant that overrides the scope.
• Allow tenant-wide delegation only with written justification, minimum scopes and a review date.
• Turn on expiring or rotating tokens on every platform that offers them.
• Keep secrets, keys and refresh tokens in a vault or broker, never in the agent's context.
• Give each agent its own app identity or integration user; never share one across agents.
• Alert on new high-privilege grants, added scopes and bulk exports by agent identities.
• Rehearse revoking all tokens for one platform and measure the time taken.

Standards and references

• OWASP: LLM06:2025 Excessive Agency
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• GitHub Docs: Generating a user access token for a GitHub App
• Google for Developers: Using OAuth 2.0 for Server to Server Applications
• Microsoft Learn: Overview of Microsoft Graph permissions
• Microsoft Learn: Role Based Access Control for Applications in Exchange Online
• Salesforce Help: OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration
• Slack Developer Docs: Tokens

Related NHI Mgmt Group resources: Agent Identity and Access Guide · AI Agent Authorisation Guide · Delegation Chains and Attenuated Authority for AI Agents · SaaS and OAuth App Governance Guide