Zero Trust in the Age of AI Agents: Identity, Provenance, and Runtime Controls

Zero Trust in the age of AI agents starts with one uncomfortable truth: the network is no longer the most interesting boundary. AI agents can read documents, call APIs, browse internal systems, open pull requests, run code, trigger workflows, and summarize security data across tools. If those actions inherit broad human privileges or shared service credentials, the organization has not adopted Zero Trust. It has moved old perimeter assumptions into a faster, more automated body.

Classic Zero Trust already gave defenders the right mental model. NIST SP 800-207 defines Zero Trust as a shift away from static network perimeters and toward protecting users, assets, resources, workflows, and accounts. Authentication and authorization should happen before access to an enterprise resource is established, and trust should not be granted just because something is on a corporate network. AI agents make that principle more urgent because an agent can combine identity, data, code, SaaS access, and external tools in one fast loop.

The next version of Zero Trust must treat AI agents as first-class subjects. NIST's 2026 work on software and AI agent identity and authorization is a strong signal: organizations need ways to identify agents, authorize them, audit them, and support non-repudiation when they act. That means a coding agent, SOC copilot, model gateway workflow, or autonomous remediation bot should not hide behind a human user's account. It needs its own identity, its own scoped authority, and its own evidence trail.

For security leaders, the biggest mistake is treating AI governance as a policy document while agents operate through production tools. A written rule that says agents must be careful does not stop a prompt-injected workflow from exporting data, a compromised model gateway key from reaching many providers, or a coding assistant from opening a dangerous change. Zero Trust for AI means putting policy enforcement points in the path: model gateways, identity providers, API proxies, repository rules, CI/CD controls, EDR, data-loss controls, and approval workflows that can deny or step up access in real time.

CISA's Zero Trust Maturity Model is useful here because it frames Zero Trust through pillars such as identity, devices, networks, applications and workloads, and data, with visibility, analytics, automation, orchestration, and governance cutting across them. AI agents touch all of those pillars. A single agent may use a developer laptop, cloud API, GitHub repository, SaaS ticketing system, vector database, and model provider in one task. If those systems do not share enough telemetry to reconstruct the action chain, incident response becomes storytelling instead of evidence.

The AI-era Zero Trust control stack should start with identity. Give every agent a unique identity, separate it from the human who launched it, and bind permissions to the business purpose of the workflow. Use just-in-time access, short-lived tokens, phishing-resistant authentication for humans, workload identity for machines, and explicit approval for actions that touch production, secrets, customer data, source code, deployment pipelines, or financial systems.

The second control is context. Traditional access decisions ask who, what device, what resource, and what risk signal. AI-agent access decisions should also ask which model, which prompt or task, which tool route, which data classification, which repository, which environment, which approval, and which downstream action. A read-only summarization task should not silently become a write-capable production change. A customer-support agent should not suddenly query source code. A code-review agent should not gain cloud-admin authority because it discovered a deployment script.

The third control is provenance. In human-only systems, logs often answer who logged in and what endpoint they touched. In agentic systems, logs need to answer what the model saw, what tool it called, what command it ran, what file it changed, what token it used, what artifact it produced, who approved it, and whether the final action matched the authorized intent. Without provenance, a future AI incident can look like a blur of normal automation, API traffic, CI jobs, and SaaS clicks.

The fourth control is runtime containment. Security teams should assume some prompts will be hostile, some packages will be compromised, some credentials will leak, and some agent workflows will make unexpected choices. The answer is not to block every AI tool forever. The answer is to run agents inside narrow lanes: sandboxed execution, controlled egress, scoped repositories, brokered secrets, human approval for irreversible actions, rollback paths, and continuous monitoring that can revoke access mid-session when behavior changes.

A practical Zero Trust architecture for AI agents has a simple pattern: identity provider for humans and agents, model gateway for routing and policy, secrets broker for short-lived credentials, tool registry for allowed actions, policy engine for authorization decisions, audit pipeline for provenance, and response automation for revocation. The important part is not buying one magic product. The important part is making sure every agent action crosses a control point where the organization can ask: should this actor, in this context, be allowed to do this action right now?

Security teams can start this week with a five-step checklist. Inventory AI agents and coding assistants. Assign each agent an owner and identity. Separate read-only from write-capable workflows. Route model and tool access through auditable gateways. Run a tabletop exercise where an agent is prompt-injected, a token is stolen, or a workflow tries to modify production. If the team cannot answer what happened, what was touched, and how to revoke access, the Zero Trust program is not ready for AI-speed operations.

The future of Zero Trust is not zero AI. It is trustworthy AI operation. Enterprises will use agents because the productivity and defense gains are real. But the organizations that win will not be the ones that let agents roam with inherited privilege. They will be the ones that make every agent prove identity, purpose, context, authorization, and provenance before action, during action, and after the incident review.