What is zero trust for AI?
By Identra · Updated
Zero trust for AI applies explicit authentication, least privilege and ongoing authorization to AI applications and agents. Approving an app or completing a login does not grant blanket permission to read data, run tools or act on someone's behalf.
How does zero trust apply to AI?
NIST SP 800-207 rejects implicit trust based on network location or asset ownership. Carry that over to AI and an agent running on your own infrastructure still needs explicit authorization for each resource it touches. NIST's zero trust architecture guidance is the foundation.
The zero trust identity basics hold. Authenticate the actor. Authorize access to the resource. Check again when context changes. What AI adds is software choosing its own next step. Ask an agent to summarize a customer issue and it might walk through Zendesk tickets, a Google Drive folder and a Slack channel before it answers.
So the boundary has to cover what the AI can reach and what it can do. An approved app can still be used through a personal login. A legitimate agent can still attempt something it should not. App approval and a valid token do not cover every action that follows.
What should an AI access decision check?
Who is asking, what they want to do, to what, and under which policy. For agents, also record the owner and whose authority the agent is borrowing. A separate AI agent identity keeps the agent's activity apart from the person running it.
Look at the actual operation and its arguments. Read access to one customer record is not an export of the customer table. Permission to call an MCP server does not cover every tool it exposes, the destructive ones included.
Then enforce where enforcement is possible. Browser controls cover AI accounts and what gets submitted. Endpoint controls cover local files and commands, like Claude Code trying to read a .env file. Identity, SaaS and cloud controls cover credentials, grants and hosted resources. Coverage has to match the paths the workflow really uses.
- Identity: which user, app or agent is asking?
- Authority: what task and permissions justify it?
- Resource: which file, record, service or environment?
- Action: read, write, execute or transfer?
- Context: has the account, device, destination or authorization changed?
How is zero trust different from approving an AI app?
App approval asks whether a service fits a business use. Runtime authorization asks whether this actor can do this thing right now. You need both.
Least privilege is what makes the runtime answer enforceable. Separate read from write, narrow the resources and use short-lived credentials where the service supports them. A broad token is dangerous no matter how narrow the task described in the policy document.
Application
- App approval
- Is this service approved for this use?
- Zero trust on the workflow
- Is access allowed through the account in use right now?
Data
- App approval
- Which data categories may it handle?
- Zero trust on the workflow
- May this actor read or send this specific resource?
Tools
- App approval
- Is this integration approved?
- Zero trust on the workflow
- Is this operation allowed with these arguments?
Changes
- App approval
- Revisited at the next review
- Zero trust on the workflow
- Access reassessed when conditions change
What does zero trust for AI look like in practice?
Say a support agent may draft a reply about a delayed shipment. It can read the assigned ticket and that order's status. It cannot search other customers, issue refunds or send email. A person reviews the draft.
The ticket contains text telling the agent to export customer records to an outside address. That is prompt injection. Even if the model goes along with it, the data service should refuse anything beyond the assigned records, and outbound controls should refuse the destination.
Later the workflow needs refunds. That is a new authorization decision. Show the reviewer the customer, the amount and the operation, and bind the approval to those details. Change the amount and it needs approving again.
How do you implement zero trust for AI?
Pick one bounded workflow that touches sensitive data or changes business records. Map its browser, endpoint and connected service access. Then test whether the controls hold when the model proposes something nobody expected.
With AI agent delegation, each downstream agent gets only what it needs. Handing a task to a sub-agent should not quietly widen access or drop the identity of whoever started it.
- Inventory the workflow's apps, accounts, agents, tools, credentials and data destinations, and give it an owner.
- Define allowed resources and operations. Remove unused grants. Stop sharing admin credentials.
- Enforce authorization outside the model, at the service, tool or execution boundary. A system prompt is not an access control.
- Require approval for chosen sensitive actions, with the exact target and consequence on screen.
- Test denied operations, expired credentials, changed arguments and attempts to route around the expected tool.
- Document how to stop execution and revoke access, and confirm revocation hits the credentials and sessions the agent really uses.
How do you verify that the controls work?
An AI audit trail should connect the request, the agent identity, the delegated authority, the authorization decision and the result. Record the person who started it when you know. For scheduled jobs, record the owner and the standing authorization, without implying the owner approved each action personally.
Get evidence from the service that enforced the rule. An agent saying it stopped proves nothing. Check that forbidden reads returned no protected data and denied writes left the target unchanged.
Zero trust limits what a misused agent can reach. It will not make a wrong answer right, and an authorized action can still be a bad idea.
How Identra thinks about it
Identra gives security teams visibility into AI use across the browser, endpoints and connected identity, SaaS and cloud services. Teams can allow, redirect or block supported browser AI apps by signed-in account, check prompts on the device before they are sent, and check AI agent tool calls on endpoints against policy, with destructive shell commands denied when policy is set to block.
Go deeper: AI security, built on identity
Frequently asked questions
Does zero trust for AI require authentication for every tool call?
Each protected operation needs an authorization decision, but not a fresh interactive login. An existing authenticated session and scoped credentials can carry the identity while each requested action is checked.
Can zero trust prevent prompt injection?
It cannot make a model ignore malicious instructions. Enforced access boundaries stop a redirected agent from reaching resources or running actions it is not allowed to.
Does an AI agent inherit all of its user's permissions?
It should get only what its assigned task needs. A user with broad access is a reason to narrow delegation further.
Does zero trust apply to AI chat tools without agents?
Yes. Which account is used, what data can be submitted and controls on uploads and sharing still matter when the tool cannot act in other systems.
Is human approval enough to secure an AI agent?
Approval helps when the reviewer sees the exact action and target. Pair it with enforced permission limits, because vague approvals and changed requests can authorize more than the reviewer meant.