Notifications
Clear all
Topic starter
09/07/2026 3:29 pm
TL;DR: MCP 2.0 adds OAuth, structured schemas, and elicitation flows to govern how AI agents connect to enterprise tools and data, according to Commvault’s STRIVE discussion with Werner Nel. The protocol improves authorization discipline, but blast radius, reversibility, and runtime trust still determine whether agents become controlled operators or enterprise liabilities.
NHIMG editorial — based on content published by Commvault: MCP 2.0 and what it changes for AI agent security
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%).
Questions worth separating out
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.
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.
Q: What breaks when MCP-connected agents are given broad access?
A: Broad access turns an agent into a high-impact execution path.
Practitioner guidance
- 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.
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.
👉 Read Commvault’s analysis of MCP 2.0 and AI agent governance →
MCP 2.0 governance: are your AI agent controls keeping up?
Explore further
09/07/2026 3:49 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: MCP 2.0 shifts AI agent governance from connectivity to control
