Zero Trust for AI Agents: What It Is and How to Set It Up

Older security models assume that once an actor is inside the network, it can be trusted. A person logs in, a service holds a credential, and after that they can move around fairly freely. That worked when the things inside the network were human and slow.

AI agents don't fit that model. An agent is fast, automated, and decides its own next action using a model you didn't write. If you give it access to a data warehouse, a CRM, and a payments system, it can touch anything a person could, much faster, and without anyone reviewing each action first. So the useful question is no longer whether an agent is allowed onto the network. It's what a specific agent is allowed to do, and whether you'd know if it did something outside that.

Zero Trust Architecture is the standard way to handle this. For firms that hold sensitive or regulated data, it's now a baseline requirement.

What Zero Trust means

Zero Trust has four main principles.

Verify every request. Being inside the network doesn't grant trust. Each action has to authenticate and pass an authorization check on its own, every time.

Grant least privilege. Each actor gets only the permissions it needs for the task in front of it. Broad, standing access is removed wherever possible.

Assume breach. Design as if part of the system is already compromised. Segment systems so one failure can't spread, and limit what any single actor can reach.

Log everything. Record every access, action, and tool call in a form you can review later.

These are standard security practices. What's new is applying them to an actor that chooses its own actions at runtime.

Why agents need Zero Trust

A normal integration does one thing the same way every time, and you can read its code. An agent is useful because it can choose an approach you didn't specify, and that's also where the risk comes from.

Three things make agents a Zero Trust problem:

• They act with delegated authority, so an agent working for an analyst can do things the analyst never intended.
• They run model-generated code and tool calls, so the exact instruction being run was written seconds earlier by the model, not reviewed by a person.
• They chain together, so one agent calls a tool that calls another service, and no single permission check sees the whole chain.

The answer isn't to block agents from real systems, because an agent that can't touch anything is useless. The answer is to give it access under Zero Trust rules: scoped, verified, contained, and logged.

How to set it up

Zero Trust for agents is mostly about requirements you put on the layer your agents run in, not a product you buy. Six controls do most of the work.

1. Give every agent action its own identity. Don't let agents share a service account or reuse a person's session token. Each agent, and ideally each task, should have its own scoped identity so that authorization and audit logs point to a specific actor doing a specific job. If something goes wrong, you should be able to say which agent did what, and on whose behalf.

2. Allowlist specific tools. An agent should reach only the tools and endpoints you've explicitly granted. Not "the CRM," but "read these three objects and write this one field." Everything else is denied by default.

3. Keep credentials away from the model. The model that plans the agent's actions doesn't need to see API keys, database passwords, or tokens. Store those in the execution layer and attach them when the call is actually made, so no secret ever appears in a prompt, a log, or the model's context. The model requests an action, and the infrastructure decides whether and how to run it.

4. Run code in a sandbox. Model-generated code has to run somewhere. Run it in an isolated environment with no default access to your network, filesystem, or the internet, and open specific paths only when a task needs them. Treat the code as untrusted, because it is.

5. Gate network access. An agent that can reach any external host can leak data or pull in instructions you never checked. Deny outbound access by default and allow it host by host, only for connections a task actually needs.

6. Log every run so you can audit it. Record every tool call, action, and decision in an open, readable log that your team can inspect, replay, and hand to an auditor or regulator. This is how you show the other five controls worked.

The controls depend on each other. Identity is what the allowlist attaches to. The sandbox is what makes credential isolation hold. The logs are what make the whole thing auditable. If one is weak, the others are worth less.

Where this leaves you

If your firm is trusted with other people's money and data, you can't give agents broad, standing access and hope nothing goes wrong before they prove useful. You set up the controls first, and the agents do their work inside them.

We think of it like a harbor instead of open water. Traffic still moves quickly, but it moves through set channels. Every vessel is identified, every cargo is declared, and nothing gets through before it clears customs. The structure is what keeps the port busy and safe at the same time.

That's what we build for at Port of Context: agents that do real work in real systems, with Zero Trust set up from the start. If you're deciding where agents fit in an environment that can't afford a bad surprise, this is a good place to start.