MCP 2.0 shifts AI agent governance from connectivity to control

At a glance

What this is: MCP 2.0 moves AI agent integration from simple connectivity toward authorization, control, and visibility, with OAuth, schemas, and pause points as the key changes.

Why it matters: IAM, PAM, and NHI teams need to treat AI agents as governable actors whose permissions, decision paths, and rollback limits must be explicitly constrained across enterprise systems.

By the numbers:

• 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%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Commvault’s analysis of MCP 2.0 and AI agent governance

Context

MCP 2.0 matters because AI agents are no longer passive interfaces. They can read files, change systems, and trigger downstream actions, which turns protocol design into a governance issue rather than a pure integration problem. For identity and security teams, the real question is how to bound agent authority before those actions create an uncontrolled blast radius.

The protocol’s importance comes from its attempt to add authorization and execution discipline to a class of systems that often grew faster than their controls. That creates a genuine identity intersection: when an agent can act, it needs scoped access, clear accountability, and revocation paths just like any other privileged non-human identity. In practice, the starting position in most enterprises is still behind the pace of adoption, not ahead of it.

Key questions

Q: How should security teams govern AI agents that can act on enterprise systems?

A: Treat each agent as a non-human identity with a defined purpose, scoped permissions, and a clear owner. Put high-risk actions behind confirmation, step-up checks, or change-control gates, and ensure the agent can be disabled or rolled back before it crosses critical boundaries.

Q: Why do AI agents create more risk than ordinary automation workflows?

A: AI agents can choose actions dynamically, which means their behaviour can change at runtime and cross boundaries a simple script would never reach. That makes access scope, approval logic, and revocation more important than static workflow design.

Q: What breaks when MCP-connected agents are given broad access?

A: Broad access turns an agent into a high-impact execution path. If the agent is manipulated, misconfigured, or compromised, it can read data, modify systems, or trigger downstream actions far outside the original task, expanding the blast radius across multiple services.

Q: Who is accountable when an AI agent causes an unauthorised action?

A: Accountability should sit with the team that approved the agent’s authority, the system owner that exposed the tool, and the governance function that failed to define the control boundary. Frameworks such as NIST AI RMF and identity governance policies should make that ownership explicit.

Technical breakdown

OAuth for AI agents: how scoped access changes MCP governance

OAuth brings a familiar delegated-authorisation pattern into MCP, allowing an agent to operate with a token-bound permission set instead of broad, implicit trust. That matters because agent actions are not just API calls, they are policy-relevant operations against files, systems, and data. In identity terms, the agent behaves like a non-human identity that needs least privilege, short-lived scope, and revocation. The protocol can narrow access, but only if the downstream system enforces the token’s intended boundary consistently.

Practical implication: treat every MCP-connected agent as a scoped NHI and align its permissions with explicit approval and revocation rules.

Structured schemas and prompt injection resistance

Structured schemas constrain what a tool can accept and execute, which reduces the attack surface created by free-form agent instruction following. In practice, a schema acts like an allowlist for permitted operations, data shapes, and parameter ranges. That helps when prompt injection tries to steer an agent into calling unexpected tools or submitting malformed requests. But schemas do not solve trust in the surrounding environment. If the tool, server, or binary is compromised, a perfectly valid request can still produce harmful outcomes.

Practical implication: combine schema validation with signed tooling, server integrity checks, and environment hardening.

Elicitation flows and high-risk action checkpoints

Elicitation flows add a pause point before an agent completes a sensitive step, such as sending data, escalating privilege, or changing state. This is important because agent risk often appears at the moment of action, not at the moment of inference. A checkpoint can force confirmation, validation, or step-up authentication before the agent crosses a policy boundary. The limitation is that a pause button is only useful when the action taxonomy is well defined and the system can distinguish low-risk from high-risk work reliably.

Practical implication: define which agent actions require confirmation, then wire those checkpoints into access and change-control workflows.

Threat narrative

Attacker objective: The attacker aims to convert an agent integration into a trusted execution path that can exfiltrate data, alter systems, or widen access at enterprise scale.

1. Entry occurs when an AI agent is connected to enterprise tools with insufficiently scoped permissions or weak trust in the MCP server environment.
2. Escalation follows when the agent inherits broader access than its task requires, allowing it to read files, modify systems, or trigger downstream workflows.
3. Impact occurs when the agent’s actions ripple across business systems, creating data exposure, unauthorised changes, or irreversible operational damage.

NHI Mgmt Group analysis

Authority without containment is the central governance failure in agentic integration. MCP 2.0 is not just about making agents useful, it is about making their authority legible. Once an agent can act on behalf of a user or system, the security problem becomes one of lifecycle control, not model quality. Identity teams should read this as a non-human identity governance problem with runtime consequences, not as a protocol footnote.

