MCP tool governance is the missing control for AI agents

At a glance

What this is: This is an analysis of WitnessAI’s Agentic Control approach, which argues that AI agent risk concentrates at the MCP tool boundary and that visibility alone does not stop unauthorized agent actions.

Why it matters: It matters because security teams need controls that govern AI agents, their tools, and downstream systems without assuming human-paced review or traditional app-layer inspection will catch misuse.

👉 Read WitnessAI's analysis of agentic control at the MCP tool boundary

Context

AI agent governance fails when the security programme assumes a session can be reviewed before it can act. In agentic workflows, the agent can select tools, call MCP servers, and trigger downstream actions faster than a human approval loop can intervene, which means the control point shifts from conversation content to runtime authorisation at the tool boundary.

For identity teams, the key issue is not whether the session belongs to a real employee. It is whether the agent is operating with inherited permissions, hidden third-party tool dependencies, and enough autonomy to make access decisions that existing IAM, PAM, and DLP controls were never designed to inspect in real time.

Key questions

Q: How should security teams govern AI agents that can call tools directly?

A: Treat tool access as a separate authorisation decision from user login. The agent should only reach approved MCP servers and downstream systems, and those approvals must be enforceable before the call executes. Visibility matters, but the real control is policy at the tool boundary where action begins, not after the session has already done damage.

Q: Why do AI agents create more risk than normal application integrations?

A: They can combine inherited human permissions, third-party tools, and runtime decisions in one session. That means one valid login can fan out into multiple machine-speed actions that traditional IAM and DLP controls may not inspect in time. The risk is not only access, but the agent’s ability to use access in ways the programme never reviewed.

Q: What do security teams get wrong about MCP server governance?

A: They often treat discovery as control. Naming the agent and the server is useful, but it does not stop an unsafe tool from being called. Teams need approval, deny rules, and auditability at execution time, otherwise unreviewed MCP servers become trusted paths into repositories, pipelines, and other downstream systems.

Q: How can organisations tell whether agent controls are actually working?

A: Look for denied tool calls, consistent policy enforcement across applications, and attribution that ties the agent action back to the initiating user. If the team can only see agent activity after the fact, governance is observational rather than preventive. A working model blocks unsafe calls before they reach the target system.

How it works in practice

Why MCP servers change the attack surface for AI agents

MCP, or Model Context Protocol, lets agents connect to tools and data sources in a standard way. That flexibility is useful, but it also means the agent is only as safe as the servers it can reach and the tools those servers expose. If a server advertises read or write access, the agent can inherit that reach at runtime without a separate governance step. The security problem is not just malicious code. It is unreviewed tool authority, third-party dependency trust, and downstream execution that happens inside an authenticated session.

Practical implication: inventory every MCP server and require explicit approval before an agent can reach production-grade tools.

Why inherited human permissions do not equal safe agent access

Many AI agents operate inside a human identity context, so they inherit the employee’s permissions rather than receiving their own bounded privilege set. That creates a false sense of control because the authentication event looks normal even when the agent is about to fan one valid session into many machine-speed actions. Traditional IAM confirms who logged in, but it does not by itself tell you whether the agent should be able to invoke a repository, pipeline, or external tool at that moment.

Practical implication: separate authenticated human access from agent-authorised tool execution and treat them as distinct control decisions.

Tool-boundary enforcement is different from prompt scanning

Prompt scanning can catch obvious malicious input, but agent risk often appears after the model receives tool output or hidden instructions from a document, server, or downstream response. In that case, the harmful instruction is not typed by the user, which means input-only controls miss it. Runtime protection has to inspect both the request and response path and make a decision before the agent acts on the result. Without that boundary control, the agent becomes a trusted interpreter for untrusted context.

Practical implication: place enforcement at the point of tool use, not only at the model prompt or user interface.

NHI Mgmt Group analysis

MCP tool authority is the new governance boundary for agentic AI. The article is right to move the control point away from the chat surface and toward the tool boundary, because that is where agent intent becomes system action. Identity teams have spent years governing logins, roles, and sessions, but agents can hold valid identity and still behave unsafely the moment they touch an unreviewed MCP server. The practical conclusion is that tool reach, not model access alone, must become part of identity governance.

Inherited human permission is not an adequate security model for AI agents. An authenticated employee session does not tell you whether the attached agent should inherit repository write access, production pipeline access, or third-party tool reach. That is a control-model failure, not a visibility problem. Once the agent can act faster than a human can supervise, least privilege has to be expressed at the tool boundary and not inferred from the user’s original entitlement.

Tool vetting without runtime denial still leaves an execution gap. Discovery and scoring improve inventory, but they do not stop a compromised or malicious tool from shaping the agent’s next action. The important governance change is that approval must be enforceable at the moment of use, otherwise review becomes an after-the-fact artifact rather than a control. Security teams should treat every agentic call as a policy decision, not a harmless API lookup.

Agentic control is now a cross-domain identity problem, not a niche AI problem. The same policy logic has to govern employees, chat interfaces, IDE agents, and custom agents because the risk lands at the shared tool boundary. That collapses the traditional separation between human IAM, NHI governance, and application-layer controls. Practitioners should expect agent governance to sit inside broader identity architecture rather than as an isolated AI security feature.

Runtime trust debt is the right named concept for this pattern. The environment accumulates trust debt when an agent can reach unreviewed tools, inherit broad permissions, and act on untrusted context before any security control intervenes. That debt is not paid down by better dashboards alone. The implication for practitioners is that every additional agent, MCP server, and downstream tool expands the amount of runtime trust the programme must actively govern.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For adjacent guidance, see the Guide to the Secret Sprawl Challenge for how sprawl and remediation delays compound across identity programmes.

What this signals

Runtime trust debt: As more teams adopt agentic workflows, the programme accumulates unreviewed tool reach faster than governance teams can catalogue it. That is why discovery must be paired with enforcement, and why a policy that only describes the environment is not enough for production use.

The operational signal is straightforward. When an AI agent can reach a production pipeline through an MCP server, the security team needs controls that act at the same point the tool executes, not a week later in review. That is the same identity lesson visible in broader secrets and workload identity programmes, where delayed remediation turns small exposures into persistent risk.

Teams mapping this space should align their approach to the OWASP Top 10 for Agentic Applications 2026 and to the NIST AI Risk Management Framework where governance, accountability, and runtime controls meet. The next control gap to close is not model access alone, but the boundary where agent intent becomes executable action.

For practitioners

• Map every agent-to-tool dependency Create an inventory of AI agents, MCP servers, and downstream systems, then mark which calls are merely visible and which are actually enforceable at the tool boundary.
• Separate human authentication from agent authorisation Do not assume a logged-in employee can safely delegate their full permissions to an agent. Define a distinct policy for repository access, pipeline actions, and external tool execution.
• Enforce allow and block lists before execution Apply policy at the point where an agent attempts a tool call, so unreviewed MCP servers cannot execute first and get reviewed later.
• Audit agentic calls with identity attribution Record the user, the agent, the tool, and the denied or allowed rule so investigations can trace machine-speed actions back to the initiating identity.
• Test response-side manipulation scenarios Exercise cases where malicious instructions appear in tool output, documents, or upstream responses, because input-only controls will not catch them.

Key takeaways

• AI agent risk concentrates at the tool boundary, where inherited permissions can become machine-speed action without a separate governance decision.
• Discovery and scoring improve visibility, but they do not replace runtime enforcement against unreviewed MCP servers and downstream tools.
• Identity teams should govern agent authorisation separately from human login, because the same authenticated session can produce very different risk outcomes.

Key terms

• MCP server: An MCP server is a tool endpoint that exposes data or actions to an AI agent through Model Context Protocol. In practice, it becomes part of the agent’s runtime trust surface because the agent can call it, consume its output, and act on that output without a separate human decision step.
• Agentic control: Agentic control is the set of policies and enforcement points that govern what an AI agent can do at runtime. It focuses on tool access, execution boundaries, and downstream impact, rather than only on prompt content or post-event monitoring.
• Runtime trust debt: Runtime trust debt is the accumulated risk created when agents can reach unreviewed tools, inherit broad permissions, and act on untrusted context before controls intervene. The debt grows as access is granted faster than governance, making later remediation more expensive and less effective.
• Tool-boundary authorisation: Tool-boundary authorisation means deciding, at the moment of execution, whether an agent may call a tool or system. It differs from ordinary login validation because the control is tied to the action itself, not just the identity that initiated the session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by WitnessAI: Agentic Control and the MCP tool boundary for AI agents. Read the original.