Zero-trust security starts with a simple premise: don't assume that anything inside your network perimeter is trustworthy. Every request for access must be verified, regardless of where it originates. The implicit trust of "this came from inside our network" is explicitly removed.

AI agents challenge this model in interesting ways. They operate inside your infrastructure. They use credentials your team provisioned. They're trusted by design. And yet the attack surface they represent is fundamentally different from human users or traditional services.

Applying zero-trust principles to AI agent authentication requires rethinking several assumptions.

Principle 1: Verify explicitly — but agents can't authenticate the way humans do

Zero-trust's first principle is explicit verification: authenticate every access request using all available signals, not just network location. For humans, this means MFA, device posture, and behavioral analytics. For traditional services, this means client certificates, API keys, and IP allowlisting.

For AI agents, the challenge is that they're non-deterministic by nature. An AI agent doesn't have a fixed set of behaviors that can be used as a baseline for anomaly detection. It might make a request that looks unusual simply because the task it's performing is unusual.

The zero-trust response isn't to rely on behavioral verification for agents — it's to enforce verification at credential issuance rather than credential use. Instead of trying to detect anomalous use of a credential, you verify the identity and authorization of the request for a credential, before it's issued.

This is what scoped, just-in-time credential issuance accomplishes: the credential is only issued if the requesting agent identity is known, authorized, and requesting within defined parameters. Anomaly detection moves to the issuance layer, where the signal is clean.

Principle 2: Use least-privilege access — and enforce it cryptographically

The principle of least privilege says every identity should have the minimum permissions needed to perform its function. In practice, this is hard to maintain for AI agents because their function is often loosely defined ("help with billing tasks"), which leads to credentials that are permissive enough to cover anticipated needs plus margin.

Zero-trust enforcement of least privilege requires moving the scope check to the credential itself, not just the IAM policy. When an agent requests a nonce for stripe:read:customers, the credential issued is cryptographically scoped — it can only be used for that operation. Even if the agent's IAM role would theoretically allow more, the nonce doesn't.

This matters because agent behavior is unpredictable. A prompt injection attack that induces an agent to attempt a write operation using a read-scoped nonce will fail at the credential level, regardless of what the agent's underlying role would allow. Scope enforcement in the credential, not just the policy, provides defense in depth.

Principle 3: Assume breach — agents have a larger breach surface than humans

Zero-trust's "assume breach" principle says: design your security posture as if an attacker already has partial access. What's the blast radius? How do you limit lateral movement?

For AI agents, the assume-breach posture requires acknowledging that agent contexts will be compromised. Conversation logs will be accessed by unauthorized parties. Prompt injections will succeed occasionally. Model providers will have security incidents. LLM APIs will be called by unintended principals.

The assume-breach design response for credentials is to ensure that the blast radius of any single compromise is bounded by the credential's lifetime and scope. A nonce that expires in five minutes and only authorizes one specific operation has a near-zero blast radius. An attacker who extracts it from a log can do nothing with it.

Long-lived credentials fail the assume-breach test by construction. When the breach occurs — and it will — the attacker has access to credentials that remain valid until manual revocation. Manual revocation requires detection, investigation, and action, each of which takes time. JIT credentials require none of these: the attacker's window closes automatically.

Principle 4: Verify trust continuously — agent tasks have natural checkpoints

Zero-trust advocates for continuous trust verification rather than authenticate-once-and-trust. For human sessions, this means periodic re-authentication, step-up auth for sensitive operations, and session invalidation on policy changes.

For AI agents, the natural unit of continuous verification is the task. Each task represents a fresh authorization decision: should this agent, performing this task, at this time, have access to this service with this scope?

JIT credential issuance per task implements continuous verification at the most natural granularity. The authorization decision is made at task time, not deployment time. An agent that was authorized yesterday but has been compromised today will fail its task-time authorization check if the compromise is detected before the next task.

Implementing zero-trust for agent credentials: the practical checklist

The security team conversation

When you present an AI agent deployment to your security team, the conversation often goes one of two ways:

Without zero-trust credentials: "We've set up service accounts for the agents with the permissions they need." The security team asks about rotation policy, access review schedule, and what happens if the agent is compromised. The answers — "we rotate quarterly," "access is reviewed annually," "we'd revoke the key manually" — fail the zero-trust test.

With zero-trust credentials: "Agents request JIT credentials scoped to each task. Credentials expire in minutes. Every issuance is logged and attributable to a specific agent identity and task. Compromise of an agent context exposes only expired tokens." This is a zero-trust answer. It passes the assume-breach test. It has a continuous verification story. Security teams can approve it.

Zero-trust for AI agents isn't a new security paradigm — it's the application of principles that security teams already understand, to a new class of compute principal. The infrastructure for it now exists.