Delegated authority for enterprise agents

Authority is a chain, not a role

When an enterprise gives an agent authority, the instinct is to grant it a role — "the procurement agent" — and attach permissions to the role. That works until the agent spawns a sub-agent for one task, or hands a session to another system, and the question becomes what that downstream holder may do. A role does not answer it. A chain does: authority runs from a human, to the organisation that employs them, to the agent, to any sub-agent, to a session, and every link is a grant that names exactly what it carries and who issued it.

The open spec for this layer, delegation/1, fixes the shape of that chain. A grant names its scopes, a cap in integer minor units, an expiry, a purpose, and the holder it was issued to. A verifier reads the chain from the root down and computes the authority in effect at the leaf — the agent actually doing the work — as the intersection of everything above it. There is no step where the leaf holds more than the root chose to delegate.

Attenuation, refused at the widening

The rule that makes the chain safe is attenuation: a child grant may carry only a subset of its parent’s scopes, a cap no higher, an expiry no later, and the same or a narrower purpose. The important part is what the checker does with a violation. It does not clamp the child to the parent’s ceiling, and it does not average the two. It refuses the whole document, and it names the dimension that widened.

$ node vendor-delegation.mjs check vectors/invalid/widened-scope.json
✗ scope_widened at chain[1].scopes
1 problem(s)

That refusal matters because clamping is the failure mode a governance reviewer cannot see. A system that silently trims an over-broad grant to the parent’s limit looks like it is working; the grant on paper still claims more than it was allowed, and the day the clamp has a bug the extra authority is live. Refusing the document forces the mistake to the surface where it was made, which is the only place it is cheap to fix.

Enforcement before minting

The second refusal in the spec is that every grant must name, in an enforcedBy field, the endpoint that checks it before anything acts on it — and a grant with no checker is refused. This is the identity layer’s version of a rule this practice applies to every custody and agent engagement: authority that nothing enforces is theatre. It is not enough to mint a correct chain; there has to be a point in the running system that reads the chain and refuses an action outside it, and the grant itself has to point at that point.

Binding the subject to the holder

The third refusal is subtle and load-bearing: a valid signature over somebody else’s chain authorises nothing. A verifier walks the chain and checks that each grant’s issuer is the holder of the grant above it, that the root is a person or an organisation and never a machine, and that the principal actually acting is the leaf’s subject. An attacker who lifts a well-formed grant and presents it under their own identity fails this check, because the chain binds the authority to a specific holder rather than to whoever can replay the bytes.

One honest boundary: the spec fixes what is signed — the canonical form of the grant without its signature — and deliberately mandates no signature algorithm and no key distribution. Those are the implementation’s to choose, and the reference checker says so out loud, reporting a structural pass as exactly that and not as a cryptographic one. A structural check is not a verified signature, and a design that conflates the two has a hole where its strongest guarantee should be.

What this changes in an enterprise

For an enterprise, the practical shift is that "what can this agent do" becomes a question with a checkable answer at every hop, including the hops the agent creates for itself. Revocation walks down the chain, so cutting a human’s authority cuts everything delegated beneath them. And because the root is always a person or an organisation, there is always a name to put next to an action when a reviewer asks who authorised it — which is the question a regulated firm answers first and an ungoverned agent deployment answers never.

• The lab’s view (planned)FlashyLabs is preparing an engineering companion to this piece at https://flashylabs.com/insights/delegated-authority-for-enterprise-agents — planned, not yet published.
• The studio’s view (planned)The 4 Ventures thesis desk is preparing an investor-lens companion at https://4.ventures/thesis/delegated-authority-for-enterprise-agents — planned, not yet published.