System architecture

Overview

AuthR introduces a new control plane layer that sits above existing IAM infrastructure. It does not replace OAuth, SAML, or RBAC — it adds the authorship assertion layer that those systems cannot provide. The architecture separates three concerns: issuance (creating AuthR records), verification (enforcing invariants at resource boundaries), and audit (immutable logging of every authorship event).

Control plane

The AuthR control plane is responsible for minting, extending, and revoking AuthR records. It is analogous in role to an OAuth Authorization Server, but for authorship rather than access. In v0.1, the control plane is a single Issuing Authority. In v0.2, it federates across trust domains.

The control plane is not in the hot path of agent execution. Records are minted at authorship time (when a human or verified digital twin delegates authority), not at every API call. This means the control plane can be high-integrity and slightly slower without impacting agent throughput.

Issuing Authority

The Issuing Authority is the component that mints and extends AuthR records. It performs three functions: it validates that the requesting author is grounded (tied to an HR record or board approval), it constructs the AuthR record with correct provenance, and it signs the record using Ed25519 via an HSM-backed key.

Verifier

The Verifier is a library embedded at every resource boundary — the last-mile enforcement point. It is not a service; it is a dependency that every resource server imports. This ensures enforcement happens structurally, not by policy, and cannot be bypassed by routing around a gateway.

The Verifier checks all six invariants in order and fails fast on the first violation. It consults the trust store for signature verification and the revocation endpoint for real-time status.

Author Registry and Agent Registry

The Author Registry maps author DIDs to grounding evidence — HR records, board approvals, professional licenses. It is the source of truth for who is permitted to be named as an author in an AuthR record. In enterprise deployments this is typically backed by the HRMS.

The Agent Registry maps agent SPIFFEs to model manifests and attestation records. It enables the Verifier to confirm that the model running under a given agent identity matches the manifest in the AuthR record. Swapping the model under a stable agent ID is a known attack vector — the Agent Registry closes it.

Data plane — what travels with the request

AuthR records travel alongside existing OAuth tokens, not instead of them. The actor presents its OAuth access token for API authorization as normal. The AuthR record (or chain) travels as an additional header or body parameter. The Verifier at the resource boundary checks the AuthR chain before the request is processed.

Deployment patterns

Production infrastructure stack

The v0.1 playground uses mocked signatures and in-memory state. Production replaces these with enterprise-grade components: