MCP security exposes the limits of agentic AI governance

At a glance

What this is: This is an analysis of why MCP security became a central RSAC 2026 concern and how agentic AI changes the identity and runtime control model.

Why it matters: It matters because IAM, NHI, and security architecture teams now have to govern tools, data, and authorization at runtime rather than assuming code-centric controls will hold.

By the numbers:

• 48% of cybersecurity professionals now identify agentic AI and autonomous systems as the single most dangerous attack vector they face.
• 63% of organizations cannot technically enforce purpose limitations on their agents.
• 33% have no audit trails for agent activity.
• 75% have already been hit by supply chain incidents.

👉 Read Obot's full analysis of MCP security and agentic AI governance

Context

MCP security is the governance problem that appears when AI agents can read data, call tools, and chain actions at runtime. In that model, the security team cannot rely on code review or binary inspection alone, because the decision surface is shaped by inputs that are not fully knowable in advance and by tool access that can change mid-session.

At RSAC 2026, that shift was obvious to practitioners because the old assumptions behind identity, authorization, and audit trail design no longer lined up with how agentic systems behave. The issue is not simply that AI tools are new. The issue is that MCP connects identity, prompts, tools, and external systems in a way that forces governance to operate continuously, not only at deployment time.

For IAM and NHI programmes, the core question is whether control planes can inspect, constrain, and prove what an agent did while it was operating. That is a different requirement from securing a conventional workload or a human session, and it is already typical for early MCP deployments to leave gaps in visibility, scoping, and logging.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do MCP deployments create new security blind spots?

A: They create blind spots because the agent's behavior depends on live inputs, tool outputs, and connected services that are not fully known at design time. That means static review, code inspection, and deploy-time approvals cannot prove what the system will do once it starts chaining actions at runtime.

Q: What breaks when audit logging does not cover agent tool use?

A: Incident response breaks first, then accountability. If logs only show that a task finished, security teams cannot reconstruct whether the agent was steered, what data it touched, or whether a malicious tool or server changed the outcome. That leaves both breach analysis and compliance evidence incomplete.

Q: Which frameworks should teams use for MCP security governance?

A: Use NHI and zero trust frameworks as the baseline, then add agentic AI guidance where autonomous behaviour is present. OWASP NHI, NIST zero trust, and agentic AI threat models help teams map identity, tool access, and runtime control to concrete governance decisions.

Technical breakdown

Why MCP breaks static trust models

Model Context Protocol creates a live bridge between an AI agent and external tools or data sources. That means the relevant security question is not whether the software artifact was signed, but whether each runtime decision is authorised, observable, and bounded. Traditional perimeter models assume a fixed boundary, identity models assume a known requester, and audit models assume a replayable sequence. MCP weakens all three when the agent can combine data, prompts, and tools on the fly.

Practical implication: move control to the MCP layer where each request can be checked, constrained, and logged before the agent reaches the tool.

Why tool permissions become an identity problem

In MCP architecture, tool access is not a minor integration detail. It is the mechanism by which an agent turns a recommendation into action, so the identity question becomes who or what is allowed to invoke which tool, under which context, and with what limits. If permissions are broad, optional, or inherited from a human session, the agent effectively borrows trust it did not earn. That creates a governance gap between authentication and authorisation that normal application security does not close.

Practical implication: scope tool permissions at the identity layer, not only inside the agent or the target system.

Why auditability must survive runtime behaviour

A useful audit trail for MCP security has to capture tool requests, responses, and policy decisions in sequence, not just successful completions. If the agent is manipulated through prompt injection, malicious metadata, or untrusted tool output, the compromise lives in the path between request and action. Logging after the fact is not enough if the evidence only shows that the task completed. Security teams need records that support incident reconstruction and accountability when the decision logic is dynamic.

Practical implication: retain machine-readable logs for prompts, tool invocations, policy checks, and response content to support forensic review.

Threat narrative

Attacker objective: The attacker wants to turn agent trust into unauthorised access, data exposure, or control over connected infrastructure.

