Delegation & Authority
Authority in System9 flows downward and can only narrow. A person delegates a bounded slice of their authority to an agent; the agent mints a smaller grant for a sub-agent; a parent entity delegates a scoped authority to a field device. At no hop can a delegation grant more than it holds, the invariant is simply authority can only shrink.
Two properties make this more than a policy string. First, every child grant is the intersection of what was requested and what the parent holds, a request that reaches beyond the parent is attenuated, never escalated. Second, a spawn request carries no identity of its own: who the child acts as is resolved server-side from the parent's sealed grant, so a compromised model can ask for the wrong thing but can never ask as someone else.
Agents and users are not governed by different machinery. They are peers, the same lookup, the same grant path, the same audit, the same billing.
The chain
Figure D2: the delegation chain. Each solid hop mints a grant as the intersection of what was requested and what the parent holds, so a child is always a subset of its parent. The green box is the parent's sealed grant, the only source of the child's identity fields; a widen attempt is denied (red) and a custody-key mismatch fails the spawn closed (amber). The same machinery governs users and agents. They are peers.
Table equivalent
| Hop | Parent | Child | How the child's grant is formed | Failure mode |
|---|---|---|---|---|
| Person → Agent | A person | An agent | Intersection of requested and the person's held authority | A request beyond the person is attenuated |
| Agent → Sub-agent | An agent | An ephemeral sub-agent | Intersection of requested and the agent's sealed grant; a per-sub-agent signing key | Spawn fails closed on a custody-key mismatch |
| Agent / Parent → Device | A parent entity | An enrolled field device | Scoped delegation bound to the device's certificate fingerprint at enrollment | Hardware-uniqueness and fingerprint checks reject a clone |
| Any widen attempt | Refused: a child cannot exceed its parent on any axis | Denied: never escalated |
The intersection rule: attenuate, never escalate
Every delegation surface enforces the same narrowing, and a child grant must satisfy all of these against its parent:
| Axis | The narrowing rule |
|---|---|
| Permissions | A subset of the parent's |
| Lifetime | No longer than the parent's, with no backdating |
| Clearance | Less than or equal to the parent's |
| Compartments | A subset of the parent's |
| Budget | Fits within the parent's |
| Delegation depth | Strictly decreases, so recursion is structurally bounded |
For agents this takes the form of a sub-agent grant: an ephemeral, attenuated bearer credential minted from the parent's sealed grant, carrying attenuated axes for scope, tools, data grants, egress, compartments, clearance, permission mode, and budget, and signed with a per-sub-agent key. A grant verifier checks the attenuation invariant on every link of the chain and rejects a chain that widens anywhere. Verification is self-contained from the presented chain bundle, so it holds offline on a disconnected edge device.
The spawn request carries no identity
When an agent requests a sub-agent, the request carries no identity fields at all, issuer, lineage, root entity, and cell are resolved server-side from the parent's sealed grant, and the call fails closed on a custody-key mismatch.
This is the structural difference from a bearer-token system. A compromised or jailbroken model controls only the intent half of the request; the identity half is derived, not supplied. It can ask for the wrong thing, and be attenuated but it cannot ask as someone else. The property is a fact of the mint path, not a filter on a prompt.
Identity and authority are separate chains
A certificate proves who a principal is; a delegation says what it may do. Keeping the two separate is what lets a device's authority be revoked in a single call without rotating its certificate, and it is why a stolen delegation token is useless without the matching private key, the delegation is bound to the certificate fingerprint.
From a person to a field device
A device receives authority through enrollment, which binds a hardware fingerprint to a cryptographic identity and a scoped delegation from a parent entity. An operator generates a single-use enrollment token (shown once, only its hash stored); the device generates its keypair locally and computes a hardware fingerprint; the cell validates the token, enforces hardware uniqueness so a clone is rejected, signs the device's material, records it in the fleet, and consumes the token. The delegation binds the device certificate fingerprint, records its full ancestry for audit, and is validated on every RPC. See Authorization and delegation for the full enrollment sequence and offline enforcement.
Related topics
- Agent Platform Concepts, the single authorization path agents share with people.
- The entity model, the principals authority flows between, and why users and agents are peers.
- Authorization and delegation: enrollment, the grant verifier, and offline enforcement in full.
- The Net Potential Gain (NPG) gate, the gate that sits atop a valid grant and can still refuse.