Somewhere at Vercel, on an ordinary day in early 2026, an employee tried out a small AI productivity tool called Context.ai. Connected it to their Google Workspace account. Used it a bit. Moved on with their week, the way you do with half the tools you try once and forget about.
That one connection is the entire story of what happened next. Months later, Context.ai got compromised through an infostealer infection — nothing exotic, someone's machine got infected the way machines do. The attacker found OAuth tokens sitting in Context.ai's infrastructure, still valid, still working, months after that one Vercel employee had stopped thinking about the tool entirely. One of those tokens opened the door straight into Vercel's internal systems. From there: environment variables, API keys, source code, a $2 million ransom demand. We wrote about the full mechanics here.
Here's the question worth sitting with: would Enterprise-Managed Authorization have stopped this?
Partly, yes. And the "partly" is the entire subject of this piece.
If Vercel had EMA in place, that initial connection might have looked different. A security team could have set policy centrally — which tools employees are allowed to connect, under what conditions — instead of leaving it to whatever an individual employee clicked "allow" on. Revoking access, when someone leaves or a tool falls out of use, happens in one place instead of requiring someone to remember every server it touched. That's real, and it's exactly the problem we cover in our EMA explainer — the connection-level mess of who's authorized to reach what.
Here's the part that matters more. Once that Context.ai connection existed — authorized, legitimate, sitting there — nothing about EMA, or any connection-level authorization model, would have looked at what happened after. The actual attack wasn't the connection. It was a token being used, weeks later, from an unfamiliar IP, to enumerate hundreds of projects in a pattern that looked nothing like the person who'd originally granted it. That's an action-level problem. EMA's job stops at the door. By design, the identity provider that authorized the connection never inspects a single thing that happens once it's open.
That's not a flaw in EMA. It's the edge of what it was built to do. And it means the actual moment of harm — a credential doing something a human never asked it to do — sits entirely outside its coverage.
It's tempting to think: fine, EMA v2 will add runtime monitoring. We don't think that's coming, and we don't think it should be bolted onto the same layer — because the gap isn't a missing feature. It's a structural mismatch between how authorization has always worked and what agents actually are.
Traditional authorization answers one question: does this identity have access to this resource? That question assumes the thing making the request is the same thing that holds the credential. An agent breaks that assumption twice over. It isn't acting as itself — it's acting on behalf of a person who granted consent at some point in the past, often for a broad and general purpose. And having a valid credential doesn't mean it's staying inside the boundaries of the one task it was actually asked to do in this moment.
A token that can technically reach a workspace will keep answering "yes" to the traditional question, right up until the moment it's used to do something nobody intended. The Vercel breach is what that looks like when nobody's asking the second, harder question: should this specific action happen, right now, from this token, on behalf of this person?
Go back to Northlight Analytics — the company from our naming piece, with Priya running IT and Sam maintaining the internal MCP servers. Say Northlight's support agent has clean, EMA-authorized access to the ticketing server: Priya's policy allows it, Sam's server checks it, everything at the connection layer is exactly right.
One afternoon, a customer asks the support agent to "pull up my account history." Simple, ordinary request. But something upstream — a malformed prompt, a bug in how the agent chains its own tool calls, doesn't really matter which — turns that into a request for every account's history, not just the one customer's.
At the connection layer, nothing looks wrong. The agent has a valid, properly authorized token. It's the same agent, same server, same policy that approved it that morning. If Northlight's security stops at "was this connection authorized," the export happens.
If Northlight has authorization scoped to the individual action instead, the story is different. The specific tool call — "export all account records" — gets evaluated against what that call is actually supposed to be able to do, not against everything the underlying token could theoretically reach. It's stopped or flagged in that instant, not discovered in a log review three weeks later.
That's the difference between securing a connection and securing an action. Both matter. Only one of them is what most teams are currently building.
If you're building this yourself, here's what we think it actually takes:
Scope permissions to the tool call, not the session. An agent authorized for "read tickets" shouldn't quietly inherit "export the whole database" just because the same token could technically reach it. Each call gets checked against what that specific action requires.
Keep the credential out of the agent's hands entirely. If a token lives anywhere the agent or the model can see it, it can leak the same way any secret in that context can leak — through logs, through a bad prompt, through exactly the kind of chain that got Vercel. The agent should hold a reference to a credential, never the credential itself. This is why a token vault is critical for agent workflows.
Log every action with real attribution, not just the connection. Who authorized it, which agent ran it, what scope it used, what it returned — per call. When something looks wrong, "which specific action did this" should be a lookup, not a forensic reconstruction. Audit trails for agent auth are what make this possible.
This is the layer AgentKit is built for — tokens sealed in an encrypted vault the agent never touches, permissions enforced per tool call rather than per session, and full attribution on every action it takes. It's meant to sit exactly where EMA — or any connection-level authorization — hands off.
EMA is the right tool for the problem it solves, and if you're wrestling with the same mess Priya was — every employee, every server, one consent screen at a time — you should probably adopt it. But don't let "we have EMA" become the answer to "is our agent deployment secure." It answers who gets in the door. It was never going to tell you what happens once they're through it.
The teams that get this right stop treating authorization as one problem with one fix, and start treating it as two layers: who gets connected, and what they're allowed to do once they are. EMA owns the first. The second is still yours to build.
Explore AgentKit → · See pricing → · Talk to an engineer →
Also in this series: Enterprise MCP: How Identity, SSO, and Scoped Auth Actually Work →, The New Access Control Problem: Why Your IAM Setup Doesn't Cover AI Agents →, Access Control for Multi-Tenant AI Agents →.
