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.
Editorial analysis by NHI Mgmt Group, based on content published by AppSOC: “PointGuard AI”.
Key questions
Q: What breaks when MCP servers are generated without runtime controls?
A: Call volume grows faster than oversight.
Q: Why does MCP increase risk even when zero trust and IAM are in place?
A: Because those controls primarily answer who can access a resource, not whether an agent’s chosen action is appropriate right now.
Q: How do security teams know if an MCP deployment is outside its intended boundary?
A: Look for any server that is reachable beyond its expected network scope, accepts tool calls without strong identity proof, or can act on systems it was not explicitly scoped to touch.
Practitioner guidance
- Define an execution control point for MCP traffic Place policy enforcement at the agent-to-tool boundary so each invocation is evaluated before downstream action occurs.
- Inventory every MCP server and connected tool Create and maintain a live list of MCP servers, the tools they expose, and the permissions each one can exercise.
- Scope tools for the minimum agent task Reduce tool permissions to the narrowest viable action set and remove broad, catch-all entitlements that let agents branch into unrelated operations.
Bottom line: MCP turns AI agents into runtime actors that can reach tools through trusted workflows, which exposes a control gap that identity alone cannot close.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:17 pm
MCP creates an execution-layer trust gap: Zero trust was built to govern access decisions, not to arbitrate whether an AI agent’s action should proceed once a tool call is already in flight. That is why MCP changes the problem space from authorisation to runtime governance. The implication is that identity proof alone no longer tells practitioners whether a request is safe.
A few things that frame the scale:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should teams enforce MCP tool permissions before an agent executes a sensitive action?
A: Teams should evaluate the actual request before execution, not just the OAuth scope or access token. The MCP server or gateway should validate, freeze, and policy-check the proposed call, including recipient, body, and declared intent. If the policy denies the action, times out, or needs approval, the system should stop the send and require a separate approved path.
👉 Read our full editorial: MCP breaks zero trust by shifting control into execution