MCP governance is becoming load-bearing for agentic development

At a glance

What this is: This analysis argues that MCP is evolving into core infrastructure for agentic development, and that community plugin sprawl is outpacing visibility, vetting, and audit controls.

Why it matters: IAM, NHI, and security teams need to treat MCP-connected agents as governed access paths because identity, logging, and approval gaps quickly become audit and data exposure gaps.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Obot's analysis of MCP governance for agentic development stacks

Context

MCP governance now sits at the intersection of software delivery, access control, and supply chain risk. In practice, that means the problem is not whether agents can call tools, but whether organisations can see, classify, and account for the permissions those tools create across development and production workflows.

The primary identity concern is that community-built MCP servers, parallel agent sessions, and connected production signals create new non-human access paths that look operational until something goes wrong. For IAM and PAM teams, the question is whether these agentic workflows are being governed like managed identities or left as invisible integrations.

This pattern is still emerging, but the starting position is already common in fast-moving engineering teams: wide experimentation, weak review, and no central inventory of what has been connected. That combination is now typical rather than exceptional.

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 unvetted MCP servers create more risk than normal integrations?

A: Unvetted MCP servers can inherit broad tool reach while hiding what data they read, what they transmit, and what decisions they influence. Unlike a conventional integration with clear boundaries, they sit inside an agent workflow that can browse, write, and act in sequence. That makes the risk cumulative, because one connection can expand the agent’s authority across multiple systems.

Q: What breaks when agent sessions are not isolated from each other?

A: Parallel agent runs can overwrite files, reuse context, and leak assumptions if they share state or credentials. That creates silent corruption instead of obvious failure, which is harder to detect and triage. The practical failure is not just data loss. It is unreliable execution across feature work, testing, and production-connected tasks that were meant to be independent.

Q: Who is accountable when an MCP agent accesses the wrong resource?

A: Accountability sits with the teams that defined consent, token handling, and policy review for the MCP deployment. If token passthrough, weak audience checks, or incomplete client approval allowed the request, that is a governance failure, not an agent anomaly. Frameworks such as NIST CSF and Zero Trust architecture expect explicit access validation.

Technical breakdown

Why MCP becomes a control plane, not just a protocol

MCP began as a standard way for a model to talk to external tools, but in practice it becomes a control plane once agents rely on it for code execution, search, observability, and file operations. Each server expands the agent's effective permission set and data reach. The architectural shift matters because the protocol no longer sits at the edge of the workflow. It sits in the middle of decision-making, where a connected tool can influence what the agent sees, does, and writes back into systems.

Practical implication: inventory MCP servers as governed integrations, not optional plugins.

How indirect prompt injection reaches through connected tools

Indirect prompt injection works by hiding malicious instructions in data an agent already expects to consume, such as documentation, API responses, or dependency feeds. The model does not need to be compromised directly. It only needs to read untrusted content that then shapes downstream actions. In agentic development, the risk grows when the same workflow can browse the web, edit files, and call external services. That creates chaining opportunities where one hidden instruction can influence multiple steps before a human notices.

Practical implication: constrain what connected data sources agents can read before they can act.

Identity-aware logging is the difference between activity and accountability

Agent ecosystems often produce logs about what happened, but not enough identity context to show who connected what, when, and under which approved scope. That gap is the core governance problem. Without identity-aware audit trails, security teams can see tool traffic but cannot attribute it to a developer, an approval event, or a specific risk decision. In environments where agents can run parallel sessions and connect to production signals, that lack of attribution turns observability into partial evidence rather than usable control.

Practical implication: tie every MCP connection to a human identity, approved entitlement, and reviewable session record.

Threat narrative

Attacker objective: The attacker wants to influence a trusted agent into performing authorised-looking actions that expose data, corrupt code, or widen access across connected workflows.

1. Entry occurs when a developer connects an unvetted community MCP server or third-party data source into an agentic workflow.
2. Escalation follows when the agent inherits broad tool access, including code changes, browser access, file writes, or production signals.
3. Impact appears when injected or malicious instructions drive the agent to exfiltrate data, alter code, or take unsafe operational actions across connected systems.

NHI Mgmt Group analysis

