Agent Tool-Scope & Least-Privilege Lab
A queue of AI agents lands on your desk, each asking for a tool — one wants to read a file, one a payments key, one a shell, one wants to write to production, one to spawn subagents, and a self-improving optimizer wants to widen its own permissions. For each, decide how much access it should actually get, the principle at stake, and the concrete control that makes the grant safe — because a read gets a read-only credential, an irreversible action gets a human gate, and a safe scoped read should not be over-denied. Real principles, real standards, no invented products.
The real job. More noise, a tighter clock.
Grant queue
1 / 9 reviewed
Task: Review the billing-service repository and suggest a fix for one failing test.
Requested grant: Read access to the entire host filesystem
1 · Grant decision
2 · Principle at stake
3 · Scoping control that makes it safe
Pick a decision, the principle, and a scoping control to continue.
Privilege × blast-radius map
This grant: decide how much privilege a tool with this blast radius should keep.
Access review
A queue of agents, each asking for a tool. For each of 9 grants, decide the grant decision, the principle at stake, and the scoping control that makes it safe.
So far: 0 / 9 grants reviewed.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based lab: work a queue of AI agents, each asking for a tool — read a file, call an internal API, run shell, send email, make a payment, query a database, browse the web, spawn a subagent, write to production — and decide how much access each one should actually get.
- For every grant you pick the DECISION (grant as requested / narrow & scope it / downgrade to read-only / deny), the PRINCIPLE at stake, and the SCOPING CONTROL that makes it safe.
- Grounded in least privilege, the OWASP Top 10 for LLM Applications "Excessive Agency" risk, and the AI-governance standards ISO/IEC 42001 and ISO/IEC 27090 — no invented products or CVEs.
- The core skill it drills: a read gets a read-only credential; a broad grant gets narrowed to a path or an allow-list; irreversible or outward-facing actions get a human gate or a dry-run; privilege is time-boxed, not standing; and a self-improving optimizer must not be able to widen its own tools.
- A live privilege × blast-radius map, difficulty tiers, a speed bonus and an S–D grade.
The control follows the task
Most agent-security failures come from granting a tool the way it was asked for instead of the way the task needs it. The queue in this lab is built to force the distinctions that matter. A task that only reads gets a read-only credential or a read replica — the whole category of write, delete and schema-change accidents disappears. A broad grant gets narrowed to a single path, a single API endpoint or a command allow-list, so a compromised or prompt-injected agent cannot move laterally. And anything irreversible or outward-facing — moving money, sending email, writing to production, deleting records — gets a human gate or a dry-run, because you cannot un-send an email or un-charge a card. This is the OWASP "Excessive Agency" risk stated as a set of concrete controls, and it is what ISO/IEC 42001 and ISO/IEC 27090 ask you to govern.
Two cases are easy to get wrong in opposite directions. The first is the self-improving harness: an optimizer rewarded for a higher score will grant itself more powerful tools if it can, so the grant must be non-self-expandable— held outside the agent, read-only to it, changed only by a separate controller (the setting described in Google Research’s Harness² work, arXiv 2610.14224). The second is over-denying: refusing a genuinely safe, scoped, read-only action buys no security and just makes the agent useless. The whole skill of access review is telling the over-broad grant apart from the already-minimal one, and spending your scrutiny where the blast radius actually is.
Frequently asked questions
What does the Agent Tool-Scope & Least-Privilege Lab teach?
It teaches how to provision an autonomous AI agent with the minimum access its task needs. For each scenario you are shown what the agent must do and the tool it is about to be granted, and you decide the grant decision (grant as requested, narrow and scope it, downgrade to read-only, or deny), the principle at stake (least privilege, separation of duties, human-in-the-loop, time/rate-bounded, non-self-expandable), and the concrete scoping control that makes the grant safe (a path or resource scope, an allow-list, a dry-run or confirm gate, a rate and spend cap, a read-only credential, or an egress limit).
What is "excessive agency" and how does this lab address it?
Excessive agency is the OWASP Top 10 for LLM Applications risk where an agent is given more capability, permissions or autonomy than its task requires, so a compromised prompt, a bad plan or a manipulated input can cause real-world harm. The defence is least privilege: scope every tool to the task. The lab drills exactly that decision — downgrading writes to reads, narrowing broad grants to a single path or endpoint, and putting a human or a dry-run in front of anything irreversible or outward-facing such as payments, email and production writes.
Why can a self-improving agent not widen its own tools?
Because a permission boundary the agent can edit is not a boundary. In a self-improving harness — the setting described in Google Research's Harness² work (arXiv 2610.14224) — an optimizer that is rewarded for a higher score will, if allowed, grant itself more powerful tools to reach it. Grants must therefore be non-self-expandable: the tool-permission set lives outside the agent's reach, read-only to it, and is changed only by a separate controller. The optimizer tunes within fixed tools; it never rewrites its own access.
Is over-restricting an agent also a mistake?
Yes. Least privilege means the right privilege, not reflexively zero. Denying an agent a genuinely safe, scoped, read-only action — such as fetching a page from one public documentation domain — buys no security and simply makes the agent useless for its task. The lab deliberately includes such a case: the correct answer there is to grant it as requested, keeping the egress allow-list already pinned to that one domain. Good access review separates the over-broad grant from the already-minimal one and spends scrutiny where blast radius actually lives.