AI Agent Access Control: MCP and RFC 8693 for Enterprise LLMs

In 2025 the question was whether to let LLMs into the enterprise at all. In 2026 the question is how to give them the exact right amount of access — enough to actually do their jobs, not enough to exfiltrate the data lake, and with an audit trail that satisfies your compliance team. The answer is an uncomfortable combination of two protocols most security leaders haven't had to think about: Model Context Protocol (MCP) and RFC 8693 OAuth 2.0 Token Exchange.

This post walks through why the naive "put an API key in the LLM's prompt" pattern fails, what MCP gets right and what it punts on, and how RFC 8693 token exchange closes the loop for audit-ready, on-behalf-of agent authorization.

The naive pattern and why it breaks

The first-generation pattern for giving an LLM access to enterprise data is embarrassingly direct. You write a system prompt like "Here's an API key for our data warehouse. When the user asks a question, call these functions to look up information." The key is static. It has the permissions of the service account it was issued against. The LLM decides when to use it.

Everything about this is wrong.

• The key's scope is the union of every possible user's needs. A contractor using the agent gets the same API access as the CEO.
• There's no on-behalf-of chain. The API request shows "service-account-ai-agent" in the audit log, not "Alice asked the agent to do X." When a customer's data gets exfiltrated, you can't tell whose session was compromised.
• The LLM can be convinced to call the API in ways the user didn't want. Prompt injection is a real attack surface; a long-lived high-permission key is the worst thing to hand an agent that can be talked into anything.
• Rotation requires redeploying prompts. When the service account's credential rotates, every running agent's context breaks.

Any enterprise AI deployment that looks like this is one prompt injection away from an incident. The industry consensus as of late 2025 was that this pattern has to die. The question was what replaces it.

Model Context Protocol: the interface layer

MCP is Anthropic's open protocol for connecting LLMs to external tools and data. The spec landed in late 2024 and has become the de-facto interface for agent-to-resource communication by 2026. It defines:

• Resources — data the agent can read (documents, API responses, database rows).
• Tools — operations the agent can invoke (API calls, database writes, notifications).
• Prompts — reusable interaction templates.
• A transport — stdio, SSE, or HTTP — for the agent process to talk to an MCP server that exposes resources/tools/prompts.

What MCP explicitly does not define is authorization. The spec says: "the MCP server is responsible for enforcing access control." In practice that means every enterprise MCP server has had to reinvent the wheel for authentication and authorization — and most have reinvented it badly.

The opportunity: because MCP is a clean interface boundary, you can plug a proper auth layer into every MCP tool call without the agent itself knowing. The agent sends an MCP tool invocation; the MCP server checks a token; the token dictates what tools/resources are reachable. Done right, this gives you per-request authorization without the agent ever seeing a credential.

RFC 8693: the token exchange layer

RFC 8693 is OAuth 2.0 Token Exchange. It defines a grant type where a client presents a subject token (a token representing an identity) and receives back a new token representing a narrowed or delegated identity. The core use case is "I have a token proving the user is Alice; give me a new token that represents an agent acting on Alice's behalf with only read access to her documents."

This is exactly the primitive enterprise AI needs.

The flow for an LLM-powered agent:

1. Alice logs in to the application and receives an OIDC token from the enterprise IdP.
2. Alice asks the AI agent for help. The application forwards her OIDC token to its token-exchange service (e.g., CoreLink).
3. The token-exchange service verifies Alice's token against the IdP's JWKS, asserts subject stability, and matches her identity against a workload template that describes which agents can act on which users' behalf.
4. A new, scoped session token is issued — representing "agent X acting on behalf of Alice, with scopes documents:read and calendar:read, expiring in 15 minutes."
5. The agent presents that session token on every MCP tool call. Each tool invocation is checked against the session's scopes, and each is audit-logged with both the agent identity and the acting-user identity (actor: agent-x; on_behalf_of: [email protected]).

The security property that matters: if Alice can't read the HR database, her agent can't either — even if the LLM gets prompt-injected into trying. The authorization is enforced in the token, not in the agent's prompt.

How CoreLink implements this

CoreLink's POST /oauth/token endpoint speaks RFC 8693 as a first-class grant type. For a SPIFFE subject token (JWT-SVID from a peer identity platform), the flow is:

1. Parse the JWT, extract the SPIFFE ID from the sub claim.
2. Resolve the federation peer by the SPIFFE trust domain; fetch the peer's JWKS.
3. Verify the JWT's signature, issuer, and audience against the peer's JWKS.
4. Assert subject-stability between the preview (pre-verification) subject and the verified claims — prevents swap attacks.
5. Match the verified claims against a registered workload template that describes which external agents can map to which internal NHIs.
6. Auto-register an NHI if one doesn't exist; narrow the requested scopes to the template's allowed scopes.
7. Issue a short-lived platform session token; audit the exchange under AuditActionOAuth2TokenExchange.

The agent receives the session token and uses it on every subsequent CoreLink API call, including MCP tool calls brokered through CoreLink's MCP gateway. Every tool invocation is authorized per-request against the session's scopes and logged with the full on-behalf-of chain. The full token-exchange implementation covers the inbound SPIFFE path; the NHI use-case page has the outbound side (AWS STS, Azure workload federation, GCP workload pools).

What MCP alone doesn't give you

MCP is an interface contract. It doesn't care who is on either end of the connection. Teams that adopt MCP without a proper auth layer end up with agents that can call every tool on every MCP server they're connected to, with no narrowing. That's the new shape of the old naive-API-key problem — just wrapped in a cleaner protocol.

The pattern that closes the gap is: MCP for the interface, OAuth 2.0 / RFC 8693 for the authorization, and an audit backend that captures both sides. MCP servers should require bearer tokens on every tool invocation. Bearer tokens should be exchanged from user tokens via RFC 8693 at session start, with scope narrowing. Every tool invocation should be audit-logged with actor + on-behalf-of + tool + parameters (redacting secrets) + resource + decision.

Prompt injection doesn't go away, but its blast radius shrinks

Scoped session tokens don't prevent prompt injection. An attacker can still convince the LLM to call tools in unintended ways — ask it to summarize Alice's documents, get it to leak information into a visible output, exfiltrate via side channels. But the tools it can call are bounded by the session scope, which is bounded by what Alice herself can do. A compromised agent session is at most as powerful as a compromised Alice session.

This is a defense-in-depth posture, not an absolute defense. Layer it with: structured prompts that mark untrusted input, output filtering for exfiltration patterns, rate limits on sensitive tool invocations, and human-in-the-loop approval for destructive operations. But the token-exchange layer is the foundation. Without it, the other layers are painting on sand.

What 2026 compliance frameworks are starting to ask

The emerging pattern in SOC 2 and ISO 27001 updates for 2026 is: if you deploy AI agents that access customer data, you must be able to attribute every access to (a) the agent, (b) the user on whose behalf it acted, and (c) the scope under which the access was authorized. A bearer token with an on-behalf-of claim in the audit log satisfies this cleanly. A static API key with an agent-service-account identity does not.

The cleanest way to get ahead of this in 2026 is to build the delegation primitives now, before an auditor asks for them. MCP + RFC 8693 + hash-chained audit logs is the combination. It's also, not coincidentally, the combination CoreLink ships today.

Where to start

1. Inventory your AI deployments. Which agents exist? What data and tools do they access? Which identities do they run under?
2. Audit the current authorization story. Is there a single service-account key per agent? A shared API key? On-behalf-of delegation? Most teams find the answer embarrassing.
3. Wrap your MCP servers with a token-checking middleware. Even a minimal bearer-required gate is better than nothing.
4. Set up RFC 8693 token exchange at session start. The agent's access should derive from the user's token, narrowed by policy.
5. Add on-behalf-of to your audit logs. Every agent action in the audit trail should name both the agent and the user it acted for.

The organizations that get this right in 2026 will deploy AI agents the same way they deploy microservices — with proper identity, proper authorization, and proper audit. The ones that don't will have a breach with "AI agent" in the disclosure statement.