Zero trust in one paragraph
Zero trust is the security model that removed the perimeter assumption. Instead of “inside the network means trusted,” zero trust holds that no user, device, or workload is trusted by default; every request is authenticated, authorized against policy, and granted the minimum privilege it needs: continuously, not once. Its three working principles: verify explicitly (identity and context on every request), enforce least privilege (access scoped to the task), and assume breach (design so a compromised actor can do limited damage, and audit everything so you can respond). Formalized in NIST’s zero trust architecture guidance and adopted across the industry over the past decade, it is now the default aspiration for human and device access, which is exactly where its assumption breaks, because the newest actors on the network are neither.
Why AI agents break login-time zero trust
Every zero-trust deployment in production today verifies at an access boundary: a login, a connection, a session grant. That model assumes the expensive thing to get wrong is access, and that once a verified actor is inside a session, its individual actions are human-paced, human-judged, and few.
Agents invert every part of that. An agent authenticates once ( often with a human’s delegated credentials) and then takes thousands of actions under that single grant: shell commands, file writes, package installs, MCP tool calls. No human reviews each one. Prompt injection means the agent’s intentions can be hijacked mid-session by content it reads, without any new authentication event for a zero-trust platform to inspect. The session-level trust decision is stale seconds after it is made. For agents, the trust boundary has to be the action: each tool call verified against policy at the moment it is attempted. That is the same “never trust, always verify” principle: relocated to the only checkpoint that still means something when the actor is a non-human identity operating at machine speed.
The four zero-trust controls for agents
Verify identity per session
Every agent session is attributed to a terminal, user, and repo at start: no anonymous actors. The session is the unit of accountability.
Evaluate policy per action
Each tool call is checked against policy before it executes; violations are denied with a stated reason. This is "never trust, always verify" applied at the only boundary agents respect: the action.
Least privilege for tools
Protected paths the agent may not touch, registries it may not install from, MCP servers it may not call: capability allow-lists instead of inherited full access.
Assume breach: audit everything
Every session, action, file change, and install lands in a durable ledger, so when verification fails or an identity is compromised, the trail exists for response.
This is how Nexus implements continuous verification for coding agents like Claude Code: the wrapper hooks the agent runtime, evaluates each tool call locally and synchronously before execution, and denies violations with a stated reason. Enforcement cannot be bypassed by a network failure because the policy check is local; capture is fail-open so telemetry never blocks legitimate work.
Zero trust tools and the AI layer
Zero-trust platforms are not competitors to agent enforcement, they operate at different layers, and organizations running agents need both:
| Layer | What it verifies | Examples | Where it stops |
|---|---|---|---|
| ZTNA / zero trust network access | User + device before reaching an app or network segment | Zscaler, Cloudflare Zero Trust, Palo Alto Prisma | At the connection: no view of what an actor does after access is granted |
| Identity providers / conditional access | Login context: user, device posture, location, MFA | Okta, Microsoft Entra | At authentication: one verification covers thousands of subsequent actions |
| Agent action enforcement | Every individual tool call, file write, and install by an AI agent | Swfte Nexus | This is where it starts: the layer below access, on the machine where the agent acts |
The pattern to notice: access-layer tools answer “may this actor reach this system?” Agent enforcement answers “may this actor do this specific thing, right now?” The second question is the one prompt injection and shadow AI exploit when it goes unasked, and MCP connections multiply the places it needs asking (see MCP security best practices).
Enforce vs. audit: rolling out zero trust without breaking developers
The classic zero-trust rollout failure is turning on blocking before understanding real workflows: developers hit denials on legitimate work, and the program loses its mandate in a week. The agent version of the fix is built into Nexus’s modes: audit mode evaluates every action against policy and records would-have-blocked violations as findings, without denying anything; enforce mode turns the same rules into pre-execution denials. Because modes are set per repository, rollout is gradual: enforce on production-adjacent repos first, audit everywhere else, and promote rules as the findings stream shows them firing only on genuinely unwanted actions. Trust in the policy is itself earned through verification, which is about as zero trust as a rollout can get.
Zero trust and compliance
Regulatory regimes increasingly assume zero-trust mechanics without naming them: DORA and NIS2 expect demonstrable control over privileged access and the ability to evidence what happened during an incident; the EU AI Act adds oversight and logging obligations for AI systems specifically. None of these exempt non-human actors: an action taken by an agent on the organization’s behalf carries the same audit burden as a human’s. Action-level verification produces the evidence layer as a by-product: every allowed and denied agent action, with attribution and the policy reason, in a durable ledger. When the auditor asks how AI agents are overseen, the answer is a query, not a slide. See AI compliance and AI agent governance for the full governance program around this.
Zero trust for AI FAQ
What is zero trust security?
Zero trust is a security model in which no user, device, or workload is trusted by default, regardless of network location; every access request is verified against identity and policy before it is granted. It replaces the old perimeter assumption ("inside the network means trusted") with continuous verification.
How does zero trust apply to AI agents?
Agents authenticate once but then act continuously, so verifying at login is not enough: the zero-trust checkpoint has to move to each individual action. In practice that means evaluating every tool call, file write, and install against policy at execution time, which is how Nexus enforces zero trust for coding agents.
What does a zero-trust policy for an AI agent look like?
It defines what the agent may never do (destructive commands, writes to protected paths like .env files and production infrastructure), what sources it may use (allow-listed dependency registries, approved MCP servers), and what must be recorded (every session and action, with attribution). The policy is enforced synchronously, before actions run.
Can zero trust be implemented for agents without slowing developers down?
Yes: the practical path is to start in audit mode, where policy violations are recorded as findings but not blocked, then switch to enforce mode once the policy fits real workflows. Nexus supports both modes per repository, and its capture layer is fail-open so telemetry never delays the agent.
What’s the difference between a zero trust platform and zero trust for agents?
Zero trust platforms broker access between users, devices, and applications: they verify who can reach what. Zero trust for agents governs what an already-connected actor is allowed to do, action by action, on the machine where it runs. Most organizations need the platform for access and an agent enforcement layer for behavior.
Zero trust that stops at login can’t govern an agent
Nexus verifies every agent action against policy (before it runs) with per-session attribution and a durable audit ledger.
Explore Swfte Nexus