Decide what your AI agents are allowed to do

What changes when AI can act

Until recently, the risk of AI at work was mostly about data going out: what someone pasted into a prompt. Agents add a second direction. They read files, call APIs, open tickets, push code and message other agents, often with the credentials of the person who set them up.

That changes two things. First, mistakes become actions. A model that misreads an instruction no longer just writes a wrong paragraph. Second, the agent takes instructions from content it reads, not only from the person using it. A web page, an email or a tool result can contain text that redirects it.

Where agents get their reach

Most organizations have all five, and most have no inventory of any of them. If that is the starting point, read MCP servers are the new shadow AI surface and Your agents are shadow AI with credentials first.

The risks, as the standards describe them

OWASP's LLM06:2025 Excessive Agency describes the core problem: an LLM-based system can be made to perform damaging actions in response to unexpected, ambiguous or manipulated output. OWASP names three causes: excessive functionality, excessive permissions and excessive autonomy. In practice that means an agent that has tools it does not need, tools that can do more than the task requires, and no one checking before it acts.

The OWASP Top 10 for Agentic Applications, published on 9 December 2025, extends this to systems that plan, keep memory, call tools and act with delegated authority. Its first entry is agent goal hijack: an attacker changing what the agent is trying to do through content the agent reads.

For MCP specifically, the protocol's own security best practices list the attacks implementers have to design against, including:

• the confused deputy problem, where an MCP proxy server lets a malicious client obtain authorization without the user's consent;
• token passthrough, where a server accepts tokens not issued to it and forwards them, which breaks audit trails and controls downstream;
• server-side request forgery, where a malicious server points a client at internal addresses or cloud metadata endpoints;
• local MCP server compromise, where a startup command in a client configuration runs arbitrary code with the user's privileges;
• over-broad scopes, where one stolen token opens every tool.

Controls that work

A system prompt that says "never delete anything" is a request, not a control. The model can be talked out of it by the next document it reads. The controls below sit outside the model, in the path of the call.

1. One route for tool and agent traffic. When every MCP call and agent message passes one point, rules, records and data checks apply in one place. Tools reached around that point are the ones nobody controls.
2. An identity on every call. Know whether a call comes from a person, acting with their own access, or from an agent or service key, acting as no one. The answer decides whose permissions apply and who approves.
3. A rule per tool. Allow, ask first or block, per tool and per team. Reading a ticket and closing it are different tools and deserve different rules. A blocked tool should be hidden from the model, so it is never offered.
4. Approval before changes. Hold calls that create, update, delete or send until a person approves them. Who approves depends on who called: the person themselves, or an administrator or named team for agent keys. This is the human-in-the-loop control OWASP recommends for high-impact actions.
5. Data checks in both directions. Check tool arguments before the call, for personal data and secrets on the way out, and check results on the way back, which is where injected instructions arrive.
6. Limits. Rate limits per tool, budgets per key, and a cap on how long a run can take. A runaway loop then costs a little instead of a lot.
7. A record of every call. Who called which tool with which arguments, what decided it, and what it cost. Without it, an incident review is guesswork.
8. Testing. Attack the agent with its own tools and instructions before someone else does. See AI red teaming.

MCP firewall, AI gateway, agent firewall: what the terms mean

The market uses several names for overlapping things. Roughly:

What matters is which of the five channels a product actually sits in. A gateway that sees model calls but not tool calls can redact a prompt but cannot stop a delete.

How Unseen does it

Unseen's AI Gateway runs in your environment and covers all three kinds of agent traffic: model calls, tool calls over MCP, and agent-to-agent calls over A2A. Callers use an Unseen key or sign in as themselves, and your provider keys stay with Unseen, not in the apps.

• Your organization's MCP servers are offered to AI clients such as Claude Code, Claude Desktop, Cursor, Codex and VS Code through the gateway, for the people and teams allowed to use them.
• Each app has one set of tool rules, followed by chat, agents and AI clients alike: Allow, Ask first or Block per tool, with rules per team. New apps start with approval required for changes.
• Actions that need approval wait for the right person, with alerts in Slack or Teams.
• Blocked tools stay blocked, for chat, agents and coding tools alike.
• Rules decide which outside agents can be called, by whom, and for what.
• Data policies apply to tool calls and agent messages as well as prompts.
• Every model call, tool call and agent message is recorded with who made it, the rule that decided it and the cost.
• Red teaming attacks an agent or app with tests written from its own tools and instructions, mapped to OWASP and MITRE ATLAS.

What a gateway does not see

A gateway controls what passes through it. Be clear about what does not:

• Local MCP servers that a client starts on a laptop do not cross the network as tool calls. Find them with endpoint inventory and shadow AI discovery, and move the ones that matter to a server the gateway offers.
• Agents that call a provider directly with their own key bypass the gateway. Network-level discovery shows which machines reach AI providers, which is how those keys are found.

That is why we pair the gateway with shadow AI visibility: one shows what goes through the controlled route, the other shows what goes around it.