MCP 2.0 shifts AI agent governance from connectivity to control

At a glance

What this is: Commvault argues that MCP 2.0 shifts AI agent governance toward authorization, action control, and visibility, but does not remove the underlying risk of broad agent authority.

Why it matters: IAM, PAM, and AI governance teams need to treat AI agents as actors whose permissions, pause points, and reversibility must be designed up front, not assumed safe because the protocol is more structured.

Context

MCP sits at the boundary between AI systems and enterprise tools, so changes to the protocol matter most where an agent can actually act, not just answer questions. The governance problem is no longer simple connectivity. It is whether an AI agent's authority is bounded tightly enough that one compromised workflow cannot become enterprise-wide access.

For identity and access teams, the important shift is that AI agents now behave like non-human identities with real privilege decisions behind them. That makes authorization, tool scoping, and execution controls part of the identity model rather than a separate AI concern. MCP 2.0 is best read as an attempt to move control closer to issuance and action time.

The article frames MCP 2.0 as a turning point because earlier protocol design was built for adoption, not for limiting blast radius. That starting position is typical of emerging agent ecosystems: capability arrives before governance maturity, and security teams then have to retrofit control boundaries.

Key questions

Q: What breaks when AI agents are given broad enterprise access without tight governance?

A: Broad access turns AI agents into high-speed execution paths that can move data, spend money, modify records, or delete assets before operators can intervene. The failure is not only misuse by an attacker. The system itself can exceed intended scope during normal task completion, so the real control problem is bounding authority before runtime action begins.

Q: Why do AI agent tools need stronger controls than normal application APIs?

A: AI agent tools need stronger controls because the caller can be partially autonomous, non-deterministic, and easier to manipulate through prompts. That combination raises the chance of unintended tool use, privilege abuse, and chained actions. Control design should assume the agent may be induced to request actions that the user never explicitly intended.

Q: What are the signs that an MCP implementation is not governed well enough for production use?

A: Common warning signs include broad tool access, missing masking on sensitive outputs, no approval path for privileged writes, and little or no tracing from agent to API. If teams cannot explain which tool ran, what policy decided, or whether a write was intentional, the MCP layer is still too permissive for production.

Q: How should teams respond when AI agents can make irreversible changes?

A: They should require explicit confirmation, constrain the tool surface, and design for rollback before the agent is allowed to commit the action. Where rollback is not practical, the workflow should force additional validation or human review so the action cannot silently propagate through downstream systems.

Technical breakdown

OAuth and least-privilege scoping for AI agents

MCP 2.0 adds OAuth so an agent can be authenticated and authorised with scoped permissions rather than broad, static trust. In practice, that means the protocol can express which tool, resource, or operation an agent may invoke, and can align access with the principle of least privilege. For IAM teams, this matters because the agent is not a user interface detail. It is a runtime actor that can hold and use access on behalf of a task. When that actor is over-scoped, the risk is not just misuse, but rapid privilege amplification across connected systems.

Practical implication: treat every agent integration as a privilege design problem and scope each OAuth grant to the narrowest task it must perform.

Structured schemas as an action allowlist

Structured schemas constrain what the agent can attempt by defining the accepted shape of tool calls and inputs. This reduces the chance that prompt injection, malformed inputs, or hidden instructions can push the agent into executing unexpected operations. The security value is not that schemas make the system safe by themselves. It is that they narrow the set of executable actions to those explicitly declared, which is an important control boundary when the agent can move from inference to action. In governance terms, schema discipline is a guardrail against tool misuse and uncontrolled execution paths.

Practical implication: require explicit tool schemas for every high-risk action and reject agent workflows that rely on implicit or loosely defined commands.

Elicitation flows create pause points before high-risk actions

Elicitation flows introduce a deliberate interruption in an agent workflow so a sensitive step can trigger confirmation, validation, or further credential handling. That is valuable because the main danger in agentic systems is often not initial access, but the speed with which the agent can chain one approved action into the next. A pause point gives security teams a chance to inspect intent, check context, or require human approval before the action completes. This is especially relevant where reversibility is low, because some actions cannot be undone once the agent has committed them to a system of record.

Practical implication: use elicitation only for actions with material business or security impact, and require explicit confirmation before irreversible changes are committed.

NHI Mgmt Group analysis

