Holding a credential is not holding authority. Three independently held components, bound to registry state, recorded on a tamper-evident chain.
An attacker takes a server. On it they find a token, a key, a session — whatever the system treats as proof of authority. In most architectures that is the end of the story, because the system was built so that whoever holds the credential is the authority.
ABT-A separates the two. Authority is not a thing you hold. It is a relationship between three components held independently of one another: the client, SARA, and the ABT registry operator. Each is custodied separately. No one of them, and no two of them together, can produce recognized authority alone.
So the server that was taken does not carry the authority to act on itself. Taking it yields a credential; it does not yield recognition.
A registration the operator key did not sign is not a recognized authority. A release that does not verify against the registry’s current state fails closed. A release bound to a retired generation cannot authorise anything, and a release that has already been applied cannot be applied again.
Each of those is a refusal, and each refusal is written to the same hash-chained evidence log as the actions — because a refusal nobody recorded is indistinguishable from a check that never ran.
Security Assurance operates four plans against a protected infrastructure environment. Plan A defends it continuously and Plan B investigates and contains a confirmed incident — both within a scope the client agreed in advance, so that a real incident does not wait on a signature.
Plan C verifies whether the environment and a recovery point can be trusted, and Plan D treats the environment as untrusted and rebuilds it. Those two reach much further into the client’s infrastructure, so they are locked. The client releases them explicitly, per capability, for a bounded period, and the release is not reusable.
The protected environment does not hold the client’s component. That is the point of the arrangement: compromising the machine does not confer the authority required to rebuild or re-verify it.
ABT-A introduces no new cryptographic primitive. It composes the ones ABT already uses. Tier authorities are registered through the existing ABT registry, and each activation is signed by the registry operator key held by a separate signing service that returns a signature and never the key; the activation payload is canonicalised with sorted keys and the resulting event hash is SHA-256 over the payload concatenated with that signature. The client component is the per-transaction AES-256-GCM key role of the existing envelope construction, custodied with an expiry rather than issued to the holder. Capability projections are authored per tier at envelope construction, so a tier with no active registration has no initialisation vector, no authentication tag and no ciphertext. Authority state is bound to a registry state hash computed over the registry’s canonical authority listing; a release verifies that hash at the moment it is requested and again when it is applied, and fails closed if the registry has moved between the two. Releases are capability-specific, scope-specific, environment-specific, generation-specific, time-bounded and single-use. Regeneration revokes the prior generation, revokes every release issued under it, and retires the prior registrations through the registry’s partial unique index on active tier authorities. Every issuance, release, refusal and revocation is appended to the existing hash-chained evidence log, where each entry’s hash includes the prior entry’s hash.
Security architects designing authority models where credential theft, replay, forgery and insider misuse are assumed rather than excluded, and where compromise of the protected asset must not confer authority over it.
Incident response and recovery teams who need extraordinary capability during an incident without holding standing extraordinary capability before one.
Cryptography researchers studying multi-party authority composition, registry-bound recognition, canonical activation signing, and tamper-evident authorization records.
Auditors and counsel examining whether an authorized action can be shown to have been authorized — and whether a refusal can be shown to have occurred.
Policy researchers examining architectural constraints on privileged access, separation of duties enforced cryptographically rather than procedurally, and evidence standards for automated infrastructure action.