Least privilege for AI agents as runtime control

You must now demonstrate that your AI agents operate under least-privilege controls applied at runtime, not merely at provisioning, with centralised visibility into every tool call and an auditable record of what was approved and when.

The prompt is an analysis of 23 September 2026 of runtime control and least-privilege enforcement for AI agents, which argues that permission boundaries must shift from static role assignment at creation to dynamic controls enforced during execution. The concrete case is a firewall capability announced for enterprise identity infrastructure that provides central visibility into traffic between agents and external protocol servers, applies policy at the moment of action, and blocks unapproved resources. In our assessment, this development matters because it exposes a gap between stated confidence in agent permissions and actual runtime enforcement: organisations cannot manage what they cannot see, and visibility without policy is incomplete.

Why static permissions at provisioning are no longer sufficient

When you set agent permissions only at the moment of deployment, the actual tools and data sources an agent accesses during execution remain invisible. An agent provisioned with broad access to a set of external servers can call any of them for any task without further constraint. The person responsible for oversight has no record of which resources were touched, in what order, or whether the access matched the intended task. This gap between intended scope and actual behaviour is where least-privilege enforcement fails.

The shift to runtime control means that permissions become a property of the task itself, not a property of the agent's identity alone. An agent can be constrained to call only specific servers, tools and prompts for a specific workflow, with that constraint enforced at the moment the agent attempts the call. If the agent tries to access a resource outside the allowlist, the call is blocked and logged. This requires infrastructure that can see the traffic and apply policy to it.

What concrete controls does runtime enforcement demand?

The vendor's guidance on least-privilege design for agents names four foundational requirements:

• Separate identity per agent — each agent must have its own identity so that actions can be traced to the specific agent and the scope that applied to it, rather than to a shared user account.
• Defined scope in advance — the tasks, tools and data resources an agent is permitted to access must be documented before the agent is deployed.
• Allowlist enforcement at execution — the infrastructure must check each tool call against the permitted list and block calls to unapproved resources.
• Centralised audit trail — every permitted call, every blocked attempt and every policy decision must be logged in a place you can query and review.

How do you know if your allowlists are actually being enforced?

Research reported in September 2026 found that 94 per cent of IT and security leaders surveyed said they were confident their agents did not have excessive access. Yet only about a third of organisations actually check authorisation at the moment of execution, and roughly a third apply least-privilege provisioning at all. The gap between confidence and practice is the problem you must close.

To demonstrate that runtime enforcement is working, you need to be able to show:

1. Identify which model and protocol each workflow uses — document which agent, which external servers, and which protocol version are involved in each task.
2. Record the approved scope per task — maintain an allowlist of tools, resources and prompts the agent is permitted to call for each specific workflow.
3. Capture every execution attempt — log each time the agent tries to call a tool, whether the call was permitted or blocked, and the timestamp.
4. Review and update allowlists regularly — check whether the recorded permissions match what the agent actually needs to do, and remove access that is no longer required.
5. Route sensitive agent configuration through approval workflows — require just-in-time approval and multi-factor authentication for anyone who modifies agent permissions or allowlists.

What does the new infrastructure actually do?

The firewall capability announced in September 2026 provides central visibility into the traffic between agents and external servers. It discovers which servers an agent is calling, applies policy to block unapproved ones, and logs the traffic. This moves the control point from the moment an agent is created to the moment an agent acts. The allowlist becomes a runtime property that can be enforced per task, rather than a static configuration that applies to all tasks the agent might ever perform.

This requires maintenance. If you define an allowlist and then the agent's tasks change, the allowlist must change with it. If it does not, either the agent will lack access to resources it needs, or it will retain access to resources it no longer touches. The allowlist is not a one-off configuration; it is a property you must keep aligned with what the agent actually does.

What remains your responsibility, not the tooling's?

The infrastructure can show you what an agent is calling and enforce policy against it. It cannot decide what the agent should be allowed to call. You must define the scope of each agent's tasks, decide which tools and resources are appropriate for each task, and maintain those decisions as tasks change. You must also decide when to revoke an agent's credentials entirely—for instance, when a pilot ends or a project is cancelled. The tooling carries visibility and enforcement; your professional judgement carries the decision about what is appropriate.