AI agents are now non-human identities, not just application features. Once an agent can read, modify, or decide, the identity question becomes central: what can it do, under what authority, and with what rollback boundary? That makes MCP governance an IAM and PAM problem as much as an AI problem. Practitioners should stop treating agent control as a protocol detail and treat it as a runtime identity model.

MCP 2.0 is a control-layer improvement, not a trust guarantee. OAuth, schemas, and elicitation improve how authority is expressed and constrained, but they do not prove the server, the toolchain, or the runtime environment is trustworthy. The named governance gap here is blast-radius control: if a compromised agent can still reach too much, the protocol has not solved the real exposure. Practitioners should design for containment, not assume control syntax equals safety.

Agentic governance debt will accumulate wherever execution is faster than review. Security teams already know that logs, approvals, and after-the-fact review do not stop a high-impact action once an agent has enough authority to commit it. The important shift is from monitoring access to governing issuance and action. Practitioners should build approval, scoping, and reversibility into the workflow before agent adoption spreads further.

Structured schemas reduce abuse only when the surrounding environment is controlled. The article correctly notes that a defined tool surface can limit prompt injection and misuse, but a disciplined schema is only one layer. If the MCP server, binaries, or host environment are compromised, the agent may still expose a wide control plane. Practitioners should pair protocol controls with environment hardening and continuous oversight.

The market signal is moving from agent connectivity to agent accountability. That is the right direction for identity governance because enterprise buyers are no longer asking only whether an agent can connect. They are asking what authority it has, how quickly that authority can be withdrawn, and how much damage one action can cause. Practitioners should expect procurement and architecture decisions to become more evidence-driven around scope, containment, and reversibility.

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.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Agent authority is the new control boundary: if an AI system can read, modify, and decide, then access scope must be governed as an identity issue rather than an interface issue. That shift matters because traditional review processes assume a human or service account with stable patterns, while agents can create and consume authority inside a single workflow. Practitioners should move control decisions to issuance time and define exactly which actions are reversible before deployment.

MCP 2.0 reflects a broader market move from connectivity toward accountable execution. For security programmes, that means the question is no longer whether AI tools can be connected to enterprise systems, but whether each delegated action has a bounded blast radius and a clear rollback path. Practitioners should expect agent governance to converge with PAM, ZTA, and runtime monitoring as deployments mature.

For practitioners

• Define agent authority before deployment Map each AI agent to the exact enterprise resources, tools, and operations it may use, then remove any permissions not required for the task. Treat the OAuth grant as a living entitlement, not a one-time setup.
• Use structured tool schemas for every sensitive action Require explicit schemas for commands that modify systems, move data, or trigger downstream workflows. Reject any integration that depends on hidden prompts, free-form tool calls, or undefined execution paths.
• Insert pause points for irreversible workflows Route high-risk actions through elicitation flows or equivalent approval steps before the agent can commit changes to systems of record. Reserve this control for actions where rollback is difficult or incomplete.
• Validate blast radius as part of access review Review not just who approved the agent, but what systems a single token, tool, or workflow can reach if the agent is compromised. Focus on containment boundaries across the full action chain.
• Monitor the agent runtime, not just the protocol Check the host, server, and tool environment for tampering, because a secure protocol does not compensate for a compromised runtime. Include signing, inventory, and monitoring for the surrounding components that execute MCP traffic.

Key takeaways

• MCP 2.0 reframes AI agent governance around authority, pause points, and action scoping rather than simple tool connectivity.
• The central risk is not whether agents can connect to enterprise systems, but whether their delegated access is broad enough to create unrecoverable blast radius.
• Security teams need to treat AI agents as runtime actors whose permissions, containment, and reversibility must be designed before deployment, not reviewed after the fact.

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.
• AI Agent Control: AI Agent Control is the set of policies, permissions, and runtime safeguards that govern what an AI agent can do. It defines allowed tools, data access, action limits, approval steps, logging, and rollback controls so an agent can operate independently without exceeding its intended authority or creating unmanaged risk.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Elicitation Flow: A workflow checkpoint that pauses an AI-driven action to request confirmation, validation, or additional credentials before continuing. It is useful for sensitive operations because it turns hidden execution into a controlled decision point with policy enforcement.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It helps practitioners turn identity policy into operational controls across human and non-human access.