MCP governance is now an identity problem, not just a tooling problem. Once an agent can connect to code, logs, search, and file systems through MCP, every server behaves like a non-human access path with its own approval, attribution, and revocation requirements. That moves the issue squarely into IAM and PAM territory, especially when community-built servers can be connected faster than they can be reviewed. Organisations should govern MCP the way they govern privileged integrations, not like optional developer extensions.

Shadow agent infrastructure is the right named concept for this shift: unreviewed MCP servers, parallel agent sessions, and unmanaged integrations are creating a second control plane outside normal security inventory. That control plane is difficult to see precisely because it is framed as productivity infrastructure. The governance failure is not that the tools exist, but that they can accumulate authority without lifecycle controls. Practitioners should treat every new server as a privileged asset with a lifecycle, ownership, and offboarding requirement.

Visibility without identity is not enough in agentic development. The strongest risk signal in these ecosystems is not just what data moved, but who approved the connection, which identity used it, and whether the session can be reconstructed later. That makes this a direct test of auditability across identity, NHI, and security operations. If a team cannot answer those questions, it has not governed the workflow, only observed it.

Protocol scale changes the attack surface faster than policy can catch up. MCP is moving from a developer convenience layer into load-bearing infrastructure, which means the future risk is less about isolated misuse and more about a growing base layer of connected authorities. That trajectory will favour organisations that standardise approval, classification, and logging early. Security leaders should assume the governance gap widens as agent capabilities expand.

What this signals

Shadow agent infrastructure is becoming a programme-level governance issue. Once developers can compose their own MCP stacks, security teams lose the luxury of reviewing tools one by one after adoption. The better operating model is pre-approved identity bindings, controlled server catalogs, and audit trails that can survive a compliance review. For identity programmes, that means the policy question is no longer whether agents can connect, but which connections are allowed to exist at all.

The next control gap is not discovery, it is lifecycle management for non-human access created by agents and plugins. The same governance patterns used for service accounts and secrets should be extended to MCP-connected workflows, with explicit ownership, revocation, and evidence capture. That is the difference between scalable control and a growing exception list.

For practitioners

• Implement a governed MCP server inventory Create a central register of every approved MCP server, its owner, data sources, identity bindings, and revocation path. If a server cannot be tied to an accountable human owner and a documented approval, it should not be connectable to production-adjacent agents.
• Require identity-aware session logging Log the developer identity, tool approval event, server name, and session scope for every MCP connection. This makes it possible to reconstruct which agent used which authority and supports audit, incident response, and access review.
• Restrict agent data sources before execution Allow agents to read only the data sources needed for the task and block unreviewed repositories, APIs, and documentation feeds by default. This reduces indirect prompt injection exposure and narrows the blast radius of a compromised server.
• Separate parallel agent sessions with hard isolation Use sandboxed workspaces, separate credentials, and no shared state between concurrent agent runs. Parallel agents should not be able to modify each other’s files, tokens, or operational context, even when they work on related tasks.

Key takeaways

• MCP is evolving into infrastructure for agentic development, which makes its governance a privilege and identity problem as much as a developer-experience issue.
• The largest risk is not a single malicious plugin, but the accumulation of unreviewed servers, opaque data paths, and identity gaps across parallel agent workflows.
• Teams need inventory, identity-aware logging, and lifecycle controls now, before the ecosystem becomes too large to audit reliably.

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.
• Shadow Agent Infrastructure: Shadow agent infrastructure is the unmanaged layer of agent tools, servers, and integrations that employees connect outside formal review. It is risky because it creates non-human access paths with real authority but weak inventory, weak ownership, and poor lifecycle control.
• Identity-Aware Logging: Logging that connects AI activity back to the human, service account, or agent that performed it. This is essential when data access, model calls, and approval states must be traced across cloud, SaaS, and internal systems.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.

What's in the full article

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

• Specific MCP governance workflow examples for approving, cataloguing, and revoking servers in enterprise environments
• Practical implementation detail on identity-aware logging and how to bind agent sessions to human approvers
• Operational guidance for isolating parallel agent sessions and reducing blast radius across connected tools
• The source article's deeper walkthrough of community plugin categories and the stack composition patterns developers are using

👉 Obot's full post covers the stack patterns, governance controls, and risk surfaces in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building control over non-human access. It helps security and identity teams apply lifecycle thinking to agentic workflows, service accounts, and other machine identities.