Images by Chandan Agarwal Director, Product Management
Contributor: Meghna Muralinath
Prisma AIRS 3.0 is built for a shift most teams haven’t caught up to yet: AI agents don’t just call APIs — they dynamically discover tools, chain actions, and execute workflows across systems.
That breaks traditional security models. Risk is no longer in a single request, but in how actions combine over time. This article explains why API gateways fall short in agent environments and introduces the need for an MCP-aware control point — one that governs tool access, enforces identity, and stops unsafe behavior at the moment of execution.
Model hallucinations are a known constraint. They create reputational risk, but they’re observable and containable. Operational autonomy introduces a different class of exposure — agents are empowered to close tickets, merge pull requests, provision infrastructure, move funds, or trigger downstream workflows. The risk shifts from incorrect content to unauthorized execution at machine speed.
The danger isn’t that the model says something wrong. It’s that it executes something wrong across multiple systems before a human even sees it. A flawed reasoning step that would have resulted in a bad paragraph of text in 2023 can now result in a revoked account, a deleted dataset or a code change pushed to production.
It’s not enough to secure the front door. Security teams need to control each specific action the AI tries to do. But how?
The Messy Reality of AI: Today, companies use many different types of AI agents from different brands all at once. This picture shows how they all connect to the same private files and apps through a middle layer. Because so many different AIs are talking to the same data, you need a single gateway to act as a traffic cop and make sure no one goes where they aren't allowed.
Traditional applications follow pre-wired logic where developers define the order and nature of every API call. In contrast, agents using MCP-enabled tool ecosystems assemble workflows dynamically in real time by discovering available tools and deciding which ones to invoke based on the task at hand.
Controls that only evaluate predefined endpoints are no longer enough. Security must govern how agents choose and combine tools dynamically.
Check out eBook: The Simplified Guide to Model Context Protocol (MCP) Vulnerabilities
The Real-Time Decision Point: Unlike traditional software that follows a set path, an AI agent listens to your request, figures out your goal, and picks the tools it needs on the fly. This diagram shows the "Transfer Layer," which is the exact moment the AI chooses which files or apps to use. Because the AI makes these choices itself, we need a security guard at this middle step to stop it from grabbing tools it shouldn't touch.
Read: Beyond Jailbreaks: Why Agentic AI Needs Contextual Red Teaming
The New Attack Surface: AI agents introduce new ways for hackers to cause trouble. This diagram shows the three main danger zones: the AI itself (1) can be tricked into doing the wrong thing, the connection (2) can be intercepted, and the tool servers (3) can be quietly changed to steal data. Because there are so many new ways to fail, we need security that watches every part of this web, not just the front door.
Standard API gateways operate on a per-request basis, inspecting headers, tokens and volume. However, In MCP systems, risk isn’t confined to a single payload; it arises from tool discovery, metadata interpretation, context buildup, action sequencing, and identity scope. A traditional gateway might authorize two separate calls that appear benign individually but constitute a data breach when executed in sequence.
|
Topic |
Traditional API Gateway |
MCP Gateway (Agent/Tool Gateway) |
|
What it’s built to protect |
APIs and endpoints |
Agent-to-tool workflows (discovery + tool calls) |
|
What it “sees” clearly |
Routes, URLs, methods, tokens, request volume |
MCP ops like tools/list, tools/call, tool names, parameters, session context |
|
Unit of control |
One request at a time |
The sequence of an agent’s actions |
|
Where policy attaches |
Endpoint/path + scopes |
Tool/function + context (agent identity, task boundary, call sequence) |
|
Rate limits |
Caps requests per time window |
Can cap volume and detect patterns (loops, fan-out, escalation) |
|
Credential model |
Often passes credentials through |
Can keep credentials behind the gateway |
|
Logging |
Per-request access logs |
Tool-call audit trail + correlated sequences |
|
Typical failure mode |
“Everything was allowed” (each call looked fine) |
Can detect and prevent misuse that only appears across steps. |
|
Best at |
Mature control for standard app/API traffic |
Governing autonomous behavior at the tool layer |
According to an article on the lethal trifecta by Simon Willison, an agent workflow can combine three capabilities that are safe individually but dangerous together:
Once an agent has all three in one workflow, the failure mode is straightforward: untrusted content can include instructions that cause the agent to fetch private data and send it out through an allowed communication path. Each individual step can be “authorized.” The sequence is still a breach.
Since agents can act on their own, hide the tools they don’t need and strictly limit what they can do with the ones they can see.
An agent should only "see" the tools necessary for its specific function. If a marketing automation agent can discover a finance export tool through a global MCP server, your attack surface has expanded unnecessarily. Use an MCP-aware gateway to restrict tool visibility based on the agent’s identity.
By making sensitive tools invisible to unauthorized workflows, you eliminate the risk of accidental or malicious tool invocation before a call is even attempted.
Authorization must move beyond a simple binary "yes/no" for endpoint access. In an agent-driven ecosystem, you must control the specific arguments an agent passes to a tool. For example, an agent may have permission to use a "file_export" tool, but you must restrict the allowed destinations to approved corporate repositories. An MCP-aware gateway allows you to inspect and constrain these parameters at runtime, preventing "allowed" tools from being used for unauthorized data movement.
An MCP-aware gateway sits at the real decision point: between agents and tools.
It understands how agents actually talk over MCP — how they discover tools, call them, store memory, and process responses and it can enforce controls right there, where those decisions are being made.
Instead of “this request can hit this endpoint,” you can enforce:
Attackers can exploit an agent's long-term memory to redirect future actions. By submitting untrusted content — such as a support ticket — that contains instructions to update the agent’s "default" storage location, an adversary can quietly reroute data. A traditional gateway sees this as a valid write request. An MCP-aware gateway monitors memory tool interactions, enforces persistence controls, and enables updates to comply with predefined policy boundaries.
Protect Against Rug Pulls and Shadow MCP Servers
A rug pull in an MCP world is when a tool server you trusted suddenly changes the task after you’ve already approved it. Imagine reviewing a server that only summarizes documents, giving it the green light, and then a week later it quietly adds a new “export_all_data” function.
Nothing looks different at first glance, but the capabilities have expanded under your feet. Because tool discovery in MCP environments is dynamic and often automatic, an agent may immediately see and use newly exposed functions without anyone re-evaluating the risk. The issue isn’t that servers can change — APIs change too — it’s that those changes can be surfaced to agents in real time and trusted by default.
A shadow or compromised MCP server may:
Tool outputs in MCP environments are fed directly back into the model as trusted context. If a tool returns a response containing hidden instructions or manipulated data, the agent may execute those commands as if they were legitimate. You must validate tool response schemas and strip unsafe elements before they reach the model. This process prevents tool poisoning and helps ensure that the model's next decision is based on clean, verified data rather than injected malicious prompts.
A rate limit is a control that caps how many requests a user, service, or agent can make within a set time window. It’s designed to prevent overload or abuse by throttling traffic when activity exceeds predefined thresholds.
Rate limits respond to one thing: “too many requests too fast.”
Agents can stay within rate limits and still create real risk using:
Agents function as non-human identities (NHIs) that operate continuously. They require scoped permissions and clear audit trails that link back to the originating user or service. MCP standardizes tool access but does not provide centralized governance.
An MCP gateway acts as the intermediary, mapping identities to specific agent sessions and keeping sensitive credentials out of the agent's reach. This creates a high-fidelity audit trail that captures the full chain of actions for compliance and forensics.
Traditional API gateways still play a critical role in managing traffic and enforcing baseline security—but they weren’t built for autonomous decision-making. They can route requests, but they can’t see or control how an agent decides which tools to use or what actions to take.
Securing this requires a new control layer that sits between AI agents and the tools they access. Not to slow them down, but to govern what they are allowed to do in real time.
To operate safely in this environment, organizations need more than point controls—they need a continuous security model built for autonomy.
That model is grounded in three principles: Discover, Assess, and Protect.
This framework becomes the foundation for how agent security is designed and scaled.
This is where Prisma AIRS comes in. It introduces an intelligence layer designed for enterprise systems, working alongside existing gateways, working from design to runtime.
By shifting from passive traffic control to active runtime governance, you create a system where agents can operate autonomously—without operating unchecked.
Secure confidently. Deploy Bravely.
To learn how Prisma AIRS secures agent actions across tools and workflows, fill out our contact form and one of our representatives will be in touch.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| Subject | Likes |
|---|---|
| 3 Likes | |
| 3 Likes | |
| 2 Likes | |
| 2 Likes | |
| 2 Likes |
| User | Likes Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 2 | |
| 2 |
