Zero Trust for AI Agents: Practical Principles

Quick answer: Zero trust means "never trust, always verify" — every request is authenticated and authorized regardless of where it comes from. For AI agents the principle maps directly: every credential request is verified against the agent's access policy, scoped to what it actually needs, and logged — whether the request comes from a trusted internal network or not. No implicit access, no inherited permissions, no "the agent is already running so it must be fine."

What zero trust means in human IAM

Zero trust originated as a network security model in response to a simple observation: "inside the network" is no longer a meaningful trust boundary. A VPN-connected laptop could be compromised. An internal server could be running malware. Treating network location as proof of identity is a category error.

The zero trust answer is to move authentication to the identity layer: every request must be authenticated, regardless of where it originates. An employee on the corporate network still has to authenticate to internal services. A server in the private subnet still has to present credentials to reach the database. Network position grants nothing on its own.

The three core properties:

• Verify explicitly — authenticate and authorize on every request, not just at login
• Least privilege access — access scoped to what the task actually requires, nothing inherited
• Assume breach — design for the assumption that something in the environment is already compromised; limit blast radius accordingly

Why AI agents break the traditional model

Before zero trust, human security relied on a set of assumptions that agents violate by design:

Humans can be challenged. If a request looks suspicious, you send an MFA prompt. Agents can't respond to interactive challenges. If your access model requires a human in the loop to authenticate, it fails for agents.

Sessions establish trust. Human IAM often grants elevated access at login and maintains it through a session. Agents don't have sessions in the same sense — they may run continuously, spawn sub-processes, or be invoked repeatedly by an orchestrator. Session-based trust models either fail or grant persistent elevated access neither of which is correct.

Humans notice anomalies. A person logging in from a new country triggers a review. An agent making unusual API calls may run for hours before anyone notices. Silent compromise is the agent-specific threat model.

Credentials are shared. The most common agent setup is one API key used by multiple agents, pipelines, or services. When that key is compromised, every system using it is compromised simultaneously. There's no isolation.

Each of these assumptions has to be replaced with a control that works without human interaction.

Zero trust applied to agents

The same three properties — verify explicitly, least privilege, assume breach — translate directly:

Verify explicitly: Every credential request the agent makes is checked against its access profile at runtime. Not "this agent authenticated when it started" but "this specific request from this specific agent is authorized for this specific service and operation right now." Runtime verification, not session-based trust.

Least privilege: The agent's access profile defines exactly which services it can reach and which operations it can perform. A deployment agent gets Vercel write access for environment variables. Not "developer access to Vercel." Not "all of Vercel." The specific operations its task requires. See AI agent permissions for how to build these profiles.

Assume breach: Design every access profile assuming the agent will eventually be compromised. That means: scoped access so compromise doesn't spread to unrelated services, fast revocation so you can cut access without rotating credentials everywhere, and audit logs so you know what happened after the fact.

The four operational primitives

Zero trust for agents requires four things in place:

1. Named identity per agent. Each agent has its own identity — a bearer token, an access profile, a name in the audit log. Cursor is a distinct identity from Claude Code, which is a distinct identity from your n8n workflow. Shared keys don't give you this. See IAM for AI agents for why named identity is the prerequisite.

2. Access policy per identity. Each agent's identity is backed by a policy that defines scope: which services, which operations, which environments. The policy is checked on every request, not just at setup time.

3. Runtime enforcement. A layer that sits between the agent and the services it calls — checking the policy, returning a scoped credential or denying the request, and logging the outcome. This is what makes "verify explicitly" a real control rather than a configuration aspiration.

4. Fast revocation. When an agent is compromised, suspended, or done with its task, its access is cut immediately without touching the underlying service credentials. Other agents continue running. This is the "assume breach" control: you can contain a compromise quickly because each agent's access is isolated.

What this looks like in practice

A Cursor agent needs to read GitHub PRs and write Vercel environment variables as part of a deployment review task.

Zero trust setup:

• Cursor gets its own named access profile — not a shared developer token
• The profile allows: GitHub pulls:read, Vercel env:write on the staging project only
• Every API call goes through a credential broker that checks the profile at runtime
• Each call is logged: which agent, which service, which endpoint, timestamp
• Production Vercel access is blocked at the policy level — staging only

If Cursor is compromised via a prompt injection attack:

• The attacker can only reach GitHub PRs and staging Vercel env vars — the scope of the policy
• They cannot reach production, Stripe, the database, or anything else the underlying developer token would cover
• Revoking Cursor's profile cuts its access immediately — the GitHub token and Vercel token are untouched

Contrast with the default setup: one developer API token shared by Cursor, CI, and a deployment script. Compromise of any one of them is compromise of all of them.

The relationship to least privilege

Zero trust and least privilege are complementary. Zero trust is the architecture — verify every request, assume breach, use named identities. Least privilege is a property of each access policy — scope every agent to the minimum it needs.

You can have least privilege without zero trust (narrow permissions, but verified only at setup time). You can have zero trust without least privilege (every request verified, but the access is still too broad). The combination is what closes both gaps: every request verified, every policy narrow.

For a practical guide to building per-agent permission profiles, see least privilege for AI and AI agent permissions.

What zero trust doesn't solve

Zero trust handles the access control layer — it ensures agents can only do what their policy permits. It doesn't handle everything.

Model behavior. An agent with scoped Stripe access can still make unusual API calls within that scope. Zero trust limits what the agent can reach; it doesn't control what the agent chooses to do within those bounds. Approval gates on sensitive operations are the complementary control.

Credential delivery. Zero trust tells you who's allowed to access what. It doesn't specify how credentials reach agents safely. An agent can have a correctly scoped access policy while still receiving credentials in unsafe ways — pasted into prompts, written to shared environment variables.

Prompt injection. A zero trust model verifies that the agent's identity is legitimate and the request falls within scope. It doesn't verify that the agent is making the request intentionally. A prompt injection that convinces an agent to call a permitted endpoint still falls within the access policy. Zero trust limits the blast radius of a successful injection; it doesn't prevent the injection itself.

The right mental model: zero trust defines the boundary. Within that boundary, approval gates, prompt hardening, and output validation manage risk.

Keeping zero trust current

Teams often configure zero trust correctly at setup and then treat it as done. Access profiles need ongoing maintenance because agents evolve. A Cursor agent that started with read-only Stripe access may have had its scope widened incrementally — one write permission added for a task, another for the next — until it's no longer operating at minimum privilege.

Run a quarterly access profile review. For each active agent, ask:

• Is this agent still actively used, or was it created for a task that's long since finished?
• Has scope crept beyond what the current task requires? A profile that started as read-only Stripe and now has write access is a common pattern worth catching.
• Are there services in the profile the agent hasn't accessed in the review period?

The access log answers the last question automatically: which services has this agent actually called in the last 90 days? Services it hasn't touched are candidates for removal from the profile. The review takes minutes per agent and keeps the access surface from drifting silently over time.

Gazebo's security model is built on these four primitives: named agent identities, per-identity access policies, runtime enforcement at the credential broker layer, and one-click revocation. For how this applies to specific agents, see the agents page.