Access reviews start by listing every principal with access. Nested agents break that on the first step, because the principals do not all exist yet. An orchestrator spawns sub-agents at runtime, each inheriting or requesting access, and the list you review on Monday does not describe what will be running on Thursday. That is the tension: access reviews assume a fixed roster, and nested agents are a moving one.
You cannot review what you cannot enumerate. So the question becomes how to review access that materializes dynamically and disappears again.
Why nested agents defeat a static review
- Runtime spawning. Sub-agents appear in response to a task, not in your IAM console, so a point-in-time review never sees them.
- Inherited scope. A child often runs with whatever the parent could reach, so a single broad grant fans out across a chain you did not review.
- No stable identity to ask about. Reviewing "the research sub-agent" is meaningless if a new one spins up per task with the same access.
Shift from listing grants to recording behavior
If you cannot enumerate the actors ahead of time, review what they actually did. For nested agents, the reviewable unit is not a roster of standing grants; it is the recorded set of connections the chain made and the commands it ran. Behavior is observable even when the actor list is not.
This reframes access reviews around evidence. Instead of "does this principal still need access," you ask "what did access through this chain actually touch, and was it appropriate." The second question has an answer; the first often does not.
Govern the access path so dynamic actors are still recorded
The architectural requirement: because you cannot pre-register every sub-agent, the control has to live on the access path that any agent at any depth must use. Enforce and record there, and runtime spawning stops being a blind spot.
hoop.dev is an open-source gateway between identities and infrastructure. Every connection a nested agent makes goes through it, scoped by policy, granted just in time, and recorded against a named principal, regardless of how the agent was spawned. A sub-agent that did not exist when you set policy still has to pass the gateway to reach anything real. Your access reviews then read from a record of every connection the chain actually made, not a roster you could never keep current. See how grants and policy are modeled in the getting-started guide.
Access reviews that survive nesting
- Route all agent access to sensitive systems through the gateway, so depth does not matter to the record.
- Prefer just-in-time grants so there is little standing access to enumerate.
- Review the recorded connections and commands per principal, including sub-agents, against what the task warranted.
- Tighten the scope that the chain can request, since that bounds every layer below it.
The identity-aware model is described on the hoop.dev site.
One scoping choice does most of the work: bound what the top of the chain can request. Because deeper layers cannot reach anything the gateway does not permit for their connection, tightening the entry point tightens the whole tree. Your access reviews then focus on a small set of policies that govern entry, rather than an unbounded set of sub-agents you can never list. That is the move that makes reviewing a dynamic system tractable instead of hopeless.
It also changes the cadence. Static reviews happen quarterly because assembling the roster is expensive. When the review reads from a continuously updated record, you can look whenever behavior changes, not just on a schedule. A sub-agent that reached a new system this morning is visible this morning.
FAQ
How do we review agents that only exist for seconds?
By their recorded behavior on the connection, not their presence in a roster. The gateway captures what each spawned agent reached, even if the agent is gone.
Can a sub-agent escape the review by spawning more?
No. Every layer that touches infrastructure passes the same gateway, so deeper nesting produces more records, not fewer.
To run access reviews against dynamic, nested agents, read how the gateway records every connection on GitHub.
