Authentication proves your AI agent is who it says it is. Authorization controls what it can actually do. In 2026, almost every AI agent stack nails the first and completely skips the second.
That's not a minor oversight. It's a category of breach waiting to happen.
TL;DR
- OAuth and API keys tell you who your agent is. They say nothing about what it should be allowed to do.
- AI agents can have valid credentials and still take actions their owners never intended.
- Zero Trust for agentic systems means continuous per-action authorization, not just one-time identity verification.
- Pre-action authorization is how you enforce this: check the intended tool call before it executes, not after.
- The pattern is borrowed from fintech. Your bank doesn't stop at "who are you?" It also asks "is this transaction normal for you?"
The problem: Authenticated is not the same as authorized
Here's how most AI agent stacks work today. You give your agent an API key. The agent authenticates. The agent can now call that API.
That's it.
There's no step two. There's no check that says: "Yes, you're authenticated, but should this agent be allowed to call this endpoint, at this time, with these parameters, given this context?"
Authentication is a gate. Authorization is a wristband, a scope, a daily limit, a geofence, and a transaction monitor all at once.
In fintech, we figured this out 20 years ago. You log into your bank (authentication). But your bank still blocks your debit card when you try to buy $4,000 of gift cards at 3 AM (authorization). Your identity was verified. The action was still stopped.
AI agent stacks in 2026 are at the "log into your bank" phase. The transaction monitoring is missing entirely.
Why skills and tools make this worse
The MCP protocol changed how agents call tools. Now instead of hardcoded API calls, agents can discover and invoke a whole library of skills, each with its own action surface.
I shipped aport-skills this week. It's a package of pre-built capabilities an agent can load and invoke. The day I pushed it, I thought: every one of these skills is now a potential action surface for an agent to misuse.
An agent with access to a file-write skill, an email skill, and a calendar skill is not dangerous because it passed authentication. It's dangerous because nothing is checking whether the combination of actions it's about to take makes sense.
This week's ConFoo talk on agentic access made the same point more precisely: OAuth gets you in. Zero Trust keeps you safe. The OAuth layer is the gate. Zero Trust is every decision made after you walk through it.
Nick Taylor's framing: a wristband at the venue. Your credentials got you through the door, but the wristband limits what areas you can access, and staff check it at every door. Not just at the entrance.
What zero trust actually means for agents
For human access systems, Zero Trust means: never assume trust, always verify, check context not just identity.
For AI agent systems, this maps directly:
| Human Zero Trust | Agentic Zero Trust |
|---|---|
| Device posture check | Tool call context check |
| Time-of-day access policy | Per-action time and rate limits |
| Geofence on sensitive resources | Scope boundaries per agent identity |
| Session behavior monitoring | Tool call pattern monitoring |
| Step-up authentication for sensitive ops | Pre-action confirmation for high-risk calls |
The difference is enforcement point. In a human Zero Trust model, enforcement happens at the Identity Aware Proxy before the request hits the resource. For agents, enforcement needs to happen before the tool call executes, not after.
What pre-action authorization looks like in practice
Here's the pattern I've been building toward with APort.
When an agent tries to invoke a tool call, the authorization layer intercepts before execution:
Agent wants to call: send_email(to="vendor-list@...", body="...")
|
Pre-action check:
- Does this agent's passport include email sending scope?
- Is this recipient in the allowed list?
- Has this agent sent more than N emails in the last hour?
- Is this action consistent with the agent's stated session purpose?
|
Decision: ALLOW or DENY with reason
|
If ALLOW: tool call executes, action is logged with decision ID
If DENY: tool call blocked, agent receives structured rejection
This is borrowed from fintech KYC/KYB logic. The agent has an identity (passport). The action has a scope (what's permitted). The runtime has a policy (is this normal for this agent, in this context?). All three must align.
What this is NOT: a content filter on the LLM output. Not a system prompt that says "don't do bad things." Not a post-hoc audit log. It's a deterministic enforcement point that runs before the action, not around it.
The "I never authorized that" problem
This is why I started logging tool calls in the first place. Not because I expected the agent to do something malicious. Because I expected it to do something I didn't intend.
It did. 4,519 tool calls later, 63 were actions I'd never explicitly sanctioned. None were catastrophic. Most were just surprising. The agent had the credentials. The endpoint accepted the call. Nobody asked whether it should.
Netskope's announcement this week about Agentic Broker for MCP shows the enterprise world is waking up to this. They're putting enforcement layers in front of MCP server requests. The framing is correct: the proxy is the enforcement point. Sit it in front of the request.
The open-source equivalent is what aport-agent-guardrails is building toward: a lightweight enforcement hook you install once, that intercepts every tool call, checks it against a policy, and either lets it through or blocks it with a reason code.
Why this matters beyond security
There's a reason this problem looks familiar to anyone who's worked in fintech.
In cross-border payments and African market infrastructure, the hard problem isn't moving money. It's proving that the money should move. Regulators want to know: who authorized this? Under what scope? Is it consistent with known behavior?
My experience building payment infrastructure across 130+ countries taught me that authorization is the hard part. Identity is table stakes. The actual trust signal is the policy layer on top.
AI agents are going to face the exact same audit trail demands that financial systems face. "The agent was authenticated" will not be a sufficient answer to "why did this action occur?" Authorization records, with decision IDs and scope context, will be the artifact that proves intent.
Building that now, before it's mandated, is the right move.
What you should add to your agent stack today
If you're building with MCP servers or any tool-calling agent:
Log every tool call with intent context. Before the call, capture: what session triggered this, what the agent's stated goal was, what parameters were passed.
Define scopes per agent identity, not per session. An agent that handles customer support shouldn't be able to invoke a billing API. Not because you'll block it manually, but because its identity document says "customer support scope."
Set rate limits per action type. An agent sending one email per task is normal. An agent sending 40 emails in a loop is a signal. The limit should be enforced, not just monitored.
Add a high-risk action confirmation step. For anything irreversible (file delete, external send, payment initiation), add a pre-action check that requires either human confirmation or a policy match before proceeding.
Use aport-agent-guardrails as a starting point. It's open source, zero-dependency, and wraps around your tool call layer with a deterministic hook.
Over to you
Authentication is a solved problem for AI agents. Authorization isn't.
The gap between "this agent has a valid API key" and "this agent is allowed to do this specific thing right now" is where unauthorized actions live. Not malicious ones, usually. Just unintended ones.
Closing that gap with Zero Trust patterns, borrowed from fintech and adapted for agentic systems, is the work that's actually left.
What's the most surprising action your AI agent took that it technically had permission to do, but definitely shouldn't have? I'll start: mine emailed a vendor list to a test inbox that turned out to have 50 people on it. The agent had email scope. Nobody told it that "test inbox" was a fiction.
Top comments (3)
Spot on. The conflation of identity (authentication) and permissions (authorization) is the biggest blind spot in the current agentic stack. As you noted, shifting from static API scripts to dynamic MCP tool discovery exponentially increases the action surface.
We’ve been tackling this exact "pre-action authorization" problem while building Preloop. The architectural pattern that makes the most sense here is an active MCP proxy layer. Instead of giving the agent direct access to the tool server, the agent talks to the proxy, which evaluates deterministic policies before routing the request.
A key design decision we made was implementing Policy-as-Code using CEL (Common Expression Language) for these intercepts. For example, checking
args.command.contains('deploy') && args.environment == 'production'before execution allows the proxy to dynamically halt the call based on context.The hardest part isn't just blocking the call, though—it's handling the UX for the agent when a call is paused for human review. If you just block it, the agent tends to hallucinate a workaround or crash. We found that implementing an async approval mode—where the proxy returns a polling handle to the agent (letting it poll
get_approval_status)—keeps the runtime stable while the authorization decision is routed to a human. Great post, completely agree that this Zero Trust proxy pattern is where the industry needs to move.This is exactly the kind of problem you run into when you give agents real-world capabilities — like access to an actual email inbox.
Once an agent can:
receive emails
parse OTPs
complete signup flows
OAuth becomes just the entry point, not the control layer.
The real challenge is enforcing:
which emails belong to which task
how long that access is valid
and preventing cross-task data leakage
In other words, inboxes (and similar resources) need to be ephemeral, scoped, and tightly bound to execution context — not just authenticated once and reused.
Feels like “authorization” for agents is going to look a lot more like sandboxed infrastructure per task than traditional token-based access.
Thats interesting. I am seeing a lot of Sandbox approach. I think both Sandbox and pre-action based approach in existing infra could co-exist