Zero Trust for AI Agents Starts After Login

Zero Trust was built to fix an older assumption: if you were inside the network, you were trusted. Then, Cloud, SaaS and remote work broke that, so security moved toward identity, device checks, MFA, least privilege, and continuous verification.

But now, with agents, the messy bit starts after access. The agent reads a prompt, pulls context, chooses a tool, calls an API, and may trigger a workflow. The login tells you the agent is “trusted”. It does not tell you whether the next action makes sense.

Agents inherit the machine identity problem

Security teams have already seen the quieter version of this with machine identities. Service accounts, API keys, tokens, and certificates are created for a project, granted access, and left running long after the project changes.

That pain is familiar: standing privilege, stale ownership, and logs that only get opened after something breaks.

Agents complicate the old problem with judgment. A service account usually follows code. An agent interprets a goal, reads live context, picks a tool, and decides what to try next.

Security now has to cover every system the agent can reach, and any action it is about to take.

Autonomy decides how much control you need

Gartner’s May 2026 note is useful here because it separates two things that often get blurred: how much autonomy an agent has and how much access it holds.

The combination matters. An agent that summarizes documents needs scoped read access and clean logs. An agent that updates records, writes code, or changes workflows needs approval steps, stronger guardrails, monitoring, ownership, and a rollback path.

Gartner’s autonomy ladder is a good place to start: observe, advise, act with approval, act autonomously. Each step should carry more control because the agent is getting closer to a business action.

That is the Zero Trust shift for agents. Identity tells you who is acting. Runtime context tells you whether the action fits the situation.

The policy decision needs the details security usually loses after login: what data is involved, which tool is being called, what instruction shaped the request, and what system gets touched next.

What security teams should do now

Start with a simple inventory. List the agents already in use, where they run, what they touch, and who owns them.

Group agents by where they show up: coding agents on endpoints, managed agents inside SaaS platforms, custom agents built by internal teams, and personal or third-party agents connected through OAuth.

Classify autonomy. Is the agent observing, advising, acting with approval, or acting on its own? Tie that to data access, tools, allowed actions, owner, and approver.

Use autonomy level as the first control boundary, as suggested below:

Scope privilege by action. Give each action its own policy treatment. Reading a record and deleting a record do very different things to the business.

Put guardrails into the runtime path and treat prompts and retrieved content as untrusted input. Check responses before sensitive data leaves and validate tool-call parameters before execution. Require human approval for high-consequence actions such as record deletion, financial movement, bulk communication, or external API calls.

Make the audit trail useful. You need prompts, responses, tool calls, data touched, policy decisions, to understand the outcome. If the agent behaves unexpectedly, security needs enough evidence to stop the next action and explain what happened.

The architecture has to see the action

Security needs a place to inspect the prompt, response, tool call, data movement, and workflow step while the work is happening.

Cato AI Security for Agents fits that point in the flow. It discovers agent activity, governs tool usage and data flows and keeps audit-ready visibility across tools, APIs, data, and workflows.

The value is in the context around the action. When agent behavior sits next to user, application, network, SaaS, and security telemetry, the investigation starts with evidence. Which agent ran. Who owns the agent. What data moved. Which tool was called.

For leaders, that means cleaner governance across users, applications, and agents. For security teams, it means Zero Trust can follow the agent into the work instead of fading after login.

Start with one workflow

Pick one agent workflow that is already in use or close to production. Map the identity, autonomy level, data access, tools, allowed actions, approval points, logs, and rollback path.

That one exercise will tell you where the gaps are. If you can’t see the action, approve it, stop it, or explain it later, the control is too far away.

Zero Trust for AI agents starts after login because that is where the meaningful decision happens: should this action happen, under these conditions, right now?