递归的尽头：Agent 自举

Description and use

An internal agent ecosystem used a static allowlist that became ineffective after business changes. Switching to dynamic authorization via leases, depth limits, and capability intersections eliminated denial loops and enabled safe recursive spawning.

Problem

A static allowlist for agent permissions became operationally worthless when business changes caused legitimate requests to be denied, leading to recursive denial loops and wasted developer time.

Outcome

Dynamic grants eliminated denial loops, enabled safe recursive spawning, and allowed permission boundaries to evolve with business changes while keeping auditability.

Workflow

• 1. Agent attempts action denied by policy.deny.
• 2. Agent opens a scoped request against its lease for the missing capability.
• 3. On-call approver reviews request in the same channel, approves or denies.
• 4. Grant expires after 15 minutes; repeated requests trigger template review.
• 5. Orchestrator issues new lease with increased depth if needed, with owner recorded.
• 6. Capabilities for child agents are computed as intersection with parent; write scopes granted by name per lease.
• 7. Memory writes are namespaced to lease; promoted notes carry lease ID.

Evidence

We owned the permission layer for an internal agent ecosystem — a dozen-ish agents at the time, each one wired to a handful of internal APIs.

Source

We spent a week patching the list before admitting the model was wrong, and rebuilt it as dynamic authorization...

Source

Now the orchestrator stamps the lease, the agent gets an opaque handle, and it never holds a writable copy of its own limits.

Source

The child's capability set is computed as an intersection with the parent's at spawn time, write scopes are granted by name per lease rather than inherited...

Source

Memory was the piece that actually scared us... writes are namespaced to the lease, promotion into a shared namespace is its own capability...

Source