Identity in the Three-Party Trust Model
2025-11-05
Every discussion about AI governance eventually lands on authorization, rate limiting, or audit logging. These are important. But they’re all downstream of a more fundamental problem.
If you can’t identify who a request is for, nothing else works.
Two-party vs three-party
In a traditional web application, identity is solved. The user authenticates directly with your backend — usually via a session cookie or bearer token. Your backend verifies the token, extracts the user’s identity, and applies access controls. Two parties, one trust boundary.
AI applications break this model by introducing a third party.
Traditional: User → Backend
↑ identity verified ↑
AI agents: User → LLM → Backend
↑ verified ↑ ↑ ??? ↑
The user authenticates with the LLM (ChatGPT, Claude, a custom agent). The LLM decides to call a tool on your backend. But how does it call your backend?
In most implementations today: a shared API key.
The LLM sends the request with a static credential. Your backend receives it and sees… a valid API key. Not a user. Not a role. Not a scope. Just a key that says “the LLM is allowed to talk to me.”
This is the three-party problem, and it’s the root cause of most AI governance failures.
Why shared API keys fail
A shared API key conflates authentication with identity. It proves that the caller (the LLM) is authorized to reach your backend, but it says nothing about the user on whose behalf the call is being made.
This means:
- Authorization is all-or-nothing. If the LLM has the key, every user gets the same access. An intern and the CFO both reach the same endpoints with the same permissions.
- Rate limiting is meaningless. You can rate-limit the LLM’s key, but you can’t rate-limit individual users. One power user can consume the entire allocation.
- Audit trails are useless. Your logs show “LLM called GET /api/records” — not “Dr. Smith queried patient #12345 via the AI assistant.”
- Budget tracking is impossible. You can’t attribute costs to individuals or departments if every request looks the same.
How identity binding works
The solution is to propagate verified user identity through the LLM call chain. This requires cooperation between the identity provider, the LLM runtime, and the governance layer.
Step 1: The user authenticates. The identity provider (Auth0, Okta, Entra ID) issues an RS256 access token with the user’s identity, roles, and scopes.
Step 2: The LLM forwards the token. When the LLM calls your backend, it includes the user’s access token (not a shared key) in the Authorization header. Both MCP and OpenAI’s Apps SDK support OAuth token forwarding.
Step 3: The control plane verifies. The Agentic Control Plane intercepts the request, verifies the JWT against the identity provider’s JWKS endpoint, and extracts the user’s identity.
Step 4: Downstream layers have identity. With a verified user object on every request, policy enforcement, rate limiting, and audit logging all work correctly — because they know who.
import { identifiabl } from "@gatewaystack/identifiabl";
app.use(identifiabl({
issuer: process.env.OAUTH_ISSUER!,
audience: process.env.OAUTH_AUDIENCE!,
}));
// req.user now contains:
// { sub: "auth0|abc123", email: "dr.smith@hospital.org", scope: "tool:read records:view" }
Identity enables everything else
Once you have verified identity on every request, the other governance layers become straightforward:
Policy enforcement: “Can this user access this tool?” becomes a simple scope check against the user’s token claims.
Rate limiting: Per-user limits, not per-key limits. Each user gets their own allocation.
Budget tracking: Attribute costs to individuals and departments based on verified identity.
Audit trails: Every action is logged with the authenticated user, not an anonymous API key.
Content safety: PII detection and redaction can be scoped — what counts as sensitive depends on who’s asking.
Without identity, these layers are either impossible or meaningless. With it, they’re composable.
The industry is moving this direction
Both MCP and OpenAI’s Apps SDK support OAuth token forwarding. Auth0, Okta, and Entra ID all issue RS256 tokens that can be verified by a third party. The protocol infrastructure is ready.
What’s missing is the middleware layer that verifies, normalizes, and propagates identity across the AI call chain. That’s what an Agentic Control Plane provides.
Start with identity
If you’re adding governance to an AI system, start with identity. Everything else depends on it.
npm install @gatewaystack/identifiabl express