Least Agency in AI Agents: Defining the Principle and Enforcing It at Runtime

What least agency means

OWASP's agentic threat-modeling guidance uses the phrase least-privilege agency: grant agents only the tools, data access and action authority needed for the specific task, no more. Least agency is a practical shorthand for that idea. It treats the agent's decision latitude, and not only its access, as something to be bounded.

The failure it addresses is usually called excessive agency. OWASP describes it as an agent being able to take actions across integrated systems that no single human operator would be authorized to execute unilaterally without review. The consequence is a single point of failure: one bad decision, misinterpreted instruction or injected objective can corrupt data, disable services and cause financial harm across every system the agent can reach. Two contributing conditions are unbounded action authority, meaning no cap on the scope or impact of a single decision, and no rollback capability, so mistakes leave permanent side effects.

In practice, least agency has four dimensions. Tools: which tools and MCP servers the agent can use. Actions: what each call may do, such as read versus write and which resources. Autonomy: which actions proceed without review. Scope of interaction: which data and untrusted content the agent can touch or act on.

Least privilege versus least agency

Least privilege remains necessary. It is not sufficient, because a permission is a static grant and an agent decides at runtime how to use it. OWASP makes the distinction explicit: agents with access to multiple high-value systems need strict agency limits, with least privilege applied at the action level, not just at the credential level.

• What it constrains: Least privilege limits identities, roles and credentials. Least agency also limits what the agent may choose to do with the access it holds.
• Unit of control: Least privilege works at the credential or role. Least agency works on the individual action and tool call.
• Typical failure: Least privilege prevents over-broad access. Least agency prevents an agent with legitimate access from taking actions that would need review if a human took them.
• Example: A monitoring or reporting agent should not have write access to configuration or permission systems, even if a shared credential would allow it.
• Relationship: Least privilege is the floor. Least agency adds limits on tools, actions, autonomy and interaction scope on top of it.

What runtime enforcement does and does not cover

Runtime enforcement applies the principle to each interaction as it happens. A policy engine in the execution path evaluates a model call, tool call or MCP request and returns one of several outcomes. Allow lets the call proceed. Redact removes sensitive content, which matters because agents may pass sensitive data as tool arguments without awareness of data classification. Block stops a call outside the task's scope. Rate limit caps repeated calls so one faulty loop cannot compound. Escalate holds the call for human approval.

Escalation needs a defined threshold. OWASP's test for excessive agency gives a starting point: if an action is one that no single human operator would be authorized to execute unilaterally without review, route it to review. Irreversible actions, and actions on configuration or permission systems, are natural candidates. OWASP also expects agents to sit under the same change-management controls as human administrators.

Each control point has limits. A model-call check sees prompts and responses, but the intended action only becomes concrete at the tool call. A tool-call check sees the action and its arguments, but not the reasoning behind it. An MCP-level check governs which servers and tools are reachable, but not what a permitted tool does with an approved argument. Enforcement on individual interactions also does not replace sandboxing, per-agent tool scoping or adversarial testing before deployment. Tighter policy brings tradeoffs too: more blocked calls to tune, and added latency wherever a human must approve.

Evidence follows from the same position. Because the enforcement point sees every call, it can record the policy in effect and the decision taken for that call. That gives you both halves of the audit question: what the agent was permitted to do, and what it did.

How Trussed applies this

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It can allow, redact, block, rate limit or escalate for human approval, enforced at runtime, not reviewed after the fact. Its scope is individual interactions and tool calls.

That enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST and the EU AI Act, along with HIPAA, NAIC and NYDFS. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. It has run continuously in a regulated enterprise for more than 18 months and operates 100+ models under one policy plane.