Agentic AI and MCP governance exposes a new identity security gap

At a glance

What this is: This analysis argues that MCP has become an identity expansion event for agentic AI, exposing governance gaps around persistent credentials, weak rotation, and limited auditability.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes built for static access models do not adequately govern agentic systems that can invoke tools, access data, and act continuously.

👉 Read Unosecur's analysis of agentic AI and MCP governance gaps

Context

MCP is a protocol that lets AI systems connect to tools, data sources, and actions. The governance problem is that these connections are often created faster than identity teams can inventory, classify, or control them, which leaves access paths and trust assumptions outside normal oversight.

Unosecur's article treats this as an identity security issue rather than a pure AI tooling issue. That framing is correct for practitioners because every MCP connection can introduce credentials, authorization paths, and audit obligations that belong inside IAM, NHI, and PAM governance.

In practice, the question is not whether AI can use tools. It is whether the enterprise can govern the identities, permissions, and session boundaries that make those tool calls possible without creating uncontrolled execution pathways.

Key questions

Q: How should security teams govern MCP access in agentic workflows?

A: Security teams should govern MCP access as delegated identity, not simple application connectivity. That means binding consent to the client, validating the token audience, refusing passthrough, and constraining each tool call to the narrowest possible scope. If those controls are not enforced per request, an authorised login can become an unauthorised action path.

Q: Why do persistent MCP credentials create such a high-risk access model?

A: Persistent credentials outlive the task that justified them, which means a transient agent can retain durable access to data and tools long after the original intent has changed. That widens the blast radius, weakens accountability, and makes revocation harder once the credential is embedded in files or workflows.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: What happens if teams scale MCP before adding identity controls?

A: The result is usually identity sprawl with little visibility, making every new server and tool connection another trust edge. In that scenario, agentic AI can use legitimate access to discover secrets, move data, or trigger actions that security teams cannot reliably trace or contain.

Technical breakdown

Why MCP becomes an identity expansion layer

MCP is not just a transport layer for AI tools. In production, it becomes a trust and execution layer because each client-server connection introduces credentials, authorization rules, and session state that determine what the agent can do. That changes the identity problem from static provisioning to dynamic access governance across many tool endpoints. When thousands of MCP servers are deployed across databases, SaaS apps, internal tools, and developer workflows, the real risk is not simply access sprawl. It is that access decisions are made locally and inconsistently, without a central policy boundary that can explain or constrain those decisions.

Practical implication: treat MCP endpoints as governed identity surfaces, not as ordinary integrations.

Persistent credentials and weak rotation in MCP deployments

The article describes a dominant pattern built on persistent credentials, weak rotation, minimal auditability, and no centralized enforcement. That combination matters because it gives AI clients durable access paths even when the work they perform is short-lived and task-specific. Static credentials are a poor fit for agentic behaviour because the access window outlives the intent that justified it. Once those secrets are embedded in configuration files, keychains, or environment files, the enterprise inherits both exposure risk and lifecycle debt. In NHI terms, the issue is not only secret leakage. It is that the credential model assumes long-lived, reviewable access where the actual workload is transient and distributed.

Practical implication: replace durable MCP credentials with shorter-lived, centrally governed issuance and revocation models.

Why agentic AI changes the trust model

The article's threat examples, such as prompt injection through tools, tool poisoning, and agent-driven secret discovery, all rely on a core shift: the agent already has legitimate access and uses it in ways defenders did not intend. That is why traditional perimeter thinking fails. When an agent can read private data, consume untrusted content, and act externally in the same workflow, malicious instructions can ride along inside content the agent trusts. The security boundary moves from network location to runtime decision-making, which means controls must observe tool use, data flow, and action chaining rather than only authentication events.

Practical implication: monitor agent actions and tool outputs as security events, not just login events.

Threat narrative

Attacker objective: The objective is to turn legitimate agent access into unauthorized data access, secret exposure, or hidden system actions without breaking primary authentication.