Blast-radius control is now a primary design requirement for AI agent governance. The article’s emphasis on authority, reversibility, and pause points captures the right risk lens because agent actions can cross systems in a single execution path. That changes the governance question from 'can the agent do it?' to 'how far can the damage travel if it does?' Practitioners should treat containment as a first-class control objective.

Structured control points are necessary, but they do not create trust in the full stack. OAuth, schemas, and elicitation flows improve discipline at different layers, yet the protocol still depends on the integrity of servers, binaries, and runtime environments. That makes this a broader control-plane issue for identity and cloud teams, not just an application-layer concern. Organisations should assume protocol safety is conditional, not absolute.

Agent governance will increasingly look like privileged access governance with faster decision cycles. The named concept here is agent authority drift, where an agent’s practical access expands beyond the intent of the original workflow. That drift can happen through accumulated permissions, weak offboarding, or poorly bounded tool links. Security programmes need explicit ownership, review, and revocation for agents before the drift becomes normalised.

Protocol evolution is outpacing enterprise control maturity, which creates an adoption trap. Many organisations will deploy agent connectivity first and formal governance later, but the article shows that security posture must precede scale. The practical conclusion is clear: if the enterprise cannot explain, bound, and reverse agent actions, it is not ready to let those agents operate broadly.

What this signals

Agent authority drift will become a recurring programme risk as organisations add more tool-connected AI into production. Security teams should expect a gap between what an agent was intended to do and what it can do once permissions, tools, and runtime exceptions accumulate. The operational response is to treat every new agent as a governance object, not a convenience feature.

The control conversation will shift from model safety to access containment, with identity teams asked to own revocation, review, and escalation paths for agent identities. That makes the intersection with the Ultimate Guide to NHIs , 2025 Outlook and Predictions especially relevant for programme planning. If the enterprise cannot explain where agent authority begins and ends, it is already behind.

MCP-style integrations also sharpen the need for external guardrails such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026. These references matter because they turn a protocol discussion into a measurable governance programme with ownership, testing, and remediation.

For practitioners

• Define agent authority boundaries Map every MCP-connected agent to a named business purpose, then constrain its token scope, tool access, and downstream write permissions to that purpose only.
• Introduce action-specific approval gates Require confirmation or step-up authentication for agent actions that change state, expose sensitive data, or cross system boundaries, and document the thresholds in policy.
• Validate the runtime environment, not just the protocol Check server provenance, sign tools and binaries where possible, and monitor the runtime environment for tampering that could turn valid requests into unsafe execution.
• Build reversibility into high-risk workflows Design rollback, quarantine, and disablement paths before deploying agents into production so a harmful action can be contained before it propagates further.
• Review AI agents as non-human identities Place agent accounts into identity governance, lifecycle review, and privilege recertification processes so ownership and offboarding do not depend on tribal knowledge.

Key takeaways

• MCP 2.0 shifts the problem from AI connectivity to AI authority, which makes governance and containment the primary security questions.
• Identity teams should treat AI agents as scoped non-human identities because broad permissions turn routine actions into enterprise-wide blast radius events.
• OAuth, schemas, and elicitation flows improve control, but only runtime ownership, revocation, and rollback make agent governance operationally safe.

Key terms

• Model Context Protocol: A protocol that connects AI models and agents to external tools and data sources in a standard way. In practice, it determines how an agent discovers capabilities, passes context, and executes actions, which makes the protocol a governance surface as much as an integration layer.
• Non-Human Identity: A digital identity used by software rather than a person, such as a service account, token, certificate, workload, or AI agent. These identities need lifecycle management, least privilege, monitoring, and revocation because they can act at machine speed and often hold persistent access.
• Blast Radius: The scope of damage that follows if a system, identity, or workflow is compromised. For AI agents, blast radius is shaped by access scope, downstream permissions, and the number of systems an action can touch before a human can intervene or reverse it.
• 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.

What's in the full article

Commvault's full article covers the operational detail this post intentionally leaves for the source:

• The STRIVE discussion of where MCP 2.0 fits in the protocol’s release trajectory and what that means for platform adoption.
• Werner Nel’s practical risk lens for evaluating authority, blast radius, and reversibility before enabling agents in production.
• The discussion of residual gaps such as server authenticity, signed binaries, and runtime trust beyond protocol controls.
• The full 20-minute episode context around where MCP 3.0 may go next and what security leaders should prioritise now.

👉 Commvault’s full STRIVE discussion covers the security shifts, remaining gaps, and practical risk lens for agent deployments.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners translate agent and workload risk into practical governance decisions across IAM and security programmes.