Inside the Firewall: Securing Internal Tools

Internal Deployments: A Unified but Unguarded Domain

Many enterprise AI deployments keep every component behind the corporate firewall: the Identity Provider, the MCP servers, and the tools themselves all operate within a single network boundary. This unified domain of control simplifies identity management, but it does not eliminate the need for robust security. Lateral movement, over-scoped tokens, and implicit trust assumptions are just as dangerous inside the perimeter as outside it.

In Part 3 of this series we focus on how OAuth 2.1 and advanced authorization patterns apply specifically to these fully internal architectures, ensuring that AI agents accessing internal tools are authenticated, authorized, and auditable at every step. We cover 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).

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 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.

OAuth 2.1 consolidates the best of OAuth 2.0, mandating secure defaults like PKCE and eliminating unsafe legacy flows — even for internal systems. 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.

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 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.

Suppose an AI agent has a user's token to call Tool A, but fulfilling the request requires data from Tool B. Instead of the agent directly requesting the user's credentials for Tool B, Tool A itself performs a token exchange — presenting the original user token as a "subject token" to the IdP's token endpoint with the grant type urn:ietf:params:oauth:grant-type:token-exchange, indicating it needs a token for Tool B's audience.

All of this happens behind the scenes — the user doesn't have to re-authenticate or even know that multiple services are involved.

Benefits of Token Exchange

Fine-Grained Access with Rich Authorization Requests (RAR)

While OAuth scopes provide a coarse mechanism to limit what an access token can do, modern applications often need more fine-grained control. A scope like read:documents grants access to every document. OAuth 2.0 Rich Authorization Requests (RFC 9396) address this by allowing clients to describe desired access in detail using structured JSON objects instead of flat scope strings.

RAR introduces the authorization_details request parameter carrying a JSON structure. Each object has a mandatory "type" defining the kind of access, plus fields for specifics:

• locations — resource identifiers (URIs or server endpoints) the client wants to access.
• actions — the operations the client wants to perform (read, write, delete).
• datatypes — the types of data involved or affected.
• identifier — an ID for a specific resource instance (account number, file ID).
• privileges — the level or role of access being requested.

For example, an AI agent needing to retrieve a finance report from an internal file service could send:

{
  "type": "file_access",
  "locations": ["https://files.internal.corp/finance"],
  "actions": ["read"],
  "identifier": "Q4-report.pdf"
}

This tells the IdP exactly what the agent wants: read access to Q4-report.pdf in the finance file repository. The IdP decides (based on policy or user input) whether to allow that specific access, and issues a token constrained to that file and action.

RAR in the Authorization Flow

1. 1
   Agent Sends RAR Details

   The AI agent initiates an authorization request including the authorization_details JSON (rather than or in addition to the usual scope parameter), along with standard parameters like client ID, redirect URI, and PKCE code challenge.

2. 2
   User Authentication & Consent

   The IdP authenticates the user via SSO. It detects the rich authorization details and displays a consent page listing the requested access in detail — e.g. "This AI assistant is requesting read access to Q4-report.pdf on the Finance File Server." Far clearer than a generic scope name.

3. 3
   Token Issuance

   If the user approves, the IdP issues an authorization code which the agent exchanges for an access token. The resulting token carries the rich authorization — as structured claims or a reference to stored details — limited to exactly what was approved.

4. 4
   Accessing the Resource

   The AI agent calls the internal API with this token. The resource server validates the token and enforces the constraints — ensuring the user, file, and action all match what was authorized.

Securing Authorization Flows with Pushed Authorization Requests (PAR)

In a traditional OAuth flow, the client redirects the user's browser to the IdP's authorization endpoint with a long URL containing all request parameters — client ID, scopes, redirect URI, state, and potentially RAR details. This front-channel request can be susceptible to tampering and may expose sensitive details in browser logs. Pushed Authorization Requests (RFC 9126) address these concerns by moving the authorization request from the front channel to a back-channel POST request.

How PAR Works

Instead of immediately redirecting the user with a full query string, the client first opens a direct connection to the IdP's PAR endpoint. It sends all authorization request parameters in an authenticated HTTP POST — a secure server-to-server call. The IdP responds with a request_uri, a short-lived handle to the stored request data.

The client then redirects the user to the IdP's authorization URL with only client_id and the request_uri:

https://idp.internal.corp/authorize
  ?client_id=AI-Agent123
  &request_uri=urn:ietf:params:oauth:request_uri:TX123...

The IdP already has the full details from the prior PAR call, so it proceeds with authentication and consent knowing the request is exactly what the client intended — unaltered in transit. The request_uri is one-time use and typically expires in minutes.

Decoupled Authentication with CIBA

OpenID Connect Client-Initiated Backchannel Authentication (CIBA) is a flow for scenarios where the typical front-channel redirect for user login is not possible or desired. It enables the AI agent to trigger an authentication process without directly involving the user's interaction on the client device. Instead, the user completes authentication on a separate device via an out-of-band mechanism — think of it as "login by push notification."

When CIBA Is Useful

• Hands-free or unattended scenarios: the user initiated an action via voice interface, and the agent needs approval to fetch sensitive data.
• Secure approval for sensitive actions: an AI assistant autonomously attempts a large fund transfer or critical deletion, but policy requires explicit user approval via a separate device.
• Devices with limited UI: internal IoT or kiosk devices without full browsers — the user authenticates on their phone instead.

How CIBA Works

1. 1
   Backchannel Auth Request

   The AI agent sends a request directly to the IdP's Backchannel Authentication Endpoint, including its client credentials, the requested scopes/resources, and an identifier for the user (login_hint, id_token_hint, or login_hint_token). Since there's no immediate user interaction, the client must indicate which user it wants to authenticate.

2. 2
   User Notification

   The IdP validates the request and initiates authentication with the user via a separate channel — typically a push notification to the user's registered authenticator app or device. The user sees: "AI Agent XYZ is requesting access to Resource ABC. Do you approve?" The user then approves (possibly with MFA) on their Authentication Device.

3. 3
   Token Delivery

   The AI agent waits for the outcome. In poll mode, the agent periodically calls the IdP's token endpoint. In ping mode, the IdP calls a pre-registered endpoint on the client. In push mode, the IdP sends tokens directly to the client's backend. Once the user approves, the IdP issues an access token (and ID token). If the user denies or times out, the client receives a failure.

4. 4
   Agent Proceeds with Token

   The AI agent now has an access token representing the user and the requested scopes. It calls the internal MCP tool or API just as it would in a normal OAuth flow — fully authenticated and authorized.

CIBA is the ultimate fallback for trust — if the AI wants to do something and isn't sure if it should, it can fire off a CIBA request to get explicit human approval using standard OAuth mechanisms rather than custom ad-hoc confirmations.

Defense in Depth for Internal AI

Together, these four patterns implement a defense-in-depth strategy for internal agentic AI systems. Each tool access is authenticated with modern OAuth protocols and authorized with the minimum necessary scope and explicit user involvement when needed.

By adhering to OAuth 2.1 standards now, your internal AI integrations are not only secure for today's closed-world deployments, but also laying the groundwork for future expansions — such as federation with external IdPs or third-party tool integrations — which will be tackled in subsequent parts of this series.