Agent Subagent Delegation & Trust Lab
Google Research's Harness² (arXiv 2610.14224) orchestrates delegated work by having an agent spawn subagents — which turns the handoff between a parent agent and its subagent into a security boundary. For each delegation, decide the scope the subagent should get (none, read-only, a narrowed task-scope capability, or full inheritance of the parent), name the trust risk, and pick the controlthat fits — because a subagent must never inherit more than its task needs, and must never become a path to launder a privilege the parent itself does not have. Grounded in least privilege, the confused-deputy problem and OWASP LLM excessive agency. No invented CVEs.
The real job. More noise, a tighter clock.
Delegation queue
1 / 9 reviewed
Export one revenue report · subagent spawn
Proposed: about to hand the subagent its own full production API key.
The parent holds a broad production key; it spawns a subagent to pull a single report and passes the whole key so the subagent "has what it needs".
1 · Scope the subagent should get
2 · Trust risk
3 · Control that fits
Pick a scope, the trust risk, and a control to continue.
Scope × blast-radius map
This delegation: decide the scope the subagent should get, and where it lands on blast radius.
Delegation review
An agent is about to spawn a subagent. For each of 9 delegations, decide the scope the subagent should get, the trust risk, and the control that fits.
So far: 0 / 9 delegations reviewed.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based triage lab: an agent is about to delegate work to a subagent. For each delegation you decide the scope the subagent should get, the trust risk it carries, and the control that fits.
- The framing comes from Google Research’s Harness² (arXiv 2610.14224), which orchestrates delegated work by spawning subagents — which pushes the oldest question in access control down to a new boundary: what authority should cross from a parent agent to its subagent?
- Scenarios cover the real traps: handing a subagent the parent’s full credential, letting a web-browsing subagent also write to prod, spawning unbounded subagent fan-out, passing untrusted content into a subagent that can act, and laundering a forbidden action through a delegated subagent.
- The core skill it drills: a subagent never inherits more than its task needs, and delegation must never become a privilege-laundering path — but a correctly-scoped read-only or narrowed delegation is fine and should not be over-restricted.
- A delegation queue plus a live scope-versus-blast-radius map, difficulty tiers, a speed bonus and an S–D grade.
The subagent gets the task, not the keys
Most subagent-security mistakes come from treating the subagent as a trusted extension of the parent and handing it whatever the parent holds. The scenarios in this lab are built to force the distinctions that matter. A subagent should receive the least authority its task needs: a narrowed, task-bound capability token for scoped work; a read-only scope for untrusted input and pure analysis; and no delegation at allwhen the action is outside the parent's own mandate. Handing over the parent's full credential is privilege inheritance; a browsing subagent that can also write to prod is a confused deputy; untrusted content piped into a subagent that can act is the prompt-injection path; and spawning a subagent to do something the parent is not allowed to do is permission laundering.
Just as important: do not over-restrict. A read-only subagent reading public documents, or a narrowed capability scoped to one approved write, is exactly what good least-privilege delegation looks like — the right call is to log it and let it run, not to block it. Reflexively denying a correctly-scoped delegation pushes people toward the full-admin workaround that is the real danger. The whole skill of this review is telling the over-granted, laundered or untrusted-input delegation apart from the one that is already doing the right thing, and spending your scrutiny where it actually reduces blast radius.
Frequently asked questions
What does the Agent Subagent Delegation & Trust Lab teach?
It teaches how to reason about trust boundaries when an agent spawns subagents to do delegated work. For each delegation you choose the scope the subagent should receive (none, read-only, a narrowed task-scope capability, or full inheritance of the parent), name the trust risk it carries, and pick the control that fits. The lesson is least privilege applied across the delegation boundary: a subagent should receive the minimum authority its task needs, and never more than the parent itself holds.
What is Harness² and how does it relate?
Harness² is a subagent-orchestration approach from Google Research (arXiv 2610.14224) in which an agent decomposes work and delegates it to subagents. That design is useful, but it makes the delegation boundary a security boundary: every time the parent hands work to a subagent, you have to decide what credentials, tools and data flow across. This lab drills exactly that decision. It describes the pattern at a conceptual level and invents no products or vulnerabilities.
What is a "permission-laundering" delegation?
It is using a subagent to perform an action the parent agent is not itself authorized to do — for example a read-only agent spawning a subagent and asking it to delete records. The invariant that stops it is that a subagent inherits at most the parent’s authority: delegation is not an escalation primitive. If an action is outside the parent’s mandate, the right answer is to escalate to a privileged owner, not to delegate around the limit. The lab grounds this in least privilege and the classic confused-deputy problem, and in the OWASP LLM "excessive agency" risk.
Is this a real tool that touches my agents?
No. It is an educational, offline triage exercise with synthetic scenarios. It does not connect to, scan, or touch any system, and it contains no exploit detail — only the architect’s decision of scope, risk and control. It is meant to build the judgement you use when designing or reviewing an agent that delegates work to subagents.