Model Context Protocol (MCP) has become the default way AI agents connect to external tools and data sources. What started as an open-source framework in late 2024 is now embedded across industries and business functions like software development, finance, legal, and business operations.
With 97M+ monthly SDK downloads and 10K+ active public MCP servers, the adoption has been fast. But the protocol, by design, doesn't enforce security. With agents now performing real actions across internal systems, that gap becomes critical.
Risks When AI Takes Actions
Every MCP tool call is a data exchange. The agent sends arguments to the tool, and the tool sends back results. In today’s implementations, neither side is typically inspected.
What an agent/LLM sends to the tool: Unsanitized tool parameters can be executed directly through legitimate interfaces, exposing sensitive data or enabling unauthorized commands. There's also the everyday risk of agents unknowingly passing sensitive data as tool arguments, customer emails in search queries, or API keys. The agent is assembling what it needs to complete the task. It has no concept of what's sensitive.
What the tool sends back: A ticket lookup returns vulnerability details from a security-tagged Jira issue. Most MCP implementations treat these responses as trusted by default; the agent ingests everything without inspection, and that data can end up in conversation logs, downstream tool calls, or responses visible to users who shouldn't have access.
AI agents often pass outputs to other agents and systems without checking what's in them. In multi-agent workflows, a single bad response can ripple through the entire chain, leading to data leaks or hijacked actions.
To see what this looks like at scale, consider a widely adopted MCP integration, the GitHub MCP server. When a developer connects it to their coding agent, they frequently grant blanket read and write access across all of their repositories, private and public. The tools can then read sensitive source code from a private repository and write or publish content to a public one, without the user explicitly approving or even being aware of each action.
A poisoned response at any point in that chain has the permissions to read, write, and publish across the entire codebase.
The NSA's 2026 advisory on MCP documented real-world cases of tool parameter injection in open-source MCP agents. It also highlighted that most MCP implementations either omit logging entirely or record only minimal metadata, leaving organizations with no trace when sensitive data leaks through a tool call in either direction.
Securing Agentic AI Actions
The right way to think about MCP security is to follow the request itself, from when a server is discovered to when a tool call is logged. This breaks down into three areas: discover what's connected, protect what's flowing through, and govern who has access.
An organization does not need to go from zero to ten overnight. But it helps to know where you are and what the next step looks like.
Discover
Know what's connected. MCP servers that an organization's agents interact with should be registered in a central inventory. Track which agents are connected to which servers, what tools are available, and how they're being used.
Protect
Input Inspection: When an agent constructs a tool call, inspect the arguments before the request reaches the MCP server. Scan for PII, credentials, sensitive patterns, and unsanitized parameters that could enable injection. If the input violates a policy, the call can be blocked.
Response Inspection: When the MCP server responds, inspect the output before the agent ingests it. Flag sensitive data, exposed credentials, or hidden instructions meant to manipulate the agent. Catch it here to mitigate the risk of it spreading further.
Govern
Access and Authorization: Once a server is registered, control who can reach it. Restrict access to specific MCP servers based on team membership, user roles, or identity claims, further down to the tool level. Authentication and authorization should happen before any tool call executes, not after.
Rate Limiting: Agents generate tool calls at machine speed. Without limits, a single session can overwhelm a server with recursive loops or runaway retries. Rate limiting keeps that in check.
Session Auditing: Every step above should be captured in a single log, tied to the agent session that triggered it. One view of what happened, why it was blocked or allowed, and what the agent did next.
Enterprise-grade Security for Agentic AI
Prisma AIRS AI Gateway unifies the security, governance, and observability for LLMs and MCP interactions.
It covers the entire MCP request flow described above, from a central registry for discovery and access control, through real-time inspection of tool call inputs and outputs, to rate limiting and session-level auditing.
Organizations get a comprehensive suite of guardrails out of the box, covering data protection, content safety, custom pattern matching, and policy enforcement through external webhooks.
Because the gateway and runtime work together, policies can be applied consistently across all connected servers and agents, with session activity logged in one place, tied to the agent session that triggered it.
Recommended read: To learn more about MCP vulnerabilities and how to address them, read our Simplified Guide to MCP Vulnerabilities.
Palo Alto Networks was named a Market Shaper in AI application security. Read the report: Gartner® Emerging Market Quadrant for AI Application Security – Established Vendors, September 2026.