Excessive agency — when an LLM can do too much

Excessive agency is defined by the gap between what the model can do and what the task requires it to do. A model deployed as a read-only FAQ assistant that has been given write access to a customer database has excessive agency: the write access is not required by the task, and its existence means that a successful manipulation can produce database writes the operator did not intend.

The term “agency” here refers to the model's ability to take actions in the world — not to autonomous decision-making in the philosophical sense. A model with tools available to it has agency to the extent those tools allow. Excessive agency is the condition where those tools go beyond what the task scope requires.

OWASP groups excessive agency into three dimensions:

• Excessive functionality. The model has access to tools or capabilities it does not need for its task.
• Excessive permissions. The tools the model uses are granted permissions beyond what the tool's operation requires (e.g., read-write access when read-only suffices).
• Excessive autonomy. The model can take consequential actions without human review — regardless of whether those actions are within the task scope.

Excessive agency is rarely intentional. It accumulates through predictable patterns in how LLM systems get built:

Shared tool manifests. Teams building an LLM application start with a generic tool manifest from a framework or SDK, which includes capabilities for many use cases. They implement the subset they need but do not remove the capabilities they do not use. The unused tools remain in the manifest and are available to the model.

Convenience credentials.The simplest way to give the model access to a data source is to use an existing admin credential. “We'll tighten the permissions later” is a common comment in engineering notes. Later does not come, and the model retains admin-level access to production systems.

Feature creep. A model deployed for one task accumulates additional tools as feature requests arrive. Each new tool is scoped to the new feature but the full tool manifest grows. After several iterations, the model has capabilities that no single feature explicitly requires.

Copied architecture. Agentic system architectures are often adapted from examples and tutorials that show broad tool manifests as examples. Teams adopt the architecture wholesale without auditing the tool manifest against their specific task scope.

The control gap created by excessive agency is proportional to the size of the capability vs task gap: the difference between what the model can do and what the task requires. A larger gap means more attack surface. A smaller gap — ideally zero gap — means that even a fully manipulated model can only cause harm within the task scope.

To measure the gap, a reviewer needs two things:

• The task definition— what the model is supposed to do. This should be a clear, narrow statement: “answer customer questions about product features and pricing using the product documentation knowledge base.” If the task definition is vague, the gap cannot be measured.
• The capability inventory— what the model can actually do. This is the union of: all tools in the manifest, all permissions granted to the model's identity, and all data sources the model can access through retrieval.

Each capability that cannot be justified by the task definition is a control gap finding. The finding is not that the capability will be exploited — it is that the capability represents unexplained, unjustified exposure.

The principle of least privilege is well established in traditional access control: grant each principal the minimum permissions required to perform their assigned function, and no more. The same principle applies to LLM systems, but the implementation is different.

Least privilege for an LLM is not about what the model is allowed to request — it is about what the model can do regardless of what it requests. The tool manifest defines the capability boundary. Capabilities outside the manifest cannot be exercised even by a fully manipulated model.

For LLMs, least privilege has three implementation points:

1. Tool manifest minimisation. Include only the tools required by the task. Remove all others. Review the manifest before each deployment and before any scope change.
2. Permission scoping for each tool. Each tool should be granted the minimum permission required to perform its operation. A tool that reads customer records for lookup purposes does not need write access to those records. A tool that queries a database for product information does not need access to the HR schema.
3. Human approval for consequential actions. Any action with a significant real-world consequence — sending communications, writing to production data, calling external APIs with side effects — requires human approval before execution. This is the autonomy dimension: the model can plan and prepare, but cannot execute consequential actions without human review. This control is independent of how minimal the tool manifest is.

A tool manifest audit is the core evidence-gathering exercise for excessive agency. It requires reviewing each tool in the manifest against the stated task scope and producing a record that justifies the presence (or absence) of each capability.

The audit procedure for each tool in the manifest:

1. Name and describe the tool. What does it do? What real-world actions does it take? What data does it access?
2. Map to the task scope. Which part of the stated task scope requires this tool? If the tool is not required by the task scope, it is a finding.
3. Review the permission grant.What identity does the tool use to take its action? What is that identity permitted to do? Is that permission set the minimum required for the tool's operation?
4. Classify the consequence level.Is the tool's action reversible? Does it have external side effects? Does it access sensitive data? High-consequence and irreversible tools require the human approval boundary control.
5. Check the tool description. Is the description accurate? A description that is too broad, too narrow, or inaccurate affects how the model decides when to invoke the tool — a security issue distinct from the permission question.

The output of a tool manifest audit is a structured record: one row per tool, with task justification, permission assessment, consequence level, and audit decision (in scope / remove / reduce permissions / add approval boundary).

A security review that addresses OWASP LLM08 must produce evidence across three areas: the tool manifest audit, the permission model, and the approval boundary.

• Tool manifest with per-capability task justification — each tool present is justified against the stated task scope.
• IAM or permission policy review for each tool — showing that each tool's identity grant is the minimum required.
• Human approval boundary test — demonstrating that irreversible and high-consequence tool calls are blocked without explicit human confirmation.
• Disposition memo with scope definition — so that any future scope change triggers a re-review of the tool manifest.
• Tool call log sample — showing that all invocations are logged with sufficient detail for post-incident attribution.

The OWASP LLM Top 10 Assessment structures this evidence collection and maps it against the full OWASP risk framework for clearance decision review.