Zero trust for AI agents

Zero trust is an approach to security that does not grant implicit trust solely because an actor or resource is inside a network or owned by the organization. Access decisions focus on the particular resource and the identities and conditions involved.

NIST SP 800-207 describes zero trust architecture in those terms. For AI agents, this means explicitly authorizing access to tools, models, and data, regardless of where the agent runs.

Explore Dome: Access · Docs: Security tutorial.

Define access to each resource

Suppose an agent runs in the same cloud environment as an internal document service. The shared network makes the service reachable. It does not establish which documents the agent should read or whether it may export them.

For each request, verify the agent, the operation, and the permitted documents. If it serves several employees, include verified user identity where access depends on that person's permissions.

The decision can use identity and policy information already established by trusted systems. Document which evidence it relies on; being on the company network is not enough.

Authentication versus authorization explains how identity verification and permission checks work together.

Explore Dome: Access · Docs: Agent identity.

Examine the route and its dependencies

For one document request, identify where the agent authenticates, where the access policy is evaluated, and which component can stop delivery. Also identify the source of document ownership and classification.

A gateway can enforce checks on traffic routed through it. Also review direct backend credentials, alternative routes, inherited service permissions, and dependencies that could affect access.

Credential isolation can reduce secret exposure, while least privilege can narrow the operations available through a credential. Those are supporting practices with distinct jobs, covered in credential isolation and least privilege.

Dome's Access and rules capabilities provide identity and authorization controls on configured paths. Include those controls and any other access routes in the architecture review.

Explore Dome: Authorization · Docs: Authorization model.

Review access to one service

For a hypothetical internal document service, ask:

1. Which agent identities can reach it?
2. What evidence establishes those identities?
3. Which actions and document sets are permitted?
4. Which information must be up to date?
5. What happens when information needed for the check is missing?
6. Can another route bypass the intended check?

Test a valid request, an out-of-scope resource, and a request missing a required fact. Check where and how quickly access is withdrawn when an agent or the person it acts for loses a permission.

Repeat the access tests when the agent gains a new connection or capability, including any new way to reach the document service.

Record the permitted access to each resource so the requirements remain clear even if the agent moves to another network. Runtime policy enforcement explains where to apply those checks. Default-deny versus fail-closed explains what happens when no permission matches or a required check cannot run.

Explore Dome: Authorization · Docs: Security tutorial.