In Part 3 of our series on deploying agentic AI systems, we focus on securing AI tool integrations inside the firewall. In an enterprise setting, both the Identity Provider (IdP) and all Model Context Protocol (MCP) servers (the AI-accessible tools and APIs) are hosted internally. This unified domain of control simplifies identity management but also demands robust OAuth 2.1 patterns to ensure each internal tool is accessed safely and with least privilege. Building on the OAuth/OIDC fundamentals and internal IdP integration from Parts 1 and 2, we will now explore advanced OAuth 2.1 techniques for fully internal deployments (no external federation yet). These include delegation with OAuth Token Exchange, fine-grained access with Rich Authorization Requests (RAR), secure token issuance via Pushed Authorization Requests (PAR), and decoupled authentication using Client-Initiated Backchannel Authentication (CIBA). We’ll cover both autonomous agent scenarios and human-in-the-loop interactions, illustrating how each pattern applies to AI agents accessing internal MCP tools or APIs.
OAuth 2.1 in a Fully Internal Architecture
In an internal environment, all components—the AI agent (client), IdP, and MCP tool servers—reside within the organization’s network. The AI agent can leverage Single Sign-On (SSO) with the internal IdP, and every tool trusts tokens issued by this IdP. Unlike public integrations, there’s no need for multi-tenant federation or external identity trust here. However, internal doesn’t mean simplistic—strong security and least privilege are still paramount. Modern OAuth 2.1 practices should be followed to protect internal APIs from misuse or over-broad access. OAuth 2.1 consolidates the best of OAuth 2.0, mandating secure defaults like PKCE and dropping unsafe flows. For example, an AI agent that needs user identity should use the Authorization Code flow with PKCE (never the old implicit grant), even if all traffic stays inside the firewall. With the basics in place, we can introduce more advanced patterns to handle complex agent workflows.
Autonomous vs Human-In-The-Loop: Some AI agents operate autonomously (e.g. performing nightly data aggregation) while others act on direct user requests. In a fully autonomous scenario with no user present, the agent can use a machine identity—typically the OAuth Client Credentials flow—to get access tokens as a service. But many agent tasks involve acting on behalf of a user or obtaining user approval for certain actions. In these human-in-the-loop cases, the agent needs to integrate user authentication/authorization into its tool access flow. The following sections cover OAuth patterns addressing both situations:
- OAuth Token Exchange (On-Behalf-Of): Delegating access from one internal service to another, propagating user identity.
- Rich Authorization Requests (RAR): Requesting fine-grained, context-rich permissions beyond coarse scopes.
- Pushed Authorization Requests (PAR): Securing and simplifying the OAuth authorization flow in high-trust internal channels.
- Client-Initiated Backchannel Authentication (CIBA): Decoupling user interaction from the client, enabling out-of-band user auth when needed.
Delegation with OAuth Token Exchange (On-Behalf-Of)
In complex internal systems, an AI agent often needs to call multiple microservices or tools in a chain to fulfill a single high-level request. OAuth Token Exchange, defined in RFC 8693, standardizes a secure delegation flow where one service can exchange an access token for a new token to call another service on behalf of the same user. This is commonly called the On-Behalf-Of (OBO) flow. It allows a resource server (internal API) to act as a client to the IdP, trading the token it received from the AI agent for a new token intended for a downstream API. Crucially, the new token retains the user’s identity and context, but can be scoped specifically for the target service.
How OBO Works: Suppose our AI agent has a user’s token to call Tool A, but fulfilling the request requires data from Tool B as well. Instead of the agent directly requesting the user’s credentials for Tool B (which is impractical), Tool A itself can perform a token exchange. It presents the original user token (now a “subject token”) to the IdP’s token endpoint with a special grant type (e.g. urn:ietf:params:oauth:grant-type:token-exchange), indicating it needs a token for Tool B’s audience. The IdP verifies that Tool A is authorized to act on the user’s behalf, and issues a new access token for Tool B, embedding the user’s identity and appropriate scopes. Tool A can then call Tool B with this token, and Tool B will accept it as if the user made the call (with the scope limited to what Tool B requires). All of this happens behind the scenes—the user doesn’t have to re-authenticate or even know that multiple services are involved.
Token Exchange Flow (OBO) Sequence: The diagram below illustrates a typical on-behalf-of flow in an internal AI tool chain. The AI Agent (client) calls Tool A with the user’s token; Tool A exchanges that token for a Tool B token at the IdP, then calls Tool B and returns the result back to the agent:
Unlock the Full White Paper:
Fill out the form to get in-depth guidance, technical patterns, and deployment insights designed for enterprise architects building secure, scalable identity.