Zero-trust architecture for AI agents: principles and implementation

Your security team runs a zero-trust network. Every human user authenticates per session, and every device gets checked. Lateral movement between services needs explicit authorization. Then your engineering team deploys a fleet of AI agents. Zero-trust agent architectures apply explicit verification and least privilege through infrastructure controls introduced in stages, with breach containment built in.

Each one holds production API keys in environment variables and can reach any service without per-request verification. Your zero-trust posture has an agent-shaped hole in it. Zero trust already covers non-human subjects. NIST SP 800-207 counts applications and other "non human entities" as subjects an attacker can coerce.

Gartner predicts 40% of enterprise applications will integrate task-specific AI agents by the end of 2026. In 2025, Gartner's forecast put it under 5%. That is a fast-growing class of network actors for a CISO to absorb.

Agents run code a model wrote seconds ago and pick their own service calls.

TL;DR

• Agents are zero-trust subjects: They hold credentials for service calls and data movement. The program that governs human users has to govern them too.
• Verify explicitly at the egress proxy: Every outbound agent request routed through the proxy gets checked against a domain allow-list and logged. Network position grants nothing.
• Least privilege means scoped reach and scoped secrets: Each agent type sees only the destinations its job requires. Credentials are injected per request, never stored in the environment.
• Assume breach with hardware isolation and credential separation: Treat each sandbox as compromised, run it in its own microVM, and keep secrets outside it.
• Mature in layers: Start with compute isolation and outbound logging. Add deny-by-default egress and credential separation. Per-agent-type policies and anomaly detection come last.

Zero-trust principles mapped to agent architectures

Each zero-trust principle has a direct agent-side enforcement point. Microsoft's model calls for explicit verification and least-privilege access. It also directs teams to assume breach. NIST SP 800-207 expresses equivalent ideas through its tenets. Both framings land in the same place for a zero trust agent architecture.

Verify explicitly: every request, every agent, every destination

For a human user, verification means authenticating the account and checking device posture on each access request. For an agent, the equivalent unit of verification is the outbound network request. Each call gets authorization and credential checks. The proxy confirms the agent is authorized to reach the destination. It then confirms the attached credential is valid and scoped to that destination alone.

Treat the agent's service identity as a first-class policy input, the same way you treat a user account. NIST's policy tenet already counts "artifacts to authenticate automated tasks" as client identity. A policy engine that can't name the calling agent has nothing to decide on. The proxy should reject any request without a recognized agent identity.

Where that check runs decides whether it holds. Enforcement inside agent code depends on the agent behaving, and a hijacked agent won't. An egress proxy moves the check outside the sandbox. However, this protection applies only when traffic is forced through the proxy. Environment-variable proxy configuration alone remains bypassable by compromised code. Log every decision, allowed and blocked, with the agent identity and destination.

Least-privilege access: scope credentials and network reach per agent type

A human user's role grants access to defined resources. For an agent, the role is the agent type. The grant combines a network policy with a credential map. A coding agent gets access to GitHub and npm. It can also reach your CI system. A data analysis agent gets your data warehouse, and neither can reach the other's services.

Credentials follow the same shape. The coding agent's proxy rules inject a GitHub token, and the data analysis agent's rules inject warehouse credentials. Neither sandbox ever holds the other's secrets, or its own. A PR review agent needs GitHub and nothing else.

Grant each agent type only the destinations its task needs. That is what SP 800-207's tenet 3 means by "least privileges needed to complete the task." Start from an inventory built from observed calls. List every external destination each agent type calls today, and that list becomes your first allow-list.

Assume breach: isolate compute, separate credentials, contain blast radius

Assume breach for human users drives segmentation and lateral movement controls. For agents, the assumption should be stronger, since a model writes the code at runtime. NIST's own testing found novel indirect prompt injection attacks raised agent hijacking success from 11% to 81%. Hijacking succeeds often enough that the architecture has to hold when an agent is compromised.

Each sandbox runs its own kernel, so there is no shared kernel to cross into a neighbor. Proxy-based credential injection means there are no secrets in the sandbox to steal. Domain filtering blocks outbound requests to unapproved destinations, as long as the sandbox's tools honor the proxy configuration. After a successful hijack, one sandbox acts inside its own authorized scope.

That containment requires mandatory routing or lower-level network enforcement that prevents direct connections around the proxy. Without it, compromised code can ignore standard proxy environment variables and attempt another route. Treat proxy configuration and network enforcement as separate controls because each protects a different part of the traffic path.

Infrastructure controls that implement zero trust for agents

Principles become controls at the compute boundary, the credential path, the network policy, and the log. Enforce these controls outside the agent's own code wherever possible. Controls that rely on sandbox tools honoring proxy settings require additional network enforcement to prevent bypass.

Compute isolation: microVMs as the trust boundary

Each agent sandbox needs its own kernel and memory space, and microVMs deliver that at the hardware level. Treat every byte inside the sandbox as untrusted. That is the design assumption behind Firecracker microVMs, which give each sandbox a dedicated guest kernel.

Each agent receives a separate guest kernel instead of sharing one attack surface with the fleet. A compromise inside one microVM reaches that sandbox's memory and its authorized destinations. The guest kernel is not shared with neighbors.

Containers make a different trade. They share the host kernel, which leaves that kernel reachable from inside the container. The 2024 runc escape CVE-2024-21626 gave a process access to the host filesystem.

For trusted, human-written services, containers remain the standard and the right choice. For code a model generated seconds ago, the shared kernel is the boundary you can least afford to trust.

Use the sandbox boundary consistently: one agent execution environment should not share a guest kernel or memory space with another agent sandbox. Isolation limits the compute blast radius, but it does not authorize network access or protect credentials by itself. Pair the microVM with external credential storage, mandatory proxy routing, and per-agent-type policy so a guest compromise cannot turn compute access into fleet-wide access. Verify that lifecycle operations preserve separation rather than treating isolation as a one-time launch setting.

Credential separation: proxy secrets injection as least-privilege enforcement

The agent should never hold the secret. A proxy stores credentials centrally and adds them to authorized outbound requests at the network boundary. Sandbox code sends a request without a key, and the destination receives one with it.

Each credential maps to one destination. A GitHub token is injected when the request targets api.github.com. A request to any other host gets no token. Sandbox code contains zero credentials no matter how many external services it calls.

Keep the credential map outside the sandbox as well, so compromised code cannot add a destination, alter an injection rule, or retrieve the stored secret.

The alternative, secrets in environment variables, fails the assume-breach test. Environment variables are "generally accessible to all processes" and can land in logs or system dumps, per OWASP secrets guidance. A hijacked agent that reads its own environment walks away with every key it was given.

Credential injection works alongside request authorization. The proxy needs the calling agent's identity, the approved destination, and the matching credential rule before it adds a secret. Reject requests that lack any one of those inputs, and record which rule was applied without writing the raw credential to the log. This separation also lets teams change or rotate a stored secret without placing the replacement inside an already-running sandbox. The agent continues to request the destination, while the trusted boundary controls which credential, if any, accompanies that request.

Network microsegmentation: per-agent-type domain policies

An outbound domain allow-list per agent type is the agent-side version of microsegmentation. Set egress to deny by default and allow by exception, the posture SP 800-53 SC-7(5) specifies. Applied to agents, the coding agent's segment contains GitHub and the package registries it needs, and nothing else answers.

Enforcement belongs at the egress proxy, outside the sandbox, where agent code cannot edit the rule set. Network routing must also prevent code from bypassing the proxy. New agents inherit their type's policy at creation. A policy change reaches every agent of that type at once, with no redeployment.

An agent team files a ticket naming the destination and the workload. Security approves it. The domain then enters the type's allow-list through the normal review. Block and log by default. Every blocked request is worth investigating, since a well-scoped agent should never hit a denied host.

A domain entry grants reachability, while the service identity and destination-specific credential rule limit authority at the domain. Keep domain policy paired with the service identity and destination-specific credential rule so access to an approved domain does not automatically expose every account or operation available there. Review wildcard entries carefully because they enlarge the segment beyond one named domain. When a blocked request is legitimate, update the centrally managed type policy through review. Local sandbox exceptions prevent inheritance and security auditing.

Continuous monitoring: egress logging as the verification record

Zero trust requires continuous verification, and for agents the egress log is that record. Each entry should capture the agent identity, destination, timestamp, credential rule applied, and response status. Inspect and log all agent traffic, per SP 800-207. Capture metadata where you cannot decrypt the payload.

The log proves policy is being enforced in real time, which is what an auditor asks for. It also feeds anomaly detection. An agent contacting a domain it has never called before is one trace of hijacking. A sudden jump in request volume is another. Retain both allowed and blocked decisions so investigators can reconstruct the agent's outbound activity and identify attempted policy violations.

A NeurIPS 2025 workshop study found 21% of agent trajectories contained insecure actions. The NeurIPS workshop study covered more than 12,000 actions from five frontier models. That rate is too common for manual review to catch.

How to mature zero-trust agent infrastructure

Implementing all these controls at once can stall on policy work. Move from isolated critical workloads toward just-in-time and just-enough connectivity. Follow the CISA Zero Trust Maturity Model. Start where your fleet is and add one layer at a time.

Isolate compute and log outbound traffic (Level 1)

Run every agent sandbox in its own microVM before anything else. Higher-level controls depend on the sandbox being a real boundary. An escape to the host makes the proxy irrelevant.

At the same time, turn on outbound logging for all sandbox traffic without blocking anything. Record the destination host, the agent type, and the timestamp on every outbound call. Run the baseline long enough to capture recurring activity. Monthly dependency refreshes and scheduled jobs need to appear before you flip to deny.

Expect surprises in the baseline. Package managers pull from mirrors you didn't list. Each of those is a policy decision you'll make at Level 2, made from observed traffic rather than documentation. Level 1 ends with a hardware boundary under every sandbox and a traffic baseline per agent type.

Deny egress by default and separate credentials (Level 2)

