Choose an AI tool's acting principal before choosing its credential mechanism. A delegated user operation should preserve that user's permitted authority; a scheduled workload may use a dedicated service identity with its own bounded permissions. Record the resource owner, execution principal and revocation path together. A valid cloud token or managed login does not answer which customer account a business action may affect.
Draw the authority chain in ordinary terms
For a synthetic report, name the requester, workspace owner, report worker and storage reader. Under user delegation, removal of the user's membership should affect later operations according to the application's documented revocation checks. Under a workload identity, the worker's permissions exist independently of a particular human session. The product must therefore record the authorizing workflow and permitted tenant scope rather than borrowing the most recent user's identity.
Google Cloud's MCP authentication guidance distinguishes authentication choices by runtime and principal. It recommends granting the agent identity only the required permissions. That cloud guidance applies to Google Cloud MCP resources; it does not automatically govern access to a separate SaaS application's records. Keep the cloud IAM boundary and the application's membership boundary visible in the diagram.
Google Cloud MCP authentication and principal choices
Compare two report contracts
In a delegated workflow, Mira asks for her workspace's permitted report now. The server verifies Mira, resolves membership and performs the read within that authority. In a scheduled workflow, a report worker runs nightly for explicitly enrolled workspaces. Its service identity can call the required dependencies, but application code must still select only enrolled accounts and apply delivery rules. Neither design should trust an arbitrary tenant ID supplied by the model.
| Decision | Delegated user | Scheduled workload |
|---|---|---|
| Who acts? | Verified member | Dedicated service identity |
| Account scope | Current permitted membership | Explicit enrollment contract |
| Removal event | Member/grant lifecycle | Workflow and identity lifecycle |
| Audit fields | Requester and tenant | Authorizer, worker and tenant |
A useful audit record has both requested_by and executed_as where those identities differ. Include the tenant, operation identity and grant reference. Do not copy an incoming token into an unrelated downstream Authorization header. The receiving service must use a credential intended for that resource through an approved delegation or workload mechanism. Keeping token audiences distinct avoids turning the adapter into an implicit authority bridge.
Managed authorization still has an issuer and offboarding policy
Supabase's November 3, 2026 announcement describes Claude-issued enterprise-managed authorization for eligible Supabase organizations. It preserves a member-bound identity rather than turning every request into a universal service account. The published flow has specific organization, SSO and administrative prerequisites, and its offboarding differs from an identity-provider-issued flow. Review those conditions with the organization administrator before changing the trusted issuer.
Supabase: Claude-issued managed authorization, availability and offboarding
This provider example is a reminder to put issuer choice in the design worksheet. A login UI can disappear while the underlying member identity and removal procedure remain critical. Ask which systems must remove the person, when already issued credentials expire, and whether changing the issuer affects other tools. Do not generalize a managed provider feature into a capability of a custom MCP server.
Test the principal model you selected
Use two fictional workspaces and one removed member. For delegation, verify permitted access, crossed-workspace denial and the post-removal behavior promised by your token and membership checks. For a workload, verify the allowed schedule, tenant enrollment and destination restrictions. Also remove a human administrator and prove the scheduled task does not accidentally depend on that person's cached session.
No provider deployment or offboarding experiment is executed here. The table is a proposed authority worksheet. Review logs for identities and operation outcomes, while excluding credential values and report contents. If operators cannot explain who authorized a report and which principal executed it, adding another authentication library will not resolve the ambiguity. Bring that single journey to an integration review before expanding the tool inventory.
MCP server authentication: trace the identity all the way to the record
Evaluate the tool action, not just the answer.
Bring one tool workflow, supported hosts and a sanitized failure trace for a scoped AI integration review.
AptixLabs ai agent development
Should an AI tool use user delegation or a service identity?
Use the principal model that matches the task: member-bound authority for delegated actions, or an explicitly scoped workload identity for independent scheduled work.
Does managed authorization turn users into a service account?
Not necessarily. Inspect the provider’s member mapping, issuer and removal policy rather than inferring the principal from the absence of a consent screen.
Can a service identity ignore tenant checks?
No. Cloud permission to call a dependency does not grant access to every tenant’s application records.