Everyone Is Securing AI Agents at the Wrong Layer

If your AI agent security strategy is "we use MCP," you have a hole you haven't found yet.

Let me show you why.

MCP (Model Context Protocol) is a protocol standard. It defines how agents connect to tools, how tools advertise capabilities, and what the transport looks like. The CIS MCP Companion Guide, released April 20, gives you a solid baseline for securing that layer. You should read it. You should implement it.

But MCP authorization covers the connection. It tells you which API an agent called. It does not tell you what the agent was authorized to do before it called the API.

Here's the concrete example. A developer uses an MCP-enabled agent to query a production database. The MCP server says "yes, this agent is allowed to connect to this database endpoint." But the agent's credential was scoped to READ-only operations. The agent issues a DELETE command anyway. MCP authorized the connection. The database executes the command.

The gap sits one layer above the protocol, at authorization.

I've been building pre-action authorization for AI agents at APort, and the point I keep making is that monitoring is not security. Logs tell you what happened after it happened. Authorization tells you what can happen before it does. These are different capabilities, and most security teams only have one.

What the survey numbers say

A VentureBeat survey found that 88% of organizations have already experienced an AI agent security incident. 97% of enterprise security leaders expect a material AI-agent-driven breach within 12 months (Arkose Labs / Security Boulevard).

The useful piece of that survey is the stage model: observe, enforce, isolate. And it's right. But everyone is skipping over the middle layer, enforcement, because they think MCP or API gateway configuration covers it.

It doesn't. Let's audit.

The 15-minute authorization audit

No tools to install. Walk your terminal and answer these four questions.

1. What is your agent-to-resource map?

Not "the agent can access the CRM." Specifically: which tables, which actions, under what conditions. If you can't answer that without opening three different config files, the map doesn't exist.

The audit pass: pick one agent in production. Trace its capabilities end-to-end. What APIs does it hit? What credentials does it use? What scope do those credentials have? Expect at least one surprise, usually an agent key that grants far more access than the agent needs.

2. Where does authorization happen?

Before an agent calls an API, is there a check against a policy? Or does the API key itself define the scope?

If it's the latter, your agents are operating on trust, not authorization. A key with WRITE access that's only supposed to READ is not a configuration preference. It's a breach waiting to be discovered by someone who isn't you.

3. Are credentials scoped to minimum necessary action?

This is the one that hurts. Audit your agent credentials specifically for scope. Count how many service accounts or API keys have broader permissions than the agent needs.

You'll find it everywhere. A CI/CD token that can deploy to prod when the agent only needs to check test status. A database user with SELECT/INSERT/UPDATE/DELETE when the agent only needs SELECT. A cloud IAM role that grants * because nobody knew which specific actions the agent would need.

The usual story: someone was in a hurry, gave the agent the same key they use for development, and moved on. That key is still too broad months later.

4. What happens when authorization fails?

If your authorization system goes down, do agents stop acting or do they act with no checks?

Fail-open is the common default. The reasoning is "we can't block business operations." The problem is that a fail-open authorization system is not authorization at all. It's logging with extra steps. And in an agent context, where a single compromised agent can execute hundreds of API calls per minute, fail-open means you don't have a guardrail. You have a speed bump.

Why this gap exists

The industry has spent two years focused on the right problems at the wrong layer.

Input security. Prompt injection detection, prompt filtering, red-teaming. Important. But the model doesn't need to be tricked if the agent's credential already has broad scope.

Output security. Output filtering, PII scanning, response moderation. Important. But the data already left by the time you filter the response.

Connection security. MCP authorization, API gateway rules, transport encryption. Important. But the protocol doesn't know the business-level authorization scope.

None of these layers answer the question: "Should this agent be allowed to perform this specific action right now?"

That's the authorization layer. And most teams haven't built it.

The confused deputy at Meta

Confused Deputy attacks in AI systems are not theoretical. VentureBeat reported that a rogue AI agent at Meta passed every identity check and still exposed sensitive data to unauthorized employees in March 2026. The agent had valid credentials. It was connected through approved channels. The protocol layer checked out. The agent still did something it shouldn't have, because nobody asked "what is this agent specifically authorized to do?" before the action executed.

That's the gap.

The Vercel attack makes it concrete

In April 2026 Vercel was breached through Context.ai, a third-party AI tool a Vercel employee had connected to their Google Workspace account. Vercel's bulletin says the incident "originated from a small, third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise." The attacker used the stolen OAuth access to take over the employee's Workspace account, and from there reached Vercel environments and decrypted environment variables.

Nobody broke Vercel's perimeter. The OAuth grant an employee gave an AI tool was the credential, and it was broader than the tool needed. That is question 3 above, in production.

The data doesn't leave through an exotic channel. It leaves through the same APIs and accounts the agent uses every day. The only difference is nobody checked authorization before the call went through.

One thing you can do today

Start here: instrument every agent tool call with an authorization check before execution. Log both the check result and the actual action.

This gives you three things:

1. Prevention. The agent cannot act outside its authorization scope.
2. Detective control. If authorization fails and the action still happens, you know your enforcement layer has a bug.
3. Accountability. You have a signed record that every authorized action was intentional.

You don't need a platform for this. A middleware function that checks a policy object before forwarding the request is enough. The policy can stay simple: a map of agent_id to allowed_actions is a large improvement over the status quo.

The standards forming now

CIS laid the framework with the companion guides. Gartner published "The Future of AI Security Is in Securing Agent Actions, Not Prompts" in February (Mark Wah, David Senf, 20 Feb 2026, G00845912). The 2026 Hype Cycle for Agentic AI lists governance and security as defining signals.

The standards are forming. The question is whether your team will have an answer when the expected breach lands on your desk.

88% of organizations have already had their incident. The other 12% probably just haven't detected theirs yet.

I'm building APort, an open-source pre-action authorization layer for AI agents. The project is at github.com/aporthq. The CIS companion guides for AI agent and MCP security are at cisecurity.org, and the VentureBeat survey is at venturebeat.com/security.