Protected boundary — what is never grantable

The line above the Library

The Action Library and Event & system control are the grantable set. This page is what sits outside it — things no grant, at any RiskLevel, can touch.

RiskLevel ≠ protection

A high RiskLevel (even Sovereign) still describes something grantable — it just needs the highest approval. The things that must never be touched are a different category entirely:

They are protected by mechanism, not by permission — so they are never in the grantable Library at all.

“Turn off the audit trail,” “edit a past record,” “extract a signing key,” “grant myself everything” — none of these are actions you approve at some tier. They are structurally impossible or reserved.

The five protections

1. The sealed chain — the past cannot be rewritten ✅ Built

Every sealed record (AuthIntegrityBase) is an append-only, hash-chained entry. Altering a past record breaks the hash, and TamperAlertWorker detects the mismatch. Deleting audit history isn’t forbidden by a permission — it is structurally detectable: you can edit the row, but you cannot hide that you did.

2. Keys — derived in silicon, never extractable ✅ Built (PUF / TPM)

Signing and seal keys derive inside the TPM / PUF and are never serialized out — not by an admin, not by Axowl staff. “Extract a key” is not a grantable action; it is physically unavailable.

3. Immutable & protected scopes ✅ Defined (PermissionConstants)

Root and ownership scopes are flagged un-modifiable:

ImmutableScopes  = system:admin · platform:owner · security:root      ← cannot be modified/deleted
ProtectedScopes  = *:* · system:* · permission:manage · platform:admin · security:policy
IsSystemPermission = true  → Axowl-owned catalog row; an org cannot delete or edit it

4. The no-escalation ceiling — you cannot mint authority ✅ Built (ceiling) · ⚠️ escalation-event emit

Even an owner cannot grant a capability that exceeds what exists. The subsumption rule refuses any request above the grantor’s own bound, so “give me everything” is rejected by arithmetic. The comparator ships — EntitlementSubsumption.Subsumes (arbitrary-depth FK path, layer-inviolable, constraint ceiling with deny-propagation; escalation blocked; unit-tested PR-W, 19 cases) — and the same subset check gates every SignedPermit at PermitEndpoints. The intended auth.security.privilege_escalation_attempted emission on a rejected over-grant is ⚠️ not yet confirmed wired.

4b. Separation of duties — one person cannot hold both halves ✅ Built (2026-07-28)

The ceiling above stops you from getting more authority than the grantor has. It says nothing about a combination that is individually permitted and jointly dangerous: raising an approval and stamping it, granting a permission and deleting the audit record of it.

That is checked separately, on the resulting scope set. SodChecker unions what the member already holds with what the incoming grant compiles to, and refuses if both halves of a pair in SodConflictCatalog are present. Scope pairs rather than role pairs, deliberately — a role-pair rule is bypassed by splitting the two halves across two roles, and that split is the whole failure mode. The reason the union has to be re-checked at grant time: a role’s own deny is consumed by EntitlementCompiler when it bakes and does not survive to suppress an allow that arrives later with a different role.

Enforced at both grant paths (role assignment and approval materialization) and readable as a report at GET /api/org/{slug}/roles/sod-report. Refusal emits auth.sod.assignment_blocked; a scan finding emits auth.sod.conflict_detected. Owner and Admin are exempt — a full-authority principal trips every pair by construction, and refusing them would leave an organization unable to repair itself.

4c. Money is carved out of “full access” ✅ Built (2026-08-03)

Administrative authority and financial authority are different things, and the second is not a subset of the first. An admin with organization-wide access still cannot change what the organization pays or what it charges: the billing scopes are excluded from the membership bypass rather than merely denied in a preset, so a full-access principal does not acquire them by being full-access.

EntitlementPresets.OwnerOnlyScopes is the single list, and ScopeGate reads it directly — Owner bypasses everything, Admin bypasses everything except that list. An admin who is explicitly granted a billing scope passes; the carve-out blocks the implicit route only, so an organization can still delegate deliberately.

This covers both directions of money: plan and add-on purchases (what you pay), and the per-app-group collection switch (what you charge your own end users). Turning collection on or off goes through the same gate — stopping revenue is a financial decision too. The UI hides the control for anyone who lacks the scope, but that is a courtesy: the server refuses the call directly with 403 PERMISSION_DENIED, so bypassing the interface changes nothing.

5. Kill switch & self-modification block ✅ Revocation · 🚧 AI articles

• A revoked principal is blocked immediately, overriding every other policy (RevocationService, highest precedence).
• An AI principal cannot modify its own role or permissions (AI constitution Art 10 — defined, enforcement pending).

Grantable vs protected — the distinction

	Grantable (in the Library)	Protected (never in it)
Examples	approve device · assign role · transfer ownership	edit a past record · extract a key · modify platform:owner · reach billing as an admin
Controlled by	RiskLevel → approval routing	mechanism (chain · silicon · immutable flag · ceiling)
Highest control	Sovereign = multi-approval	not approvable — structurally closed

Even "turn off the audit" has a hard floor

toggleEventRecording is a grantable platform action — you can pause a category for a scope. But it can never make the chain itself mutable or erase the past: protections 1 and 2 sit beneath it. The most an actor can do is recorded; the record itself cannot be unmade.

---

Related: Action Library · Event & system control · Capability grants · Seals & integrity