All posts

Nested agents: what they mean for your least privilege

Least privilege means granting an actor only the access its job requires. Nested agents complicate the first word: which actor. When an orchestrator spawns sub-agents that spawn their own, the access you granted to one principal is exercised by a tree of them, and least privilege quietly becomes "least privilege for the whole chain, whatever it grows into." No padding here. The practical question is how to keep a tight grant tight when the actor holding it can multiply. How nesting erodes lea

Free White Paper

Least Privilege Principle + 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.

Least privilege means granting an actor only the access its job requires. Nested agents complicate the first word: which actor. When an orchestrator spawns sub-agents that spawn their own, the access you granted to one principal is exercised by a tree of them, and least privilege quietly becomes "least privilege for the whole chain, whatever it grows into."

No padding here. The practical question is how to keep a tight grant tight when the actor holding it can multiply.

How nesting erodes least privilege

  • Inheritance widens reach. A child running with the parent's access means a single grant is exercised by every descendant.
  • Convenience grants. It is tempting to give the orchestrator broad access so its children "just work," which is the opposite of least privilege.
  • Standing access compounds. If the top-level grant is permanent, every future sub-agent inherits a permanent grant.

The requirement: grant per connection, not per chain

Least privilege survives nesting only if access is granted on the specific connection an agent makes, enforced outside the agent, rather than inherited as a blanket capability down the tree. The decision point has to sit where the agent cannot widen it, which is the access path, not the agent process.

If a sub-agent can reconfigure its own scope or rely on a parent's broad grant, least privilege is a suggestion. If the scope is enforced on the connection, it is a bound.

How a gateway holds the line

hoop.dev is an open-source gateway between identities and infrastructure. Every connection a nested agent makes is scoped by policy on the gateway, granted just in time, and recorded against a named principal. An orchestrator does not get broad standing access that its children inherit; each connection is granted to the principal making it, scoped to what that task needs, for the window it needs. Depth does not loosen the grant, because the grant lives on the connection. That keeps least privilege intact no matter how the chain grows. See the grant and approval model in the getting-started guide.

Continue reading? Get the full guide.

Least Privilege Principle + Mean Time to Detect (MTTD): Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

An operating pattern

  1. Default every agent, parent or child, to no standing access.
  2. Grant access per connection, just in time, scoped to the task.
  3. Do not rely on inheritance to pass access down; let each layer request what it needs through the gateway.
  4. Use the command-level record to find scopes you can tighten, since unused access in the record is safe to remove.

The identity-aware model is described on the hoop.dev site.

Inheritance versus delegation

The core design choice for least privilege in a nested system is whether access flows by inheritance or by delegation. Inheritance means a child silently runs with the parent's reach. It is convenient and it is the main way least privilege quietly dies, because no one decided the child should have that reach; it just got it.

Delegation means a child that needs access requests it explicitly, and the request is scoped and recorded on its own connection. It costs a little more at design time and it keeps the principle intact, because every grant in the tree is a decision you can see and review. When access is enforced on the connection rather than passed down in-process, delegation is the natural model: there is nothing to inherit, because the gateway grants per principal per connection.

A quick sanity check

Ask one question of any nested system: if a sub-agent five layers deep is compromised, what can it reach? If the answer is "whatever the orchestrator could reach," you have inheritance and your least privilege is theoretical. If the answer is "only the scoped connection it was granted," you have delegation enforced outside the chain, and least privilege holds at depth.

FAQ

Should children inherit the parent's access?

Inheritance is convenient and corrosive to least privilege. Prefer per-connection grants so each layer holds only what its task needs, enforced on the access path.

Does just-in-time access slow nested agents down?

Grants scoped to a connection and issued on demand add little overhead while removing the standing access that nesting would otherwise compound.

To hold least privilege across nested agents by granting on the connection, 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