Least Agency Principle

Definition

The Least Agency Principle extends the classical principle of least privilege to include autonomy as an independently governable security dimension. It states:

Only grant agents the minimum autonomy required to perform safe, bounded tasks. It is no longer sufficient to control what an agent can access; organizations must also control how much freedom it has to act on that access without human oversight.

The principle is introduced in the OWASP Agentic AI Top 10 (2026) as a core design principle for agentic systems, and operationalized in the risk classification tier model below.

Anchor terms — agency vs autonomy

The two terms have distinct definitions, formalized in the AWS Agentic AI Security Scoping Matrix (Brown & Saner, 2025-11-21):

  • Agency — the scope of actions an AI system is permitted and enabled to take within the operating environment, and how much a human bounds an agent’s actions or capabilities.
  • Autonomy — the degree of independent decision-making and action the system can take without human intervention.

The wiki uses the terms with these definitions throughout. Agency is the what (allowed actions); autonomy is the how independently (decision-making latitude). A system can have high agency and low autonomy (broad permissions but every action approved) or low agency and high autonomy (read-only but decides freely within that scope). Because the two axes are independent, “least agency” — the principle of this page — implicitly governs both.

Why Autonomy is a Distinct Dimension

Traditional access control (RBAC, ABAC, least privilege) governs what an entity can access. For deterministic systems, access scope and action scope are essentially the same: a user with read access to a file can read it; no more.

For AI agents:

  • Access scope and action scope decouple. An agent with read access to all email can autonomously summarize, forward, draft replies, archive, and flag — none of which requires additional access permissions but all of which can cause harm.
  • The agent’s action selection is influenced by its inputs — emails, documents, web content — which may be adversarially crafted. Even well-scoped access becomes a risk when action selection is non-deterministic.
  • Autonomy amplifies access. An agent with read-only access to financial data can cause significant harm by autonomously sending that data as email attachments, even if it cannot write to financial systems.

The Risk Tier Model

Operationalized in practice as a four-tier action classification:

TierApproval RequiredExamples
Low riskAuto-executeRead files, search web, enrich data, look up records
Medium riskNotify humanScale cloud resources, send messages, modify configurations
High riskExplicit human approvalDelete data, financial transactions, modify security groups
ProhibitedNever executeCredential exfiltration, recursive self-modification, unauthorized replication

The tier assignment is done at tool annotation time (CI/CD), not at runtime by the model. This is the CI-time tool annotation primitive — equivalent to the containment layer’s human-in-the-loop control.

Relationship to Traditional Security Controls

Traditional ConceptLeast Agency Extension
Least privilege (access)Least agency (autonomy over actions with that access)
Role-based access controlRisk-tier-based action control
PAM / human approval flowsHigh-risk tier requiring human confirmation
Blocked operations listProhibited tier — hard block regardless of model output

The prohibited tier corresponds to the platform-level vs. prompt-level security principle: prohibited actions must be blocked at the platform/runtime layer, not by prompt instruction. A model instructed to never exfiltrate credentials can be injected to do so; a platform-level block cannot be bypassed by the model.

Implementation Patterns

  1. Tool annotation at CI/CD: annotate each tool the agent can invoke with its risk tier before deployment. This is static analysis, not runtime policy.
  2. Runtime tier enforcement: when the agent selects a tool call, the risk tier determines the execution path (auto / notify / confirm / block).
  3. Scope narrowing for sub-agents: in multi-agent systems, child agents should inherit a tier threshold no lower than their parent’s. A high-risk action cannot be delegated to a sub-agent to bypass human approval.
  4. Human-in-the-loop flows: the high-risk tier requires a working HITL mechanism — not a logging call. The primitive is: pause execution, present the intended action to a human, resume only on explicit approval.
  5. Prohibited tier is absolute: no LLM reasoning or tool instruction can override a prohibited action. If the runtime receives a tool call for a prohibited action, it blocks and alerts — it does not ask the model to reconsider.

Connection to OWASP ASI

The least agency principle directly addresses multiple OWASP Agentic AI Top 10 categories:

  • ASI02 (Tool Misuse): tier classification limits the damage scope of compromised tool selection.
  • ASI08 (Cascading Failures): auto-execute tier bounding limits how far a single bad decision propagates.
  • ASI09 (Missing Guardrails): the prohibited tier is the implementation of a behavioral guardrail.
  • ASI10 (Rogue Agents): high-risk tier requiring human approval prevents a rogue agent from taking irreversible actions autonomously.

Organizational counterpart: distributed kill switch

Distributed Kill Switch is the organizational counterpart to the technical block tier. The technical layer enforces blocks based on annotation; the organizational layer empowers any human in the loop to invoke the block at runtime, downgrading the agent mid-run. Both are needed: the annotation is preventive (the action class can never happen), the kill switch is reactive (this specific run goes wrong, anyone can stop it). Per Gartner’s Scaling Agentic AI talk, distributing halt-authority across the workforce is the difference between governance and a single CIO standing alone with a kill switch.

See Also