Notifications
Clear all
Topic starter
24/08/2026 2:01 pm
TL;DR: Agentic AI breaks output-focused governance because agents now plan, call tools, read data, and delegate work with inherited credentials, while MCP sits inside the resulting control gap, according to Trust3. The central failure is that security programmes still assume access is stable enough to review after the fact, but autonomous actions can compose into abuse before review ever happens.
NHIMG editorial — based on content published by Trust3: The CISO’s Guide to Securing Agentic AI and MCP
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams govern agentic AI that can execute IAM tasks?
A: Start by treating the agent as an NHI with bounded authority, explicit ownership, and revocation procedures.
Q: Why do MCP-connected agents create harder access-control problems than chatbots?
A: Because they can turn model output into real actions.
Q: What breaks when least privilege is designed before an AI agent starts working?
A: What breaks is the assumption that the needed scope is knowable in advance.
Practitioner guidance
- Inventory every agent and MCP connection Build a living inventory of agents, tool servers, inherited credentials, and data domains so shadow deployments and unmanaged tool paths are visible before enforcement starts.
- Scope credentials per tool call Replace broad, long-lived tokens with narrow, single-purpose credentials tied to one action and one tool, then revoke them as soon as the task boundary ends.
- Enforce runtime policy before execution Add a policy engine that evaluates each proposed tool call against current purpose, data sensitivity, and server trust before the action runs.
What's in the full article
Trust3's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for enforcing least privilege across agent tool calls and MCP servers
- Detailed logging and audit requirements for prompt, tool call, and agent-to-agent hops
- Operational examples of purpose-based access control and runtime policy enforcement
- Comparative discussion of governance layers for data, MCP, and delegated agent behaviour
👉 Read Trust3's guide to securing agentic AI and MCP →
Agentic AI and MCP governance: are your controls keeping up?
Explore further
24/08/2026 2:01 pm
Output governance is now a control-plane blind spot. Security programmes built to inspect prompts and responses are already behind the operational reality of agentic systems. Once an agent can choose tools and sequence actions at runtime, the risk surface is defined by delegated authority, not by model text. Practitioners should treat action control as the primary governance layer.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an autonomous AI agent causes a security incident?
A: Accountability should rest with the organisation that deployed the agent, the owner of the delegated workflow, and the governance function that approved the operating model. A durable identity chain and decision record are essential, because liability and oversight cannot depend on an invisible or shifting human operator inside the execution path.
👉 Read our full editorial: Securing agentic AI and MCP requires runtime identity controls
