Notifications
Clear all
Topic starter
22/06/2026 9:58 am
TL;DR: AI agents that reach MCP servers inherit human permissions but can still execute privileged tool calls at machine speed, leaving network, identity, and data-loss controls unable to intervene, according to WitnessAI. The governance gap is not the chat model, but the tool boundary where agent intent becomes action and existing IAM assumptions break down.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
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.
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.
Q: What do security teams get wrong about MCP server governance?
A: They often treat discovery as control.
Practitioner guidance
- 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.
- 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.
What's in the full announcement
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- How the discovery layer classifies agents, tools, and MCP servers across IDEs, applications, and custom builds
- How the MCP Catalog scores tools against OWASP and CVE risk classes for approval decisions
- How allow and block lists are enforced across every application, model provider, and custom agent
- How audit records attribute blocked calls back to the user, the agent, and the denied rule
👉 Read WitnessAI's analysis of agentic control at the MCP tool boundary →
MCP tool governance: are your agent controls keeping up?
Explore further
22/06/2026 10:40 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP tool governance is the missing control for AI agents
