Why do MCP-connected agents complicate zero trust architecture?

Zero trust assumes continuous verification, but MCP agents can complete multiple actions inside one trusted session. That creates a gap between initial verification and later behavior, so teams need runtime policy checks, telemetry, and revocation that follow the agent through every tool call.

Why This Matters for Security Teams

MCP-connected agents change the trust problem because the identity check happens once, but the execution path continues. A human session is usually bounded by attention and intent; an agent can chain tools, follow prompts, and keep acting after the original approval context has faded. That makes classic zero trust assumptions too static for autonomous software with tool access.

Current guidance suggests teams should treat the agent itself as a workload identity, then re-evaluate risk at each action rather than each login. That is consistent with NIST SP 800-207 Zero Trust Architecture and the agent-specific risk patterns in OWASP Top 10 for Agentic Applications 2026. NHIMG research on OWASP Agentic Applications Top 10 reinforces the same point: autonomy expands the attack surface faster than human-centric access models can absorb.

SailPoint’s AI Agents: The New Attack Surface report found that 80% of organisations reported AI agents had already performed actions beyond their intended scope. In practice, many security teams encounter this only after a harmless-looking tool chain has already crossed a boundary, rather than through intentional testing.

How It Works in Practice

The practical fix is to move from one-time access approval to runtime policy enforcement. That means the agent receives only the minimum authority needed for the current task, with intent-based authorisation deciding whether a tool call is allowed at that moment. For agents, this usually works better than static RBAC because the access pattern is not fixed in advance. The policy engine should inspect context such as task objective, target system, sensitivity of data, time window, and whether the action matches the stated intent.

That approach usually combines three controls. First, issue JIT credentials or ephemeral tokens per task, not long-lived secrets. Second, bind those credentials to a workload identity such as SPIFFE/SPIRE or OIDC so the platform can verify what the agent is, not just what it knows. Third, enforce continuous telemetry and revocation so a tool chain can be stopped mid-session when behaviour diverges. NIST AI RMF supports this kind of governance discipline, and the CSA MAESTRO agentic AI threat modeling framework is useful for mapping where the decision points sit in an autonomous workflow.

NHIMG’s Guide to SPIFFE and SPIRE is especially relevant here because workload identity gives security teams a stable cryptographic anchor even when the agent’s actions vary. The operational standard is still evolving, but the direction is clear: authorise the next action, not the entire session. These controls tend to break down when MCP servers expose static secrets or broad tool permissions, because the agent can inherit more power than the policy layer can meaningfully constrain.

• Use short-lived credentials tied to a single task or bounded objective.
• Evaluate every MCP tool call against live policy, not only the original login event.
• Separate read, write, and escalation paths so one approval cannot unlock everything.
• Log tool intent, target resource, and resulting action for audit and revocation.

Astrix Security reported that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which explains why runtime control matters so much. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs – Lifecycle Processes for Managing NHIs both point to the same lifecycle problem: identity issuance without continuous control is not sufficient for autonomous execution. By the time a session looks suspicious, the agent has usually already completed the risky chain of tool calls.

Common Variations and Edge Cases

Tighter runtime control often increases latency and policy overhead, requiring organisations to balance safer execution against developer friction and operational complexity. That tradeoff is real, especially when agents are expected to act quickly across multiple systems. Best practice is evolving, and there is no universal standard for exactly how much context an authorisation engine should inspect before allowing an agent action.

In high-volume environments, teams sometimes allow broader standing permissions for low-risk read-only tools while reserving JIT elevation for writes, deletes, or external side effects. That can work, but only if the environment has good telemetry and clear separation of duties. Where agents operate across many APIs, shared SaaS tenants, or developer sandboxes, policy drift becomes a major risk because the same tool can be safe in one context and dangerous in another. The NIST AI Risk Management Framework is useful here because it frames governance as ongoing measurement, not a one-time configuration exercise.

For a deeper agent-specific lens, compare AI LLM hijack breach with Moltbook AI agent keys breach. The common lesson is that once an agent can reuse secrets or pivot through permissive tools, zero trust degrades into post-incident detection. The model holds up better when organisations treat every agent action as a fresh trust decision and design revocation to follow the workload, not the user.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do NHIs complicate zero trust and least privilege efforts?
• Why do Active Directory service accounts complicate zero trust programs?
• Why do autonomous agents complicate zero trust architecture?