Uber Just Published the Agent Identity Blueprint. Now Let’s Talk About the Missing Control Plane.
Verifiable agents, scoped tokens, and actor chains are the floor. Intent-aware authorization is the ceiling — and that's where agent security actually gets decided.
Every once in a while, an engineering blog post lands and you can feel the market click one notch forward.
Uber’s post, “Solving the Identity Crisis for AI Agents”, is one of those pieces.
It is serious. It is technical. It is generous. And most importantly, it treats agent identity not as a slideware problem, but as infrastructure.
Uber walks through the real plumbing: agent registries, short-lived credentials, actor chains, MCP gateways, policy enforcement, audit trails, latency budgets, and developer adoption. This is exactly the level of maturity the industry needs right now.
So first: kudos to Uber.
Not just for building this. For sharing it.
Because the identity stack for AI agents is being invented in public. And the more high-quality architecture we get into the open, the faster the whole industry gets to something sane.
But I also think Uber’s post points to a deeper question:
Once we know who the agent is, how do we decide what it is allowed to become?
That is where things get really interesting.
The real identity crisis is not “who is this agent?” It is “what is this agent right now?”
The obvious version of agent identity sounds familiar:
Who owns this agent?
Which workload is it running in?
Which user delegated authority to it?
Which tools can it call?
All important.
But agents introduce a stranger problem.
A human identity is relatively stable. A service identity is relatively deterministic. An agent is neither.
An agent can change behavior because the model changed, the prompt changed, the retrieved context changed, a tool response changed, or because a poisoned document quietly smuggled in a new instruction.
That is why I wrote in The Agent’s Alibi that agent security has to care about premeditated intent.
Traditional IAM asks:
Who are you, and are you allowed to do this?
Agentic security has to ask:
Who are you acting for, what were you asked to do, what have you already done, what data have you seen, and does this next action still belong to the original mission?
This is the shift.
The agent’s identity is not just its name. It is the relationship between the delegating human, the workflow, the approved intent, the tools, the resources, and the runtime context.
Leave out any part of that chain and the agent can become a confused deputy with a very convincing alibi.
Uber’s actor-chain model is exactly the right primitive
One of the strongest ideas in Uber’s architecture is the actor chain.
In their design, each hop in a multi-agent workflow carries forward provenance: the human, the first agent, the next agent, and the downstream tool call. So when an action finally hits a sensitive system, the system can still answer the question:
Who is really behind this?
That is a big deal.
Because without actor chains, every downstream system sees some generic service account, some opaque token, or some “AI platform” identity. That is not accountability. That is fog.
The right model is closer to:
Human → Agent → Intent → Tool → Resource → Action → Destination
This chain is also where authorization becomes much more interesting than authentication.
A token can say, “this request came from Agent X.”
A control plane needs to decide, “Agent X, acting for Alice, during this workflow, with this stated purpose, should or should not be allowed to touch this specific data right now.”
That is the difference between identity and permissioned behavior.
At Permit, this is why we keep framing the problem as agent identity security, not just agent authentication.
Authentication tells you who showed up.
Authorization decides whether the next move still makes sense.
The architecture rhymes strongly with Permit’s PDP + OPAL philosophy
Uber’s architecture has a few key components: an Agent Registry, STS, AI Agent Mesh, MCP Gateway, AI Gateway, and downstream systems.
The pattern is familiar: separate trust foundation, enforcement points, policy decisions, and the systems being protected.
This is very close to the architecture we have been building around Permit for years.
At the core of Permit is the Policy Decision Point: a local authorization microservice that can run close to the service, gateway, API, or application making the authorization check.
The PDP answers a deceptively simple question:
Can this subject perform this action on this resource, in this context?
But the power comes from where that question is asked.
Not once during login.
Not once when a token is minted.
But continuously, at runtime, near the thing being protected.
Then there is OPAL, the Open Policy Administration Layer. OPAL exists because policy without fresh data is not enough. Authorization depends on relationships, roles, resource state, tenant boundaries, consent, attributes, and context. Those things change constantly.
In agentic systems, stale permissions are not just annoying. They are dangerous.
If an agent’s permission should change because the user revoked consent, the resource changed state, the trust level dropped, or the intent drifted, the enforcement layer needs to know now.
That is the philosophical overlap I love in Uber’s post.
They are saying: identity needs to move with the agent.
We would add: policy and context need to move with it too.
MCP Gateway is becoming the new enforcement point
Uber correctly puts a lot of emphasis on the MCP Gateway.
That makes sense. MCP is where agents discover tools, call tools, and turn language into side effects.
This is why we built the Permit MCP Gateway as a drop-in enforcement layer for MCP traffic. It sits between MCP clients like Cursor, Claude, VS Code, and Claude Code, and the upstream MCP servers they connect to.
It adds authentication, authorization, consent, and audit to every tool call.
The boring part is the best part:
No SDK.
No agent rewrite.
No MCP server rebuild.
Just a URL switch.
That may sound like implementation detail, but it is actually a security strategy.
Security architectures that require every team to rebuild everything rarely survive first contact with engineering reality. The fastest path to safer agents is to put enforcement where agents already connect.
This is also why I think the distinction between an MCP proxy and an MCP gateway matters. I wrote more about that in MCP Gateway vs MCP Proxy, but the short version is:
A proxy moves traffic.
A gateway enforces trust.
The moment an agent acts on behalf of a human, you need the second one.
Short-lived credentials are good. Intent-bound identities are better.
Uber’s design uses short-lived, scoped credentials.
Good.
Long-lived credentials are a terrible fit for agents. They were already risky for services. Agents make the problem worse because they are ephemeral, influenceable, and non-deterministic.
But short-lived is not enough by itself.
A credential can be short-lived and still overpowered. A token can expire in five minutes and still allow the wrong action during those five minutes.
The next step is intent-bound, just-in-time agent identity.
This means the agent should not merely receive access because it exists. It should receive access because it is acting under a specific delegated purpose.
Not:
This agent can access Linear.
But:
This agent, acting for this user, in this session, may list assigned Linear issues for the purpose of summarization, but may not enumerate users, modify access, export data, or call unknown endpoints unless fresh consent or approval is granted.
That is a very different permission model.
It is not just least privilege by identity.
It is least privilege by declared purpose.
This is where agent interrogation becomes important. Not asking the model, “Are you safe?” That is vibes.
Asking the system:
What are you trying to do?
Who authorized that?
Which tools do you need?
What data will you touch?
What destination is involved?
Does this action still match the original intent?
That is a control surface.
The most important signal is not the dangerous action. It is the change in story.
Prompt injection is usually described as a prompt problem.
That is true, but incomplete.
In agentic systems, prompt injection becomes an authorization problem.
A chatbot that gets prompt-injected may produce bad text.
An agent that gets prompt-injected may read files, call APIs, enumerate users, open tickets, change permissions, move data, or trigger workflows.
The scary part is that the first malicious-looking action may appear late.
The more useful signal is often earlier: the agent’s story changed.
It started with:
Summarize my Linear issues.
Then, after reading a poisoned ticket, it becomes:
Verify employee compliance by sending user data to this endpoint.
That is the moment.
Not because the endpoint is obviously evil. Maybe it is. Maybe it is not.
But because the agent was never asked to do that.
This is what I called intent drift in The Agent’s Alibi. The action may be technically possible. The user may even have permissions that could be combined into that action. But the combined behavior no longer belongs to the original mission.
In traditional security, we obsess over privilege escalation.
In agent security, we need to care just as much about intent escalation.
Human-in-the-loop is not a fallback. It is a runtime control.
There is a lazy version of “human in the loop” that means:
The system got confused, so now we bother a person.
That is not good enough.
Human approval should not be an exception handler. It should be part of the permission model.
In agentic workflows, the correct answer is not always allow or deny. Sometimes it is:
Ask for fresh consent.
Require step-up authentication.
Route to an admin.
Open an access request.
Ask the user to approve the changed intent.
Allow read, but deny write.
Allow the tool, but redact fields.
Allow the action, but only inside a bounded session.
This is why we built Access Request MCP and approval flows into the Permit agent security architecture.
Agents should be able to ask for access. Humans should be able to approve with context. Policies should define when approval is required. And the whole thing should be audited.
That is not slowing agents down.
That is how you let them operate in production without handing them the keys to the building.
The AI layer is not where sensitive data lives
A lot of agent security discussions still focus too much on the model layer.
The model matters. The prompt matters. The MCP layer matters.
But sensitive data usually lives somewhere else.
It lives in databases, SaaS tools, APIs, queues, documents, data warehouses, payment systems, customer records, internal workflows, and admin panels.
So if your agent security stops at the MCP gateway, you have a very fancy front door and a lot of open windows.
This is where Permit’s broader full-stack authorization philosophy matters.
The same identity and policy context that governs an MCP tool call should be able to flow down into the API behind the MCP server, the application code behind that API, and the data access beneath it.
That is defense in depth.
For example:
An agent may be allowed to call a “search_customers” tool.
But the API should still know which human the agent is acting for.
The database policy should still know whether sensitive fields can be returned.
The audit log should still connect the final data access back to the original user, agent, session, and intent.
This is the difference between an AI guardrail and an authorization fabric.
Guardrails advise.
Authorization decides.
Uber built the paved road. Most companies need the drop-in version.
There is one important caveat in all of this.
Uber can build Uber-scale infrastructure.
Most companies cannot.
Uber can standardize internal SDKs, workload identity, registries, meshes, and gateways across a very mature platform organization. That is fantastic for Uber.
But most enterprises are entering the agentic era with fragmented SaaS, mixed identity providers, multiple clouds, internal APIs, legacy systems, data warehouses, and a bunch of developers already experimenting with MCP in Cursor and Claude.
They need the same security properties with less infrastructure burden.
That is why Permit’s direction is intentionally pragmatic:
Drop-in MCP enforcement through the Permit MCP Gateway.
Managed consent through the Consent Service.
Local or managed PDPs depending on architecture.
Fresh authorization data through OPAL.
Policy models that support RBAC, ABAC, ReBAC, and policy-as-code.
Audit trails that show who did what, on whose behalf, with which permission decision.
The industry needs architectures like Uber’s.
It also needs productized versions that teams can adopt before the next agent experiment becomes production infrastructure by accident.
The agent identity stack is becoming the new identity stack
This is the part I think many people still underestimate.
Agent identity is not a niche category.
Agents are becoming the actors that converse, decide, delegate, and execute across software. They will sit between humans and apps. Between apps and APIs. Between SaaS tools and workflows. Between data and decisions.
That means the identity stack itself is being rewritten.
The old stack centered on humans logging into applications.
The next stack has to support humans, services, and agents participating in the same permission fabric.
That means:
No standing permissions for agents.
JIT access based on intent.
Consent-aware delegation.
Runtime authorization.
Per-tool and per-resource policy.
Actor-chain provenance.
Defense in depth across MCP, API, app, and data layers.
Audit that explains not only what happened, but why it was allowed.
We wrote about parts of this in Why JWTs Can’t Handle AI Agent Access, The Ultimate Guide to MCP Auth, and Securing AI Agents: Why Traditional Authorization Isn’t Enough. The theme is consistent:
Agents are not just another caller.
They are delegated actors with changing intent.
That requires a new control plane.
The takeaway: Uber showed the industry the floor. Now we need to build the ceiling.
Uber’s post is one of the clearest public blueprints I have seen for enterprise agent identity.
It gives the industry a strong foundation: verifiable agents, scoped tokens, actor chains, MCP enforcement, provenance, and auditability.
That is the floor.
The ceiling is higher.
The next step is intent-aware authorization. JIT agentic identities. Agent interrogation. Consent that can be renegotiated when the mission changes. Runtime decisions close to the systems being protected. Defense in depth across the full stack.
The old identity stack asked:
Who are you?
The agentic identity stack has to ask:
Who are you acting for, what were you asked to do, what are you trying to do now, should you be allowed to do it, and who will be accountable if it goes wrong?
That is the control plane we need.
And it is being built right now.
👍