Convert the Level 1 baseline into allow-lists and flip egress to deny by default. Everything legitimate gets an entry, everything else is blocked and logged. Then move credentials from environment variables into the proxy's secret store, one injection rule per authorized destination. Ship the two changes together. An allow-list without credential separation still leaves a stolen key usable from any sandbox that can reach it.

You can assemble this yourself on AWS, Google Cloud, or Azure. Use a proxy backed by a secrets vault and domain-filtering egress firewall. Blaxel, the perpetual sandbox platform, offers domain filtering and proxy secrets injection as built-in networking features. Domain filtering sets allowed and forbidden domains per sandbox, with wildcard support. Proxy secrets injection resolves {{SECRET:name}} references server-side, so the raw key never reaches the sandbox. Both run on microVM isolation.

Level 2 ends with agents that reach only authorized destinations, and credentials that never sit inside the sandbox.

Segment policies by agent type and detect anomalies (Level 3)

Split the single allow-list into one policy per agent type. A compromised coding agent then has no route to the data warehouse. The coding agent's list and the data analysis agent's list should share almost nothing. Each type carries only the destinations its workload needs. The Level 1 baseline pays off again here, since you already know which type generated which traffic.

Then put detection on the egress log. Flag an agent contacting a domain it has never called or a spike in outbound volume. Include traffic to allow-list entries added in the past week in the same alert set. Export the log to your security information and event management (SIEM) platform. Agent traffic then correlates with the identity, endpoint, and cloud signals your team already watches. Deviations land in the same queue as human and endpoint alerts.

How zero trust for agents fits your existing security program

These controls fit inside frameworks your compliance team already audits and processes your platform team already runs.

Mapping to existing compliance frameworks

Existing frameworks already cover these controls.

• SOC 2: Agent network controls fall under CC6.1. The 2017 Trust Services Criteria requires "logical access security software, infrastructure, and architectures over protected information assets." Domain allow-lists and proxy credential injection are that control for agent workloads. The egress log maps to CC7.2's anomaly-monitoring requirement.
• ISO/IEC 27001: 2013 certificates expired on October 31, 2025, so use the 2022 numbering. Per-agent-type policies fall under A.5.15 (access control) and A.8.22 (segregation of networks). Credential injection lands in A.5.17 (authentication information), domain allow-lists in A.8.23 (web filtering), and egress logs in A.8.15 (logging).
• HIPAA: For workloads near protected health information (PHI), 45 CFR 164.312 requires access controls and audit controls. Credential separation and outbound domain control keep PHI from leaving through an agent-initiated request. The egress log can support HIPAA audit controls, but logging alone does not establish compliance with the HIPAA audit-control standard.

Organizational ownership and policy governance

Ownership is shared across the responsible teams. The platform engineering team defines the default policy for each agent type. The security team reviews and approves changes. Individual agent teams request exceptions through a tracked process; approved changes reach the allow-list through policy governance.

Gartner's survey of 335 identity and access management (IAM) leaders found IAM teams responsible for 44% of machine identities. The rest sits outside IAM ownership. Agent policies can drift under that split.

Policy as code makes the split enforceable. Network policies live in version control and change through reviewed pull requests. They deploy through your existing infrastructure pipeline.

Add agent policies to your quarterly access reviews. Perform quarterly validation of active accounts as the minimum cadence. Treat an agent type's allow-list as an access-control account. Each review should confirm allow-lists still match observed traffic and remove exceptions nobody can justify.

Extend zero trust to your agent fleet

Agents hold production credentials and call services without a human in the loop. A zero-trust program that excludes them leaves a rapidly growing class of network actors outside its controls.

Blaxel implements these principles as platform capabilities for agents that execute code. Blaxel Sandboxes run in microVM isolation. Proxy secrets injection keeps credentials out of the sandbox, and domain filtering controls which external domains a Blaxel Sandbox can reach, while proxy routing is configured separately. Every proxied request carries a request ID through the sandbox proxy for tracing outbound calls.

Talk to the team at blaxel.ai/contact or start building at app.blaxel.ai.

FAQ

How is zero trust for agents different from zero trust for users?

Users usually arrive through an interactive login and bring device posture, session, and role signals. Agents may run unattended, generate code at runtime, and make many service calls in one task. The policy object therefore shifts to the agent's service identity, sandbox boundary, destination, and credential rule, with every outbound decision recorded for later investigation.

Can I implement zero trust for agents incrementally?

Yes. Pilot one agent type whose destinations are well understood. Before expanding, test that direct connections cannot bypass the proxy, blocked calls fail safely, logs identify the responsible agent and destination, and credential changes do not require placing a replacement secret inside the sandbox. Promote the controls to additional agent types only after the pilot has clear owners for denied requests and a documented path for reviewing legitimate exceptions.

Does zero trust for agents require a separate security team?

Existing teams can enforce separation of duties. Document who may propose, approve, deploy, and audit agent-policy changes, and ensure the requester cannot independently expand the workload's network reach. Assign an owner for alert triage and an escalation path for blocked production traffic, then incorporate those responsibilities into the operating processes your platform, security, IAM, and compliance functions already use.