Authority

Where enforcement lives

Authority in UniNet is a property of the network rather than a check inside application code. A right is delegated by signature, carries its own limits, and is resolved by the party being asked to act on it — not by the party asking. That inversion is the whole of the idea, and it is worth stating plainly why the alternatives you have already built do not have it.

The three things you built instead

An API key in a secrets manager. A key is a bearer credential. Its scope lives in the service that accepts it, and the key itself carries nothing — not who issued it, not under what ceiling, not what it was for. Narrowing it is a new key and a deploy. Withdrawing it is a rotation, racing every consumer that holds a cached copy. And a key held by the process you wanted to constrain is a key that process can spend on anything the accepting service will accept.

A spend counter in a database column. The ceiling is enforced by the same process that wants to spend. Two workers, a retry after a timeout, a path that commits before it decrements — each is an ordinary bug, and each produces overspend that the counter then reports as compliance. The counter is advisory in precisely the circumstances you built it for.

A hardcoded allowlist checked in application code. The constraint ships inside the binary being constrained. Changing it is a deploy, auditing it is a code review, and a compromised process reads the allowlist as data rather than as a boundary. It is a comment addressed to a well-behaved program.

The three fail the same way:

              constraint
                  │
                  │  lives inside
                  ▼
          the thing constrained

The agent holds the key. The agent's process decrements the counter. The agent's binary contains the list. Constraint and actor share a trust boundary, so each holds only against the honest mistakes anticipated the day it was written.

What a delegation carries

A grant is self-describing. It states its own limits, and those limits travel with it.

| Field | What it fixes | Why it lives in the grant | | --- | --- | --- | | Issuer | The identity that signed it | Attribution survives every hop | | Holder | The identity it was issued to | It is not a bearer token — presenting is not holding | | Scope | A class of service, a set of actions | Narrowing is a new grant, not a service config edit | | Spend cap | The ceiling on value moved under it | Resolved at settlement, not counted by the spender | | Duration | How long an authorized action may run | Bounds an action in flight, not only the right to start one | | Expiry | When the grant stops resolving | The default end state is withdrawn, with no cleanup job | | Parent | The grant it was derived from | Makes the chain resolvable, and revocation cascade |

Issuance is a signature

The issuer signs a grant naming the holder identity and the limits above. There is no registration call to a permissions service and no row to write in an application database — the signature is the authorization.

Verification is resolution. A party asked to act on a grant — an operator reserving capacity, a settlement path moving value, a service deciding whether to answer — resolves it rather than trusting whoever presented it: check the signature, walk the parent chain to a root identity, check whether any link has been withdrawn. Enforcement lands at the point of effect. The spender does not decide it is within its ceiling; the path that moves the value does.

Delegation narrows, and only narrows

Any grant can be used to issue a narrower grant, never a wider one: a derived grant may reduce scope, lower the ceiling and shorten the window, on every axis, in one direction. The effective authority of a chain is the intersection of every link in it, so reading the chain is enough — you never reconstruct which service applied which policy along the way.

PERSONAL IDENTITY      scope: any service    ceiling: account    expiry: long
      │
      │ delegates
      ▼
AGENT IDENTITY         scope: compute only   ceiling: lower      expiry: days
      │
      │ delegates
      ▼
TASK GRANT             scope: one job        ceiling: lower      expiry: hours
      │
      ├───────────────────┬───────────────────┐
      ▼                   ▼                   ▼
 reserve compute     send payload      settle payment

Cascading revocation

Withdrawing a right withdraws everything derived from it. Revoke at the agent identity and the task grants beneath it stop resolving, because what is checked is the chain and the chain no longer reaches a root. You never enumerate the descendants — and enumeration is the step that fails in practice, being only as complete as your record of what you issued.

Set that against rotation, which is best-effort: it depends on every holder noticing, and leaves the old credential valid wherever it sits cached. A revocation is a state change with a definite moment, applied where the right is resolved rather than where it is held.

It does not reach backwards. An action that already completed is not undone; revocation governs what resolves from that point forward.

How it composes

• Identity. Issuer and holder are identities, so the chain of who authorized what ends at a personal identity rather than at a secret.
• Assets. The ceiling is resolved by the settlement path, which is why it constrains a compromised spender and not merely a well-behaved one.
• Compute. Scope can name a class of capacity, and the operator resolves the grant before reserving anything.
• UNP. A service can require a grant before it answers, keeping reachability and authorization separate.

What this changes in a design

Two things, and together they are the reason to model authority at the network layer at all. The blast radius of a compromised agent becomes the grant it holds — scope, remaining ceiling, remaining time — rather than everything its key can reach. And recovery becomes a revocation rather than a rotation followed by a hunt through every system that might hold a copy.