Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

MCP governance: what changes when agents can route around controls?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9059
Topic starter  

TL;DR: MCP governance breaks down when code-capable agents can route around a blocked tool path by finding alternate ways to reach the same outcome, such as SDKs, scripts, browser automation, or secrets access, according to Cyera. Tool-level restrictions still matter, but intent-level authorization becomes the real control boundary when agents can search and execute alternatives at runtime.

NHIMG editorial — based on content published by Cyera: The MCP Governance Illusion, why governing tools is not enough

By the numbers:

  • When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

Questions worth separating out

Q: How should security teams govern code-capable AI agents that can switch tools at runtime?

A: They should govern the outcome the agent is trying to achieve, not just the connector it uses.

Q: Why do MCP restrictions fail when agents can use alternate execution paths?

A: Because the restriction only covers one path, while the agent can search for another route to the same result.

Q: What is the difference between tool governance and intent-level authorization for AI agents?

A: Tool governance asks which interface the agent may use.

Practitioner guidance

  • Define policies around outcomes, not connectors Classify the business effects that matter most, such as data export, record modification, external messaging, or access control changes, then authorise those outcomes across every execution path.
  • Map equivalent actions across tool chains Inventory where the same sensitive action can occur through MCP, SDKs, CLI usage, scripts, browser automation, and direct APIs so a single deny rule does not create false confidence.
  • Add intent checks before execution Require agents to present the objective and scope of the action before they can proceed, then evaluate that intent against policy regardless of the tool selected.

What's in the full article

Cyera's full blog post covers the operational detail this post intentionally leaves for the source:

  • The Snowflake example broken down into concrete alternate routes, including SDK, CLI, secrets manager, and browser automation paths.
  • The article's own framing for why tool restrictions become diminishing returns when agents can search for new routes at runtime.
  • The suggested governance model for intent-based decisioning before execution, including where MCP checks still fit.
  • The specific examples Cyera uses for outcomes that should be authorised or denied across every tool boundary.

👉 Read Cyera's analysis of why MCP governance is not enough for code-capable agents →

MCP governance: what changes when agents can route around controls?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8498
 

Tool governance is the wrong abstraction once agents can search for alternatives. Cyera's core point is that MCP restrictions only govern one execution path, while code-capable agents can move to another path that reaches the same result. That is not a tooling problem in isolation, it is a control-design problem for identity programmes that still assume one approved interface equals one contained outcome. Practitioners should reframe governance around equivalent actions, not approved tools.

A few things that frame the scale:

  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
  • Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.

A question worth separating out:

Q: What should teams do immediately after blocking an AI agent tool path?

A: They should validate whether the same action is still possible through adjacent tools, credentials, or automation layers before assuming the control worked. If the action remains reachable elsewhere, the governance decision was too narrow and needs to be rewritten around the outcome, not the blocked interface.

👉 Read our full editorial: MCP governance fails when code-capable agents change the control point



   
ReplyQuote
Share: