Notifications
Clear all
Topic starter
06/07/2026 9:37 am
TL;DR: MCP makes it easier for AI models to reach files, tools, and enterprise data, but it also shifts the security problem to runtime authorisation, confused deputy risk, and shadow MCP deployments, according to Reva.AI. The governance gap is no longer about connectivity, but about who can trigger which action, in what context, and with what accountability.
NHIMG editorial — based on content published by Reva.AI: Securing the Model Context Protocol (MCP)
Questions worth separating out
Q: How should security teams govern MCP tool calls in enterprise environments?
A: Security teams should govern MCP tool calls at the moment of execution, not just at connection time.
Q: Why do MCP deployments create confused deputy risk for identity teams?
A: MCP deployments create confused deputy risk because a privileged server can be tricked into doing something the original user never intended.
Q: What do security teams get wrong about shadow MCP servers?
A: They often treat them as developer convenience rather than identity-bearing infrastructure.
Practitioner guidance
- Map every MCP server to an identity owner Create a complete inventory of sanctioned and unsanctioned MCP servers, including developer-hosted instances, then assign a business and security owner to each one.
- Enforce tool-level authorization before execution Require the authorization decision to happen at the tool invocation layer, with the user, agent, tool name, and context evaluated together.
- Separate discovery from trust Detect connected tools and local MCP instances first, then apply differentiated policy by data sensitivity and action risk.
What's in the full article
Reva.AI's full article covers the operational detail this post intentionally leaves for the source:
- A closer look at the intent-aware authorization flow for MCP tool calls and how it intercepts execution.
- Examples of behavioral monitoring thresholds that can trigger alerts or session termination when tool use changes suddenly.
- A discussion of OAuth 2.1 and AuthZEN integration for externalised authorization in agentic environments.
- The article's view of how a centralized control plane can replace ad hoc developer-run governance around MCP.
👉 Read Reva.AI's analysis of MCP tool invocation and runtime authorization →
MCP tool invocation: what IAM and security teams need to know?
Explore further
06/07/2026 9:52 am
MCP tool invocation is now an identity control point, not a transport detail. The security question is no longer whether a model can connect to data, but whether each discrete action is authorized at the moment it is invoked. That changes MCP from a plumbing standard into an access-governance problem that belongs with IAM, PAM, and NHI oversight. Practitioners should treat every tool call as an entitlement decision, not a mere API request.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: Who is accountable when an AI agent uses an MCP tool to expose data?
A: Accountability usually sits with the organisation that allowed the tool path, the server privilege, and the agent behaviour to intersect without adequate controls. In practice, the governance failure is shared across identity, platform, and application teams. The right response is a clear approval model for high-risk tool invocation and auditable ownership for each server.
👉 Read our full editorial: MCP tool invocation is becoming the new enterprise perimeter
