All posts

Nested agents: what they mean for your blast radius

A single agent with broad access has a blast radius you can reason about. Nested agents change the shape of the problem, because scope compounds as it flows down the chain. The orchestrator's access becomes the ceiling for its children, the children's for theirs, and a grant you made once at the top can fan out across a tree of actors you never sized. Separating the new risk from the familiar one matters here. The familiar risk is that any one agent might do damage with its access. You know how

Free White Paper

Blast Radius Reduction + Mean Time to Detect (MTTD): The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

A single agent with broad access has a blast radius you can reason about. Nested agents change the shape of the problem, because scope compounds as it flows down the chain. The orchestrator's access becomes the ceiling for its children, the children's for theirs, and a grant you made once at the top can fan out across a tree of actors you never sized. Separating the new risk from the familiar one matters here.

The familiar risk is that any one agent might do damage with its access. You know how to bound that: scope it. The new risk is that the blast radius is no longer one agent's reach; it is the union of reach across a chain that grows at runtime.

The new risk: scope that compounds

When agents spawn agents, two things multiply the blast radius:

  • Inheritance. A child commonly runs with the parent's access. One generous grant at the top is a generous grant at every layer.
  • Depth you did not plan. New sub-agents appear in response to tasks, so the set of actors holding that inherited access is unbounded at design time.

The contrast: a flat agent's blast radius is what it can reach. A nested chain's blast radius is what anything in the tree can reach, and the tree is not fixed.

You cannot bound it inside the chain

Asking each agent to limit what it passes to its children does not hold. A buggy or manipulated layer can hand down more than it should, and you have no way to verify the self-imposed limits of an actor you are trying to constrain. The bound has to come from outside the chain.

Bound the blast radius on the connection

The architectural requirement: enforce scope on the access path that every agent must traverse to reach infrastructure, not on the trust between parent and child. Then inheritance inside the chain cannot exceed what the gateway allows on the connection.

Continue reading? Get the full guide.

Blast Radius Reduction + Mean Time to Detect (MTTD): Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

hoop.dev is an open-source access gateway between identities and infrastructure. Every connection, at any depth of nesting, passes through it and is scoped by policy and granted just in time, then recorded against a named principal. A sub-agent five layers deep cannot reach a system the gateway does not permit for that connection, no matter what the parent tried to hand down. The blast radius stops compounding, because the ceiling is enforced on the connection, not inherited through the chain. See how scoping and just-in-time grants work in the getting-started guide.

A concrete bound

Suppose the orchestrator needs read access to one reporting database. Without a gateway, any sub-agent it spawns can use that access, and a deep layer that misbehaves reaches the whole database. With the connection governed, the chain reaches exactly that one database, read-only, for the task window, and every query is recorded. The blast radius is the connection's scope, not the chain's depth. The identity-aware model is described on the hoop.dev site.

The mistake to avoid

The tempting shortcut is to give the orchestrator broad access so its sub-agents "just work," then plan to rein it in later. That decision sets the blast radius for the entire chain in one stroke, and later rarely comes. Every sub-agent that ever spawns inherits the broad grant, and the actual reach of the system becomes whatever the most permissive layer was handed.

Start from the opposite default. Give the entry point the narrowest grant that lets the task begin, and let deeper layers request their own scoped access through the gateway when they genuinely need more. The blast radius then grows only by explicit, recorded grants, never by silent inheritance.

FAQ

Does limiting the orchestrator limit its children?

Only if the limit is enforced on the access path. If it relies on the orchestrator honestly restricting children, a faulty layer breaks it. Enforce scope on the connection so depth cannot exceed it.

What if a sub-agent needs more access than its parent?

Then it requests its own grant through the gateway and that grant is scoped and recorded too. Access is granted on the connection per principal, not smuggled down the chain.

To bound the blast radius of nested agents on the connection rather than the chain, read the open-source gateway on GitHub.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts