Definitions: Excessive agency and least privilege

Covers: Definitions; Capability graph; Results; Design rules; Interview questions, with the follow-ups; Common mistakes; What the example does not do.

Definitions

Excessive agency, least privilege

Excessive agency: an agent holds functionality, permissions or autonomy beyond what its task needs.
Least privilege: grant only the access required for the task, for the time required.

Blast radius, capability

Blast radius: the damage one compromised component can do.
Capability: a concrete ability (read this record, refund up to this amount, run this command).

Attenuation, deny by default, escalation

Attenuation: deriving a grant that is a subset of its parent.
Deny by default: no matching grant means no.
Escalation: using one capability to obtain another.

Capability graph

Escalation edges from a general shell to the database credential; a read-only grant reaches nothing.

Results

Design	Grants	Worst case, 20 attempts	Random compromise	Reachable by escalation	Legitimate tasks done
One service account	everything	27,187	23,587	9	100%
Scoped tools	read customers, refund cap 500, internal email	4,530	2,196	2	100%
Per-task grants	customer 3 only, 3 reads, one refund up to 50, expiry	53	31	1	88%

Worst-case and random damage, escalation reach and utility for the three designs.

Scoping the tools cut worst-case damage about sixfold; per-task grants cut it by another two orders of magnitude in this model.
Money caps and use counts bound damage even when the credential works.
The remaining risk is the legitimate path: a refund of up to 50 to the wrong customer is still possible, and approval or review covers that.

Design rules

One credential per task, short-lived, issued by a component outside the model, not a shared long-lived service account.
Never hand an agent a general shell or file system when a narrow tool will do.
Cap money, volume and rate per grant and per session; count uses.
Attenuate when delegating: a sub-agent gets a subset, never the parent's full set.
Map escalation paths (config, secrets, role assignment) and remove the edges.
Separate read tools from write tools, and put external communication behind its own grant (module 1).
Approval for what caps cannot bound (irreversible, high-value, new recipient): module 5.
Log every authorisation decision, including denials, to detect probing (module 9).
Review grants like code: an agent's tool list is a security-relevant change.

Interview questions, with the follow-ups

How do you limit the damage of a compromised agent?

"Least privilege enforced outside the model: scoped, short-lived, per-task credentials with caps on amount and uses, narrow tools instead of a shell, no escalation paths, and approval for irreversible actions. In my simulation moving from one service account to scoped tools cut worst-case damage from about 27,000 to 4,500 units, and per-task grants to 53." Follow-up: "What does it cost?" 12 percent of legitimate tasks in my mix needed a refund above the cap and went to approval.

What is excessive agency?

"OWASP LLM06: the agent has too much functionality, permission or autonomy for its task. Typical cases are a general-purpose shell, a database role with write access when only reads are needed, or the ability to act without any check." Follow-up: "Which is easiest to fix?" Functionality: remove tools. Permissions need credential changes; autonomy needs an approval design.

How do you give a sub-agent access safely?

"By attenuation: the delegating agent derives a narrower grant (one resource, fewer actions, a lower cap, an earlier expiry, fewer uses) and the derivation fails if it would be broader. The sub-agent can never exceed its parent." Follow-up: "How is that enforced?" In a token or policy service the model cannot modify, not in the prompt.

Why are caps useful if you also have approvals?

"They bound the damage while approvals are slow, skipped or fatigued (Level 8 module 8). A cap is a hard numeric bound; approval is a human judgement that can be wrong." Follow-up: "How do you choose the cap?" From the loss you can tolerate per incident times the attempts an attacker could make before detection, then check it against legitimate task data.

Common mistakes

One shared admin key for all agents.
A shell tool "for flexibility".
No expiry or use limit on grants.
Trusting the system prompt ("never delete") as a control.
Forgetting escalation: a write-to-config tool that can add roles.
Granting by tool name, ignoring arguments (any recipient, any amount).
Sub-agents inheriting everything.
No monitoring of denied calls.

What the example does not do

No real identity or access system; the grant model is a sketch of the idea.
Attenuation compares glob patterns approximately; a pattern like a/* versus a/b* is not fully analysed.
The attacker is a random or greedy caller, not an adaptive planner who chains tools.
Damage is a single number with money and non-money units mixed by assumption.
The escalation graph is hand-made and small.
Optional real experiment (I did not run this): audit a real agent's credentials and tools, list what each can reach, and recompute the worst case with real damage estimates.

Check yourself

An agent is fully compromised. What decides how much damage it can do? (Its privileges. In the model, one service account had a worst case of 27,187 units, scoped tools 4,530, and per-task grants far less. The damage units are assumptions.)

For the curious Least privilege has a price, so measure it

Per-task grants completed 88 percent of legitimate tasks. The missing 12 percent were refunds above the cap of 50, which belong with a human approval (next modules), not with a wider grant. Also look at escalation: a general shell reached 9 capabilities by escalation in the small graph, scoped tools 2, per-task grants 1.

What you will use daily at work

Practice	What it looks like
Give the specific tool, never a general shell	A shell reaches secrets, config and then admin.
Narrow five ways	Resource, action, amount, time and number of uses.
Deny by default	Anything not granted is refused.
Cap irreversible actions	Approval or a limit, even if the credential allows it.

Draft: confirm how your cloud provider scopes short-lived credentials and whether your tools support per-task grants.

What you must be able to say (one page)

Least privilege is the main control, because it works when the model fails. Grant only the specific tools needed, never general-purpose shells or file system access, and run agents on separate infrastructure. Risk scales with action capability, so an agent that only reads data has a limited blast radius. This is sometimes called the principle of least power: give the model only the tools it needs and guard every operation.
Excessive agency means the agent can do more than its task needs. It is LLM06 in the OWASP Top 10 for LLM Applications 2025; a secondary summary I read on 31 October 2026 defines it as granting an LLM too much control over sensitive actions or tools, through poorly designed integrations and unchecked tool access, with least privilege, monitoring and guardrails as mitigations. I did not read the OWASP page itself. From general knowledge (not re-checked) it is usually split into excessive functionality (tools it does not need), permissions (broader rights than needed) and autonomy (acts without a check).
Blast radius is computable. For one support agent I compared three designs against the same fully compromised agent making 20 attempts from a 28-action catalog (damage in assumed units): one service account worst case 27,187, scoped tools (read customers, refunds capped at 500, internal email) 4,530, per-task grants (one customer, one refund of at most 50, three reads, expiry) 53. A random-attempt compromise averaged 23,587, 2,196 and 31.
Escalation paths matter more than the list of tools. A general shell reaches secrets, files and config; config reaches admin; admin reaches the database credential. In my small capability graph, the one-account design reached 9 capabilities by escalation, scoped tools 2, per-task grants 1.
Grants should be narrow in five ways: resource, action, amount, time and number of uses, with deny by default and attenuation (a derived grant can only be narrower than its parent). My code enforces and tests each.
Least privilege has a utility cost you must measure. Per-task grants completed 88 percent of the legitimate tasks; the missing 12 percent were refunds above the cap of 50, which should go to a human approval (module 5), not to a wider grant.
Autonomy is a privilege too. Irreversible or costly actions need approval or a cap even when the credential allows them.
Honest limits: the catalog, damage numbers and legitimate-task mix are assumptions; the code models grants, not a real IAM system; escalation edges are a small hand-made graph.