Skip to main content

Authorization, Delegation and Revocation

Authority in System9 flows downward through delegations, and every delegation can only narrow the authority above it. A person delegates a bounded slice of their authority to an agent; an agent mints a still-smaller grant for a sub-agent; a parent entity delegates a scoped authority to a field device. At no step can a delegation grant more than it holds, the invariant is authority can only shrink.

Figure D2: authority narrows every hop. Each delegation is a subset of its parent across every axis; a grant verifier checks the attenuation invariant on every link and rejects a chain (red) that widens anywhere or fails to decrease delegation depth.

Table equivalent

HopCarriesNarrowing rule
Person → AgentA bounded slice of the user's authoritySubset of the person's
Agent → Sub-agentAn ephemeral grant minted from the parent's sealed grantSubset; per-sub-agent key; depth decreases
Agent / Parent → DeviceA scoped delegation bound to the device certificate fingerprintSubset; nested lifetime; no backdating
Any hop that widensRejected: permissions, lifetime, clearance, compartments, budget, and depth must all narrow

Delegation is separate from identity​

A certificate proves who a principal is; a delegation says what it may do. The two chains are deliberately separate: transport-level identity comes from the certificate, authorization-level authority from the delegation. This is why a device's authority can be revoked in a single call without rotating its certificate, and why a stolen delegation token is useless without the corresponding private key, because the delegation is bound to the certificate fingerprint.

Attenuation: the rule that holds everywhere​

Every delegation surface enforces the same narrowing rule. A child delegation must satisfy all of:

  • Permissions are a subset of the parent's.
  • Lifetime is no longer than the parent's, with no backdating.
  • Clearance is less than or equal to the parent's.
  • Compartments are a subset of 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, subset relationships, clearance and permission-mode ceilings, nested lifetimes, and a budget that fits within the parent with a strictly decreasing depth, 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.

An agent's base identity is provisioned with an empty authority envelope, no tools, no scope, clearance zero. Establishing identity grants no ability to act; authority is granted afterward, explicitly. You can always grant up; you can never un-leak a silent grant.

From a person to a field device​

A device receives its authority through enrollment, which binds a hardware fingerprint to a cryptographic identity and a scoped delegation from a parent entity:

  1. An operator with fleet-management permission generates a single-use enrollment token server-side. It is shown once; only its hash is stored. The token encodes the parent entity, a scope, a permission map, a device profile, a TTL, data grants (row filters and column masks), and, for classified environments, a clearance level and compartments.
  2. On the device, enrollment generates an ECDSA P-384 keypair locally, builds a certificate signing request, and computes a hardware fingerprint over the host's network addresses and hostname.
  3. The cell validates the token, enforces hardware uniqueness (so a clone is rejected), signs the X.509, SSH, and PGP material from the request, creates the delegation, records the device in the fleet, and consumes the token.
  4. The device persists its material locally and can now operate. Enrolling over a state directory that already holds an identity is refused unless re-enrollment is explicit, so a second enrollment cannot silently clobber the first.

The delegation binds device_cert_fingerprint, records its full ancestry chain for audit, and is validated on every RPC: the delegation must exist and not be revoked, must not be expired, must match the presenting certificate's fingerprint, and must cover the requested operation, otherwise the call is refused. Device profiles (sensor, agent, operator, tactical) bound what a device may do at all, set at token-generation time.

Roles, permissions, and scope-grants​

Delegation is the path for agents and devices; on the cell, ordinary callers are authorized through a deny-by-default unified permission evaluator over a three-layer catalog (directory, system, and catalog permissions) with cross-layer projection, so a directory-level role can grant a system-level capability. Role assignments attach a role to a principal within a scope (org, cell, service group, node, workspace); a scope-grant names exactly what a grant covers through a workspace resource identifier scheme. Roles are auto-assigned on entity creation, and the whole model composes strictest-wins with the capability and Net Potential Gain (NPG) gates.

For the catalog itself, the three planes, the 443 permissions and their risk tiers, the 48 built-in roles and what each is for, and the second authorization layer object storage adds, see roles and permissions.

A programmatic credential narrows this further, never wider: a scoped API key or OAuth access token carries its own scopes, and its effective authority is the intersection of the owning entity's roles and those scopes, so a credential can only ever exercise a subset of what its owner could already do.

Immediate structural revocation​

Authority is re-derived per request. There is no long-lived "you are allowed" verdict cached across requests that a revoke would have to chase down. When a role, grant, or delegation changes, the change is structural: the next request sees the new authority, not the old one.

The mechanism is a single-row authority epoch counter in the directory, bumped by 18 database triggers, six authority tables, each on INSERT, UPDATE, and DELETE. Any write to authority moves the epoch; the authority cache keyed on that epoch is invalidated; the next request re-derives. Crucially, the triggers fire on the replication-apply path too, so a revoke that arrives by replication invalidates the cache on the receiving cell exactly as a local write would.

Figure E5: immediate structural revocation. A write to any of six authority tables bumps a single epoch counter through 18 triggers; the authority cache keyed on the epoch is invalidated; the very next request re-derives and the revoked authority stops answering yes. The triggers fire on replication-apply, so a revoke propagated to a peer cell takes effect there the same way.

Table equivalent

StepWhat happens
RevokeAn operator revokes a role, grant, or delegation
TriggerOne of 18 DB triggers (6 authority tables × INSERT/UPDATE/DELETE) bumps the epoch
InvalidateThe authority cache keyed on the old epoch is now stale
Re-deriveThe next request recomputes authority from current state
EffectThe revoked authority no longer answers yes: on the next request, including after replication-apply

Because a device's delegation is bound to its certificate fingerprint, revoking the delegation invalidates every future request from that device without a certificate rotation (see key custody).

Break-glass​

Emergency access is a designed, recorded path, not an exception that bypasses the record. A time-boxed break-glass pin grants elevated access for a bounded window, and the reconciler reverts it unless it is explicitly renewed, so emergency authority expires on its own rather than lingering. The elevation, and its expiry, land on the audit record like any other governed action.

Offline enforcement​

Authorization does not require a round-trip. A device evaluates authorization locally with a policy engine and default-deny posture, and customer policy can only restrict platform defaults, never loosen them. A revoked delegation, a rotated authority, or an expired grant is enforced on the device against its own state. See Governance (Deny-Closed) for the enforcement model on both runtimes.

Design status

The delegation and attenuation mechanisms are described by mechanism. The edge delegation chain is the single authorization path for device and edge calls; on the cell, role assignments, a policy engine, and a capability broker compose alongside it for other callers.