MCP Security: The Question RSAC 2026 Couldn’t Answer But Couldn’t Stop Asking
The sessions on agentic AI at RSAC 2026 weren’t packed because practitioners had answers. They were packed because practitioners were scared, and smart enough to know it. MCP security was the thread running through nearly every conversation, from identity frameworks to supply chain risk to runtime protection gaps nobody had fully solved.
Ahead of the conference, David Brauchler, Technical Director and Head of AI/ML Security at NCC Group, put the core problem into terms that kept circulating across security channels: in agentic AI, behavior is a function of data, not code. Read that slowly. Every trust assumption the industry has built over decades, the notion that you can audit a binary, review a codebase, verify a signature, falls apart when the thing making decisions is responding to runtime inputs you can never fully enumerate in advance. The attack surface is everything the agent reads.
That framing landed hard because it named something security teams had already been feeling but hadn’t yet articulated. A Dark Reading poll cited by Bessemer Venture Partners found that 48% of cybersecurity professionals now identify agentic AI and autonomous systems as the single most dangerous attack vector they face. The top one.
MCP Security and the Infrastructure Gap Nobody Planned For
What made RSAC 2026 genuinely different from previous years’ AI security conversations was the specificity of the problem. Practitioners weren’t debating whether AI agents posed risk. They were rethinking what trust means for a class of system that can take real-world actions, chain tool calls autonomously, and respond to inputs injected anywhere along the way. Five competing identity frameworks were reportedly shipping at the conference. None of them closed every gap.
The Coalition for Secure AI captured this plainly in its recent MCP security whitepaper: these aren’t theoretical vulnerabilities, they’re production incidents, and they share a common thread. Traditional security frameworks weren’t designed for AI-mediated systems where a language model sits at the center of security-critical decisions.
That gap is what this post examines: why the problem is structural, what the conference surfaced about identity, authorization, and audit trails, and what an Obot MCP Gateway infrastructure layer needs to look like if you want governance that holds under real-world conditions.
Why Traditional Security Breaks for AI Agents
Classic software has deterministic behavior baked into its code. You audit the binary, review the logic, sign the artifact, and deploy with a reasonable expectation that the thing will do what you verified it does. Agentic systems invert that model entirely. Behavior becomes a function of real-time data inputs, and no static policy can enumerate every input an agent will encounter at runtime. You can’t sign a prompt. You can’t audit a tool call that hasn’t happened yet.
Why MCP Security Requires a Different Mental Model
CoSAI’s MCP security whitepaper states that traditional security frameworks weren’t designed for AI-mediated systems. This is a structural observation, not a product gap. The perimeter model assumes a defined boundary. The identity model assumes a known actor making authenticated requests. The audit model assumes a deterministic log you can replay. In the open-source Model Context Protocol (MCP), which connects large language models and autonomous AI agents directly to external infrastructure and data sources, agents violate all three assumptions simultaneously because the language model at the center of every decision is itself a dynamic interpreter of whatever data it receives.
MCP operates through a client-server architecture in which an MCP client mediates access to three primary functional components: resources, tools, and prompts.
Security researcher Simon Willison identified this in June 2025: according to research tracking AI agent security risks, the structural issue applies to every MCP deployment currently implemented without governance overlays. A protocol-level exposure rooted in MCP architecture, not a configuration mistake you can patch. The MCP specification does not enforce security at the protocol level, so MCP security for the MCP protocol has to be added by security teams as an architectural overlay of controls.
The implications compound quickly. An AI governance framework built on static controls, approved lists, signed packages, reviewed prompts, provides meaningful defense in depth only if those controls can be enforced at runtime, dynamically, across every tool invocation and every data input the agent touches. Governance that operates only at deploy time has a very short window of relevance. That design introduces several attack surfaces when developers don’t implement proper security controls.
The infrastructure layer beneath the agent has to carry security logic that developers and security teams once assumed lived in the code itself. The control plane, the identity layer, the authorization boundary: none of it can be passive. An MCP proxy providing centralized security, control, and observability has to interrogate, constrain, and record agent behavior as it happens, not after the fact.
The Gap Is Real and Measurable: What the Data Says
The numbers aren’t projections. They’re measurements of what’s already broken.
Research tracking AI agent security risks puts three figures together that security leaders need to sit with: 63% of organizations cannot technically enforce purpose limitations on their agents, 33% have no audit trails for agent activity, and 75% have already been hit by supply chain incidents. As the MCP ecosystem expands, those security challenges grow with MCP adoption, amplifying top MCP security risks and required best practices. That last number used to describe a software delivery problem. It now extends to agent skills, MCP server packages, third party servers, and unofficial repositories, where the lack of an official registry creates real security concerns and can expose organizations to data breaches and unauthorized access. Compromised or unauthenticated MCP servers may hold API keys and cloud credentials for multiple connected services, creating a single point of failure and elevating breach impact. The attack surface expanded, and organizations’ measurement capabilities are often still behind.
The Supply Chain Has Already Reached MCP Security
The OpenClaw/ClawHub incident is the clearest proof point. Antiy CERT confirmed 1,184 malicious skills across ClawHub, the marketplace for the OpenClaw AI agent framework, making it the largest confirmed supply chain attack targeting AI agent infrastructure to date. These weren’t theoretical proof-of-concept packages. They were in a production marketplace where developers pull agent capabilities the same way they pull npm packages, quickly, conveniently, and often without the review process a new vendor relationship would trigger. In those ecosystems, a malicious MCP server or unvetted MCP agent skills in public registries can look legitimate and still create serious security exposure.
Then, on February 25, 2026, Check Point Research disclosed critical vulnerabilities in Claude Code, Anthropic’s command-line AI development tool used by thousands of developers daily. MCP servers can also suffer command injection vulnerabilities, allowing malicious code or even remote code execution against sensitive resources when server code or exposed tools are flawed. Two separate disclosures, two separate events, and a clear pattern: the components beneath the agent are active targets.
The AI agent security guide for 2026 frames the enterprise challenge precisely: organizations need consistent controls that protect data regardless of where AI agents operate, echoing the broader MCP security risks in 2026 and CTO action plan now emerging across early deployments. An AI governance framework that only governs at the agent level, while leaving the skill marketplace, the MCP server layer, and connected external systems unmonitored, has gaps wide enough for 1,184 malicious packages to move through undetected.
The 33% with no audit trails aren’t just flying blind operationally. In a post-incident review, they have no record of what any agent touched, invoked, or exfiltrated. That’s an absence of accountability at the infrastructure layer where accountability matters most, especially when MCP servers can bridge databases, cloud tools, and other external services that are exposed if those connections are not properly secured, and when a malicious server can turn small oversights into unauthorized access or data leaks.
What RSAC 2026 Shipped, and What It Left Unsolved
Five identity frameworks shipped at RSAC 2026. Duo, Okta, 1Password, and others each arrived with approaches to register AI agents as distinct identity objects and route tool calls through MCP gateways rather than treating agent activity as an extension of a human user’s session. After years of practitioners asking where the agent fits in their identity model, vendors finally delivered answers in the form of shipping infrastructure.
That progress is real. Registering agents as first-class identity objects closes a gap that has existed since the first production deployments. MCP gateways now improve the security posture of AI applications by centralizing authentication, audit trails, and policy checks across MCP components, representing genuine maturation from the improvised configurations that characterized 2024 and early 2025 deployments. Many MCP implementations still leave authentication optional, so unauthorized access remains a core security issue even as identity frameworks improve.
The Blind Spot the Frameworks Left Open
None of them solved an agent rewriting the policies governing its own behavior. MCP hosts still face consent fatigue when repeated approval prompts train users to click through requests without understanding them.
MCP gateways inspect tool calls in transit. They can catch anomalous invocation patterns, flag out-of-scope requests, and log the full sequence of what an agent asked for and what it received, forming a critical layer against prompt injection attacks that agents cannot reliably defend against alone. In a post-incident review, that is the difference between having a timeline and having nothing. The pattern is similar to MFA fatigue: malicious MCP servers can flood users with benign prompts before surfacing a harmful action that appears to have explicit user approval.
But direct policy file modifications on the endpoint sit outside what any of these frameworks currently monitor as a shipping capability. If a compromised agent, or a prompt injection payload riding in through a tool response, modifies the configuration that defines what the agent is permitted to do, the gateway sees compliant-looking traffic from that point forward. The authorization layer has been rewritten beneath it. Tool poisoning creates a similar problem: malicious updates to tool descriptions or parameters can change relevant tool context and steer tool access or tool usage without obvious visibility from the host. The audit trail records behavior after the compromise, not the compromise itself, including blind spots created by malicious instructions embedded in metadata or responses.
This is the structural gap that the Bessemer Venture Partners analysis points toward when it describes runtime protection as the hardest and least mature of the three security stages. Visibility and configuration controls are tractable engineering problems. Runtime protection against an agent modifying its own governance state requires a different class of integrity monitoring, one the conference acknowledged but did not deliver.
RSAC 2026 generated real momentum and shipped real infrastructure. An AI governance framework built only on what shipped there is still incomplete. Security leaders need to plan around both realities.
The Infrastructure Layer Is the Answer. Here’s What It Must Do
Every gap documented in this article points toward the same conclusion: governance logic cannot live in the agent, because MCP creates a direct bridge between AI reasoning and sensitive data as well as external tools. It has to live beneath it.
Bessemer Venture Partners’ three-stage framework gives this shape. Stage one is Visibility: a complete inventory of every running agent, the model it’s calling, and the tool permissions it holds. Stage two is Configuration: least-privilege access controls enforced at the MCP layer, strong authentication, data masking before sensitive content reaches the model, hard behavioral rails constraining what agents are permitted to invoke, and fine-grained MCP access control beyond server-level permissions aligned to frameworks such as the OWASP MCP Top 10. Stage three, and by BVP’s own assessment the hardest, is Runtime Protection: detecting anomalous behavior at machine speed through runtime monitoring, using sandboxing or isolation for risky interactions, and maintaining audit logs that create genuine forensic evidence, not just timestamps of successful completions.
CoSAI’s defense-in-depth model reinforces the same architecture. Layered controls, each layer assuming the one above it will occasionally fail. Effective MCP security also depends on real-time policy enforcement, identity-aware on-behalf-of execution, input and output sanitization, and PII-aware filtering of sensitive tool responses at the control plane, plus centralized governed registries to protect AI assistants and connected services while preserving regulatory visibility.
The Control Plane Has to Be Centralized for Access Control
Integrate.io’s analysis of MCP gateway solutions describes how centralized gateways now provide authentication, audit trails, and policy enforcement across connected systems, and independent reviews of the best MCP gateways for enterprise teams in 2026 highlight how this centralization has become a baseline requirement. That centralization is the critical design principle. Distributed enforcement, where each agent team implements its own access control and logging conventions, produces exactly the inconsistency that attackers exploit and compliance officers cannot certify; centralized policy should combine role-based and attribute-based rules, with permissions tightly scoped to specific repositories, branches, and actions.
The Obot MCP Gateway is purpose-built as that centralized control plane, addressing each stage of the BVP framework directly: inventory and visibility across all agents and their tool permissions, least-privilege access enforcement at the MCP layer, and comprehensive audit logs that survive post-incident review, embodying the architectural principles outlined in what an MCP gateway is and how it secures AI agents. Identity provider integration with Okta, Google, and Microsoft Entra grounds agent identity in the same authoritative directory your human identity program already trusts, while centralized execution avoids giving models direct access to external systems and mediates each API call through policy.
Centralized control also supports audit-ready forensics and stronger regulatory compliance outcomes by securing credentials instead of passing secrets to models directly, avoiding the dangerous MCP OAuth shortcuts that are currently undermining security.
An AI governance framework built on centralized infrastructure gives development teams frictionless access to approved, cataloged tools while giving security teams the inspection point they require.
From Shadow AI to Sanctioned Infrastructure: A Practical Path Forward
Organizations with production agents running today cannot wait for the next conference to deliver a unified answer, and security teams will press for the same assurances covered in enterprise MCP security review playbooks. The governance infrastructure they need exists now, but permissions and configurations should be reviewed through recurring security assessments and regular audits so expanded roles and unused access do not remain active.
Start With Centralization
Distributed enforcement is where governance goes to die. If individual teams manage their own MCP servers, set their own access controls, and maintain their own logging conventions, you will never achieve the consistency that AI agent security guidance identifies as the core requirement: controls that protect data regardless of where agents operate. Centralize MCP server management first. A local MCP server should not retain broad file system access or unrestricted network access, and sandboxing helps isolate it from local services where possible. Everything else depends on having a single inspection point, with short-lived scoped credentials for local services rather than static secrets.
Integrate Identity You Already Trust
Agent identity grounded in a parallel directory is a liability. In the host application, the mcp client sends requests to the server on the agent’s behalf, so trust and authentication have to work in both directions. Okta, Google Workspace, and Microsoft Entra already hold your authoritative user records and group memberships. Extending those to govern agent-level access, through the same identity provider your human access program already runs, closes the gap between what your identity team can audit and what your agents are doing.
Make Audit Logging Non-Negotiable to Mitigate Prompt Injection
The 33% of organizations with no audit trails for agent activity are one incident away from a post-mortem with no timeline and no forensic basis for remediation. Treat logging as a precondition for any agent reaching production by capturing MCP interaction details, reviewing LLM inputs and outputs for prompt-context manipulation or sensitive-data extraction attempts, and analyzing event logs for suspicious API behavior or data exfiltration from compromised server tools.
Audit logs should also preserve chain-of-custody quality records for post-incident forensics and compliance.
Prefer Open-Source, Self-Hosted Infrastructure
Vendor lock-in in the MCP security layer is a compounding liability, especially as the broader MCP and agentic AI learning center ecosystem matures and enterprises expect portability across the top gateway and security tools. Organizations evaluating MCP infrastructure increasingly prioritize open-source and self-hosted solutions because they need deployment flexibility across cloud, on-premise, and hybrid environments without dependency on a single vendor’s roadmap, and self-hosted control planes make it easier to protect sensitive files such as configuration files, OAuth tokens, and ssh keys instead of scattering them across vendors or agents. Open foundations give you auditability of the control plane itself, not just the agents it governs, and an MCP gateway helps prevent credential exposure by eliminating the need to pass API keys or database passwords directly to AI models while storing tokens securely.
None of these steps require waiting for the industry to converge on a single standard. They require deciding that governance is an accelerator and building accordingly.
The roadmap is clear. The infrastructure is available. Review the Obot MCP Gateway and download it to take your first step from shadow AI to sanctioned, production-ready infrastructure.
