What is the AI last-mile problem?
The AI last-mile identity problem occurs when the identity context established at the front door degrades before it reaches the system actually doing the work. The resource ends up authorizing against a credential such as a virtual key, service account, or shared client, rather than a verifiable chain that shows which agent is acting, on whose behalf, and under what constraint. Least privilege becomes unenforceable at the only place it matters, and every action downstream looks the same in the audit log.
I've had some version of this conversation many times now, with different teams in different industries, and it usually starts the same way. In a bank, an insurer, or any regulated enterprise, developers want to use an AI coding assistant (such as Claude Code or Codex), and the platform team does the smart, obvious thing: They put an AI gateway in front of all of its resources. This gateway provides a place to route to models, enforce budget and rate limits, and broker access to internal tools over the Model Context Protocol (MCP). I understand the instinct behind this, but I can’t help but feel that it is similar to the “service account model” for AI agents, and things tend to get a bit interesting in practice.
Fundamentally, a gateway authenticates a key. It can’t authenticate a person, and by the time a request reaches the actual resource—the internal tool, the data source, or whatever's on the other end—nobody downstream can tell the difference. Fixing that isn't a matter of tightening the gateway's configuration. It means putting a real identity underneath it: the agent gets its own credentials, every call carries the identity of the human behind it, and the resource itself checks those credentials against what that specific person is entitled to. The same agent, the same gateway, and the same code now yield a different answer based on who's actually asking.
Why do AI gateways fail at downstream identity enforcement?
The way most of these gateways work today is that the agent (a coding assistant) ends up holding the key. The agent authenticates to the gateway using that virtual key; the gateway then routes the request to a model or an MCP server.
The problem surfaces at the very end of that chain. Once a request clears the gateway, there's no real way for the resource on the other end to know who's actually behind it. All it sees is the key. Not a person. Not even reliably a specific agent. Just a credential that anyone with access to it could have used that day.
The pattern most teams start with: A developer, a personal AI assistant holding a virtual key, a gateway, and whatever's downstream. Nothing in this chain carries the developer's identity past the gateway.
I have seen a few names for this problem on forums, and the one I have landed on is “the last mile problem.” The gateway gets you most of the way there: it authenticates something (for example, a virtual key) and, at the end of the day, routes to the right resource. What it doesn't do is carry any information regarding identity, entitlements, or authorization. By the time the request reaches the MCP server or the model, the system typically knows nothing about the identity performing the request.
Core security vulnerabilities of key-based AI gateways
- Static credentials as identity: A static key stands in for identity, not a live, revocable assertion of who's behind a request (resembling a service account model).
- Overprivileged access defaults: Access is typically open by default until someone deliberately closes it off.
- Enforcement: The resource has no enforcement ceiling, even when the gateway logs "this key called this tool," because no one in the chain ever asked, "Is this specific person entitled to this specific data?"
This really shows up in an audit. If you ask an AI-forward team who accessed a record or an MCP server, and for what reason, the response will be silence.
The flaw with the gateway as an enforcement point
I don’t believe this is a configuration gap you can close by writing more rules into the gateway. A real decision needs three things at the moment of the call:
- What the agent can do
- What the specific human is entitled to
- What the resource's policy allows
A gateway, by design, only ever has visibility into the first of those, and often not even that, just "someone presented a valid key."
Why does “bolting on” an identity provider fail?
A common next step is to bolt on an identity provider (IdP) and do an on-behalf-of token exchange (provided this is supported), so the agent inherits the user's access token rather than holding its own static key.
The next step is a bolted-on IdP.
This pattern is a step in the right direction, because now you at least know which human logged in. But you end up running into the same last-mile problem, just one layer down: “Which agent invoked this request?” The resource has no way to verify that agent X is legitimately acting on behalf of user Y, and no kill switch to stop it. There is no human-in-the-loop involvement, no way to block that specific agent, and no way to revoke its access. The agent still isn't a first-class citizen in that flow; it's just borrowing the user's identity wholesale. If you've seen any of the "confused deputy"-style incidents that have made the rounds, this should sound more like a risk, not a fix.
But what would a fix look like? We have already established that bolting on an IdP at the gateway level gives you a heading and does not get you to your destination of knowing which user asked which agent to perform which action.
What’s the solution to agentic identity governance?
The answer lies in treating AI agents as first-class identities within your identity and access management framework and tying user and agent authorization checks at the request level, and not at the resource level. At Okta, we deliver this capability with Okta for AI Agents as depicted in the figure below.
The fix: The assistant gets a governed identity of its own. The human logs in once; the adapter performs a token exchange against the identity layer; only an approved, scoped token ever reaches the actual tool.
With this setup, users can authenticate before a request and, more importantly, tie their user-level authorizations (which establish a ceiling on what they can access) to each request they make through that agent. Users can, of course, operate below the ceiling, but they can never go above it. With this model, provided through the Cross App Access specification, we can finally get past the last-mile issues we encounter when deploying and operationalizing AI agents.
How dynamic request-level authorization works
Authentication: The human user authenticates using OpenID Connect (OIDC).
Entitlement scoping: The identity layer evaluates three distinct policies before issuing a token:
Agent authorization: Is this agent permitted to act on this user’s behalf?
Target reachability: Is this agent authorized to access this specific resource?
User entitlement ceiling: What specifically is this user allowed to do with that resource (read/write/touch)?
Token issuance: The system generates a short-lived, single-use bound bearer token that carries the explicit intersection of agent and human permissions.
The intersection does not happen in a single place. As the figure below shows, two authorization points evaluate the actual policy of what the human and agent can access. The AI agent’s first tool call hits the Okta MCP Bridge Adapter, which is responsible for a few interactions. First, it brokers the human login through a standard OpenID Connect (OIDC) pattern. Then, it orchestrates the Cross App Access handshake between the Okta Org Authorization Server (which evaluates the agent’s entitlements and issues the ID-JAG token) and the resource’s authorization server to issue a bound bearer token (which includes both agent AND human entitlements). Only the token that carries the verdict of both the human and agent checks reaches the MCP server.
The mechanics of Cross App Access via Okta for AI Agents. The human authenticates once; the agent requests a short-lived, single-use assertion bound to that human; separate authorization servers evaluate it against policy before issuing a scoped bearer token that the resource can actually trust.
The identity layer computes that intersection before the request ever reaches the resource and returns a token that already carries the verdict. In practice, that means we must ask three questions: First, is this agent allowed to act on this user's behalf? Second, is this agent allowed to reach this resource? Finally, once it reaches the resource, what can it actually do—read one record, read all of them, or write to them?
In this model, the two separate authorization servers are asking these questions. The Okta Org Authorization Server answers the agent question: “Is this agent allowed to act on this user's behalf, and to reach this resource at all?” The resource's own authorization server (which can be Okta or the resource's own) answers the human question: “Given who this actually is, what are they entitled to at this point in time?” Neither check alone is the intersection; the intersection is the scoped bearer token that comes out the other end of both. The resource doesn't have to reimplement these checks for every tool call. It just validates a token and checks a scope.
AI gateway vs. governed agent identity: Feature comparison
| Security and operational capability | Standalone AI gateway | AI gateway + governed agent identity |
|---|---|---|
| Model routing, cost control, and rate limits | Yes, its core strength | Yes, unchanged |
| Tool and data-source scoping | Per key or per team, no user context | Per user, centrally governed |
| First-class, governed agent identity | No, identity is a static key | Yes, a registered, owned identity |
| Verifiable delegation (agent acting for a specific user) | No, the request has a key, not an actor | Yes, every call carries the person who authorized it |
| Credential lifecycle | Long-lived shared keys | Short-lived, per-agent tokens |
| Default access stance | Open by default until someone configures otherwise | Deny by default (least privilege) |
| Agent lifecycle governance | DIY | Managed like any other identity |
Although the gateway is a strong front door for cost and routing, there is no denying it has (pun fully intended) an identity crisis. The decision about who's allowed to see what belongs one layer down, and it must travel with the request all the way to the resource, without terminating at the gateway.
Real-world example: Enforcing entitlement ceilings
Imagine you have an internal bot that can look up salary information. Three different people talk to this same bot: Charlie, a regular employee who should only see their own salary; someone in compliance who's allowed to see everyone's (but not change it); and a CFO who can see and update everyone's. Same bot, same action (kind of), but different people with different ceilings.
Charlie asks the bot, through the gateway, "What's my salary?" The bot returns the correct response, let’s assume $70,000. The issue comes from the follow-up question. Charlie inputs, "What's Alice's salary?" and the bot again returns with the answer.
Nothing among the user, the agent, the AI gateway, or the MCP server ever checked the difference between "as Charlie" and "as anyone holding this key." The gateway performed exactly as the platform team configured it to; they just never configured it to distinguish between them because it can't see the difference.
Now let's put an identity layer underneath that same gateway. Charlie authenticates as himself. Every call is now the intersection of three things: What the agent can ask for, what Charlie is personally entitled to, and what the resource's access policy allows.
When Charlie asks for his own salary, all three requirements line up. When he asks for Alice's, the system denies his request because the middle term in that intersection fails, even if the agent or the gateway would otherwise allow it. If we swap the persona to the CFO, using the same agent, the system allows the request because the CFO has a different entitlement ceiling. The entitlement ceiling travels with the human, not with a key that anyone on the team could use to ask the same question.
Frequently asked questions
I’m asked some version of “Doesn’t our gateway already handle this?” every time.
Remember, a key identifies a caller category, not a caller. It doesn't carry a live, human-bound entitlement you can check at the resource or revoke the moment someone changes roles. Two people sharing a key look identical to everything downstream.
The entire information exchange happens on the back end. The developer still talks to their coding assistant the same way they did yesterday; the authentication and token exchange happen underneath and not in their workflow. If it changes how developers work day-to-day, it was built incorrectly.
I advise against this. Effectively, you create DIY governance for every single tool by whichever team happens to own each tool, forever. It fails to provide you with a single durable, centrally governed identity to audit or revoke. Instead, it gives you multiple slightly different, hand-rolled versions of the same check, and no shared source of truth across them.
Should you replace your AI gateway with an identity layer?
The argument here is not "rip out your gateway." An agent gateway has a place in the IT landscape for what it’s designed to do, such as routing, cost control, rate limits, or tool discovery. It wasn't designed to carry specific user context. That's a different layer, sitting off to the side, evaluating each request on its own terms.
So does that mean everything you've already built needs to go? No. It means the gateway and the identity layer perform two different jobs, and most architectures today pay for only one.
Take control of your AI identity architecture
To solve the last-mile problem, you need a dedicated identity layer that sits alongside your gateway, evaluating every request on its own terms.
With Okta for AI Agents, you can establish a request-level authorization ceiling that travels with the human user rather than relying on a static, standing key. By securing your workforce and developer workflows without introducing developer friction, Okta helps you scale autonomous capabilities with confidence.
Ready to eliminate your gateway’s identity crisis?
Download the blueprint for the secure agentic enterprise to assess your agent security architecture and discover how Okta can help you bring your enterprise AI agents under your control by treating them as first-class identities.
