Agentic AI

Zero trust AI agent control: identity, authority and evidence

By Gamut Assure · Updated 14 October 2026

When AI systems become agents, the governance question changes. The issue is no longer only what the model says. It is what the agent can do.

Agents are operational actors

An agent may call tools, retrieve records, write code, trigger workflows, access data or make recommendations that influence people and business processes. That means each agent needs identity, ownership, boundaries and evidence.

Zero-trust principles for agents

• Register every agent and assign accountable owners.
• Separate agent identities from human users and ordinary service accounts.
• Define tool permissions before the agent can act.
• Limit data access based on business purpose and sensitivity.
• Require human approval for high-impact or irreversible actions.
• Log runtime decisions so actions can be reviewed.

Why runtime control matters

Traditional assessments happen before deployment. Agentic workflows also need runtime decision points. A Gateway-style layer can evaluate proposed actions and decide whether to allow, block, log or escalate before execution.

Network access and action authority answer different questions

An agent needs a verified identity and an authorised path to a service. It also needs permission for the particular operation it wants to perform. An encrypted connection does not, by itself, authorise a database export, a payment or a configuration change. A useful design checks both the connection and the proposed action before the protected resource is used.

For example, an operations agent may be allowed to read service health but require independent approval to roll back a production checkpoint. The same agent and tool service can be involved in both requests; the action, target and consequences determine the required authority. An explicit policy denial must remain a denial even when someone offers to approve the request.

Bind permission to the exact action

A broad instruction such as “maintain this system” is not enough to establish execution authority. The policy decision should identify the agent, tool, action, target resource and relevant arguments. Where human approval is required, the approver should see that same scope. Changing the destination or payload after approval should require a new decision.

Bounded delegated authority can cover routine work without sending every read request to a human. Its limits still need to be explicit: which resources, which operations, under whose authority and for how long. Approval is a distinct route for requests outside that standing scope; it is not a general exemption from policy.

Child agents need their own boundaries

Spawning a helper agent should not create an untracked actor that shares unrestricted parent credentials. Record the child’s identity, owner and relationship to the parent. Give it only the authority required for its task, within the parent’s permitted scope. Review what happens when the task ends, the parent loses authority or an administrator revokes access.

This matters in multi-agent workflows where a planner delegates research, coding or operational tasks to specialists. Delegation should make responsibility more traceable, not make it harder to identify which agent performed a consequential action.

Place enforcement where bypass can be prevented

A governance interface can record a policy without enforcing it. The execution path must make the required decision unavoidable for protected operations. Tools, credentials and registered resources should not remain available through an unrestricted alternative route that an agent can use when the governed route refuses a request.

For resources on a host, that means checking the permitted operation at the protected resource boundary as well as controlling access to remote services. It also means treating policy unavailability or missing identity information as a reason to stop protected execution rather than silently falling back to a direct connection.

Questions to ask before deploying an agent

1. Can we identify the individual agent and its accountable owner?
2. Which tools and resources can it use, and which exact operations are permitted?
3. Can it reach those resources or credentials through another path?
4. What requires human approval, and is that approval bound to the proposed action?
5. What authority can it delegate to a child agent?
6. What happens when identity, policy or approval information is unavailable?
7. Can we revoke authority and explain the outcome from retained evidence?

Explore governed execution with Gamut

Managed Agent Control brings central policy, agent identity, scoped authority and runtime assurance into the execution path. Bring Your Own Agent applies that governance model to agents you already operate. The interactive simulation illustrates delegated authority, human approval and a prohibited action using synthetic scenarios.

For the underlying architecture principles, see NIST SP 800-207: Zero Trust Architecture, which describes resource-focused access without implicit trust based on network location. For the network overlay, see the OpenZiti introduction. These references explain architectural concepts; they do not certify a particular product or deployment.