1. Entry occurs when an AI client connects directly to an MCP server with a credential that persists beyond the task it was meant to support.
2. Escalation follows when the same agent can reach private data, untrusted content, and external actions inside one workflow, letting malicious instructions influence legitimate tool use.
3. Impact occurs when the agent autonomously discovers and exfiltrates secrets or performs hidden actions through trusted tool chains, creating unauthorized access and data exposure.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP governance is now an identity problem before it is an AI problem. The article correctly frames MCP as the connective tissue for agentic AI, but the more important point is that connective tissue becomes control surface. Once clients connect directly to servers with local credentials and no central policy layer, governance fragments across tools instead of being enforced across identities. The implication is that IAM teams must stop treating MCP as a peripheral integration pattern and start treating it as a governed access domain.

Persistent MCP credentials create identity debt that static IAM was never built to absorb. The article's description of persistent credentials, weak rotation, and minimal auditability is not a maturity gap alone. It is a structural mismatch between long-lived secrets and short-lived machine tasks. Ephemeral task execution was designed for access that can be reviewed after the fact; agentic MCP activity can occur before any meaningful review window exists. Practitioners need to recognize that the issue is not just missing rotation. The issue is that the control assumption itself is outdated.

Agentic AI collapses the old boundary between authorisation and execution. Traditional IAM assumes a request, a decision, and then an action. In MCP-driven workflows, the agent can select tools, chain actions, and act on its own runtime context once access is granted. That creates a governance gap between the policy that approved the session and the sequence of actions the session can later produce. The field should respond by redefining the governed unit from the credential to the task.

Auditability is becoming the decisive control variable for MCP governance. The article highlights no centralized visibility, no consistent logging, and no chain of custody for who accessed what, when, and why. Those gaps matter because regulated environments need evidence, not assumptions, and agentic workflows generate far more actions than traditional review cycles can absorb. The practical conclusion is that teams should prioritise observable control planes for MCP traffic before expanding deployment scope.

The security conversation around MCP should now be measured in identity blast radius, not integration count. Each new server, client, and workflow adds another trust edge that can expand without clear ownership. That is why the category is moving from tooling experimentation to identity governance at scale. Practitioners should assume that the number of MCP connections is itself a governance indicator, not just an architecture statistic.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

Identity blast radius is now the right unit of MCP governance: each new server, client, and workflow expands the number of trust edges that security teams must own. When access is granted locally and reused across sessions, the programme loses the ability to explain who can act, on what, and under whose authority.

The practical signal for IAM and NHI teams is that MCP cannot be managed as an integration backlog. It needs a control plane that covers ownership, lifecycle, and logging across clients, servers, and agent sessions, or the enterprise will keep adding access faster than it can govern it.

For practitioners

• Define every MCP server as a governed identity endpoint Inventory MCP clients and servers as first-class identities, including ownership, approved use cases, and access scope, so the governance model covers each trust edge rather than only the underlying application.
• Replace persistent access with task-scoped issuance Use short-lived credentials, explicit session boundaries, and revocation paths so agent access expires with the task instead of lingering as durable secret debt.
• Centralise logging for agent actions and tool calls Capture authentication events, token use, tool invocations, and action outcomes in one audit trail to restore chain of custody across MCP activity.
• Separate read and write authority for agent workflows Apply granular policy controls so the same MCP session cannot freely read sensitive data and then act on it without a distinct authorisation boundary.

Key takeaways

• MCP is creating a new identity security problem because agentic AI uses it as an execution layer, not just a connectivity layer.
• The article points to persistent credentials, weak rotation, and limited auditability as the dominant governance weaknesses in current MCP deployments.
• Teams need to govern MCP endpoints as identities, shorten credential lifetimes, and restore traceability before agentic access becomes unmanageable.

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.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Identity Expansion Event: A change in architecture that adds materially more identities, credentials, and authority paths to an environment. For MCP, this means each agent, server, token, and delegated workflow becomes part of the identity surface and must be governed as such.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of the secure MCP Gateway architecture and how it centralises control
• Detailed descriptions of Session & Token Tracking and Policy Manager behaviour across tools
• Practical examples of JIT access and Just Enough Privilege for agent workflows
• The article's own mapping of MCP governance gaps to its identity-centric platform design

👉 The full Unosecur blog covers the secure MCP Gateway, task-based access controls, and governance details for agentic AI

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 or maturing an IAM programme, it is worth exploring.