The zero-trust controls federal agencies need for autonomous AI
Federal AI is starting to cross an important line. Agencies are moving from systems that answer questions and generate content to agents that can take action across applications, data and workflows.
The Social Security Administration recently sought industry input on an enterprise AI strategy that includes agentic capabilities and an agency-wide approach to AI. As more agencies explore systems that can act with greater autonomy, the critical question is no longer simply whether an AI system should have access — it’s how much authority that system should have once access is granted, how long that authority should last and how quickly it can be revoked.
Federal zero-trust programs already provide much of the framework for answering those questions. Agencies have spent years strengthening identity, reducing standing privilege and limiting the impact of compromise. Yet agentic AI raises the stakes because autonomous software can move across connected systems far faster than a human user ever could.
The next step is applying zero-trust principles to AI agents as distinct identities with narrowly defined authority and strictly enforced boundaries for what they are allowed to do.
Three controls should anchor that approach.
1. Give every agent its own identity
Zero trust starts with knowing who or what is requesting access.
An agent operating through a user’s existing credentials creates an accountability gap. A log may show that an employee account accessed a system, but not whether the employee initiated the action, an agent acted on the employee’s behalf or the agent took an unexpected route to complete its task.
Distinct agent identities make attribution possible, creating accountability for both human users and agentic AI.
The National Institute of Standards and Technology has been increasingly explicit about this issue. In August, NIST noted that model-level guardrails alone are not sufficient and argued that agentic AI needs a stronger identity foundation. In September, its National Cybersecurity Center of Excellence outlined an effort to demonstrate how AI agents can be identified, authenticated and authorized in a DevSecOps environment.
Authentication should establish which agent is acting and on whose behalf, tracing interactions across multiple steps if need be to ensure that no more authority is given an agent than is intended and required.
2. Tie authority to the task
An AI agent acting for an employee need not inherit every authority that the employee has.
If an acquisition specialist can reach several repositories, an agent assigned to summarize documents in one may need read access to a specific dataset. It does not necessarily need permission to modify records, query unrelated systems or invoke another application because doing so would make the task easier.
Authority should match the task, resource and duration involved.
The underlying identity architecture is moving in the same direction. NIST’s September guidance for federal agencies and cloud providers emphasizes token verification, lifecycle controls, secure-by-design practices and continuous monitoring.
For contractors supporting federal AI programs, this should affect architecture from the beginning. Authentication cannot be the finish line. Teams need to define what authority is being delegated, how long it should last and which systems or actions remain out of bounds.
3. Make enforcement operate at machine speed
Logging and monitoring are essential when one autonomous system may touch multiple applications during a workflow. But visibility alone does not control behavior.
If an agent reaches for a resource outside its role, the request should be denied. If its behavior changes materially, its privileges should be reduced or revoked. If an agent or one of the tools it depends on is compromised, that activity should be containable before it spreads.
This is where agentic AI raises the bar for existing zero-trust programs. Human workflows create natural pauses. Autonomous software does not.
Last month, cybersecurity experts pointed to constrained permissions, monitoring, anomaly detection and containment as practical ways to manage increasingly capable AI systems. The broader shift is toward building identity, least privilege and containment directly into how autonomous agents operate, rather than relying solely on visibility after the fact.
With these protections in place, agents can be granted autonomy — but a bounded autonomy, where supervisory controls that sit outside the scope of the AI system step in and block actions that step beyond the prescribed boundaries.
For contractors, control has to be part of the architecture
For federal contractors, these requirements belong in the architecture from day one. Proposals and technical designs should show not only what an agent can do, but how its authority is bounded when it reaches federal systems and data. Identity, authorization and containment should be considered alongside model selection, workflow automation and data access.
Those controls should extend the agency’s existing zero-trust architectures. Agencies are already building the governance foundation for agentic AI. Industry now has to translate those principles into deployable architectures that preserve autonomy without allowing authority to become open-ended.
An agent should be able to move quickly while remaining inside defined constraints. Its identity should be explicit, its authority narrow and its access revocable at machine speed. Contractors that build those controls in from the outset will give agencies a way to scale agentic AI while preserving the control zero trust was designed to enforce.
Duncan Greatwood is CEO of Xage Security.