Notifications
Clear all
Topic starter
15/08/2026 6:09 pm
TL;DR: AI agents and MCP create an execution layer that sits outside traditional zero trust controls, according to AppSOC, because requests are treated as trusted once they originate from an approved internal workflow. The real gap is not access but contextual decision-making at the moment actions are executed, which means identity alone no longer tells teams whether an action should proceed.
NHIMG editorial — based on content published by AppSOC: MCP Breaks Zero Trust. Here’s How to Fix It
Questions worth separating out
Q: How should security teams govern AI agents that use service accounts and MCP tools?
A: Start with ownership, then add runtime attribution and containment.
Q: Why do MCP and zero trust conflict in agentic environments?
A: They conflict because zero trust primarily answers whether an identity may access a resource, while MCP can turn that access into an execution path.
Q: What breaks when AI agent tool use is treated like normal API traffic?
A: What breaks is the ability to judge intent and impact.
Practitioner guidance
- Inventory MCP servers and connected tools Build a complete list of MCP servers, tool permissions, and agent-to-tool paths.
- Insert policy checks at execution time Enforce contextual approval at the moment a tool call is made, using data sensitivity, workflow state, and system criticality as policy inputs.
- Define ownership for agent actions Assign accountable owners for each agent workflow, each MCP server, and each downstream system the agent can reach.
What's in the full article
AppSOC's full analysis covers the operational detail this post intentionally leaves for the source:
- How its MCP Security Gateway places enforcement directly inside the agent-to-tool interaction layer.
- How runtime guardrails inspect requests and responses in real time before downstream execution.
- How contextual policy enforcement uses business context, asset criticality, and operational requirements.
- How the platform surfaces shadow AI and hidden MCP risk across agents, servers, and connected tools.
👉 Read AppSOC's analysis of MCP, zero trust, and AI agent execution risk →
MCP and zero trust: what changes when agents execute tools?
Explore further
15/08/2026 6:17 pm
Zero trust breaks when the security model stops at access and never reaches execution. MCP does not just connect agents to tools, it creates a trusted path from decision to action. That is a structural problem for IAM and PAM models that were built to authorise requests, not to inspect the meaning of machine-initiated actions. Practitioners need to recognise that the control boundary has moved.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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 AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: MCP breaks zero trust by shifting control into execution