1. Entry begins when malicious skills, unvetted MCP servers, or poisoned tool responses reach the agent through the protocol layer.
2. Escalation follows when the agent inherits excessive permissions or executes tool calls that extend beyond the intended scope of the session.
3. Impact occurs when the compromised runtime path exposes credentials, data, or connected systems through the agent's tool access.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security exposes a runtime governance gap, not just a tooling gap. The article shows that practitioners are no longer debating whether agents need controls. They are confronting the fact that identity, authorisation, and audit all have to move to the protocol boundary because the agent acts in response to runtime inputs. That is why governance must treat MCP as part of the identity plane, not as a convenience layer.

Behavior is a function of data, not code, and that breaks code-centric assurance assumptions. Static review models assume that the security properties of a system can be established before execution. Agentic systems invalidate that premise because tool choice, data selection, and action sequencing emerge during runtime. The implication is that least privilege and auditability must be enforced against live behaviour, not inferred from pre-approved artefacts.

Runtime protection is now the decisive control tier for agentic AI. Visibility and configuration matter, but they are only the first two layers of governance. The harder problem is detecting when an agent is being steered through poisoned context, malicious server behaviour, or policy drift while it is already operating. Practitioners should read this as a signal that runtime monitoring is no longer optional for AI-mediated access.

Identity governance for agents must extend to the supply chain that feeds them. The article is clear that malicious skills, third-party servers, and connected tools are all part of the trust chain. That means the governance scope has to include registration, approval, logging, and revocation for everything the agent can invoke, not only the agent object itself. Security teams should treat the agent ecosystem as an identity perimeter with multiple failure points.

Named concept: runtime governance gap. This is the gap between approving an agent in advance and being able to prove what it did during execution. MCP makes that gap visible because the agent can pivot across tools and data sources faster than human review cycles can follow. Practitioners should use this concept to separate deployment controls from true runtime control.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The governance question moves from whether agents are useful to whether your control plane can still prove what happened across OWASP Agentic Applications Top 10 and operational identity controls.

What this signals

Runtime governance gap: the next phase of agent security will be decided by whether teams can enforce policy where decisions happen, not where software is deployed. The organisations that centralise tool control, logging, and policy checks will have a better chance of containing agent behaviour as adoption expands.

With 80% of organisations already reporting AI agents acting beyond intended scope, the operational issue is not theoretical drift but normalised overreach. That makes access scoping, audit coverage, and revocation discipline the difference between manageable experimentation and uncontrolled production exposure.

Practitioners should prepare for a convergence between NHI governance and agentic AI controls, with zero trust assumptions applied to tool use, not just network traffic. The practical yardstick is whether every connected tool, server, and permission can be traced back to an accountable owner and a defensible business purpose.

For practitioners

• Centralize MCP governance Put every agent, tool permission, and policy check through a single control plane so teams do not invent inconsistent local rules across environments.
• Scope tool access to named business functions Limit each agent to the smallest set of tools and actions it needs, and require explicit approval for any expansion into new data sources or external systems.
• Make audit logs forensic-grade Capture prompts, tool invocations, policy decisions, and response content in a form that supports post-incident reconstruction and compliance review.
• Review the full agent supply chain Validate MCP servers, third-party skills, and connected services before they are allowed into production, and revoke anything that no longer has a clear owner.
• Test runtime controls against prompt injection Exercise the control plane with poisoned metadata, malicious tool descriptions, and unexpected tool chaining to verify that policy enforcement holds during execution.

Key takeaways

• MCP security is forcing identity teams to move from static approval models to runtime governance.
• The article shows that agent behaviour, tool access, and auditability are now one security problem, not three separate ones.
• Practitioners should centralise control, narrow permissions, and require forensic-grade logging before agentic systems reach production.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
• Tool Permission Scoping: The practice of limiting what a non-human identity can do with each tool, including which data sources it can reach and which actions it can trigger. Strong scoping is a core control for agent governance because it reduces overreach, improves auditability, and supports revocation.

What's in the full article

Obot's full analysis covers the operational detail this post intentionally leaves for the source:

• Architecture details for the Obot MCP Gateway control plane and how it mediates tool access at runtime.
• Identity provider integration points with Okta, Google Workspace, and Microsoft Entra for agent access governance.
• Operational guidance on centralized logging, policy enforcement, and audit trail retention for MCP sessions.
• Deployment considerations for sandboxing, self-hosted infrastructure, and control-plane visibility across local and cloud systems.

👉 Obot's full post covers the gateway architecture, identity integration, and runtime control details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls across human, machine, and AI-driven environments, it is worth exploring.