docs / threat-model

Threat model

Attack vectors AuthR is designed to prevent, partially mitigate, or explicitly does not cover.

Trust assumptions

The AuthR threat model assumes the following trust boundaries:

Trusted

The Issuing Authority signing key (HSM-backed)
The Author Registry (backed by HRMS)
The Verifier implementation (audited library)
The trust store at each resource boundary

Untrusted

Individual AI agents and orchestrators
Sub-agent implementations
Network transport between agents and resources
Agent runtime environments (unless TEE-attested)

Semi-trusted

Verified digital twins (trusted only with explicit grounding)
Third-party Issuing Authorities in federated deployments
The human author's endpoint (protected by AuthN, not AuthR)

Threat catalog

Scope widening attack

CRITICALAuthR covers

Attack vector

A compromised sub-agent attempts to claim permissions its parent never granted — for example, adding wire.cancel to a scope that only included wire.prepare and wire.validate.

Mitigation

Structural enforcement via the monotonic scope attenuation invariant (§5.3.3 inv.4). The Verifier rejects the record before it reaches the resource. The Issuing Authority also refuses to mint a widened hop at issue time.

Author spoofing

CRITICALAuthR covers

Attack vector

An agent attempts to forge an AuthR record claiming a high-authority author (e.g. CFO) without actual authorization from that person.

Mitigation

All AuthR records are signed by the Issuing Authority. The Issuing Authority validates author grounding against the Author Registry before minting. An unsigned or incorrectly signed record fails Invariant 1.

Model swap under stable agent ID

HIGHAuthR covers

Attack vector

An attacker replaces the model weights or code running under a known, trusted agent SPIFFE identity. The agent identity remains the same but its behavior changes.

Mitigation

Actor model_manifest binds code_hash and model_hash to the record. The Verifier confirms the running attestation matches the manifest in the AuthR record. Changing the model invalidates the attestation.

Record replay attack

HIGHAuthR covers

Attack vector

An attacker captures a valid AuthR record and replays it at a later time to authorize a new action the original author never intended.

Mitigation

Records have explicit expires_at and stale_after timestamps (Invariant 2). Short TTLs (30 minutes default) limit the replay window. The correlation_id is unique per execution graph.

Intent drift

MEDIUMAuthR covers

Attack vector

An orchestrator re-plans mid-execution and takes an action that is technically within scope but contradicts the stated intent. OAuth OBO cannot detect this — the token still authorizes the call.

Mitigation

Intent is a first-class field captured at authorship time. The Verifier can check that the executing action matches the declared purpose. Drift signals surface when confidence drops below threshold.

Issuing Authority compromise

CRITICALPartially mitigated

Attack vector

If the Issuing Authority is compromised, an attacker can mint arbitrary AuthR records with any author, actor, and scope.

Mitigation

AuthR does not fully solve this in v0.1 — this is a trust anchor problem. Mitigations include HSM-backed signing keys, multi-party approval for high-risk records, short TTLs to limit blast radius, and audit log monitoring for anomalous issuance patterns.

Correlation ID collision

LOWAuthR covers

Attack vector

Two independent execution graphs share a correlation_id, causing audit logs to conflate unrelated chains.

Mitigation

Correlation IDs must be generated with sufficient entropy (at minimum 128 bits). The Issuing Authority should validate uniqueness against its registry before minting. In practice, UUID v4 or ULID provides sufficient collision resistance.

Verifier denial of service

MEDIUMAuthR covers

Attack vector

An attacker floods the Verifier with malformed or deeply nested chains, causing high CPU usage from repeated cryptographic verification.

Mitigation

The Verifier enforces max_delegation_depth from the scope constraints. Chain depth is bounded at issuance time. The Issuing Authority enforces the depth limit before minting. Malformed records fail fast on Invariant 1 before deeper checks run.

Out of scope

AuthR is deliberately narrow. The following are out of scope for v0.1 and require complementary controls:

—Compromised human author — if Jane Doe's credentials are stolen and used to mint a root record, AuthR cannot detect this. That's an AuthN problem (MFA, hardware keys).

—Application-layer bugs — AuthR enforces authorship boundaries. If the underlying application has a privilege escalation bug, AuthR does not protect against that.

—Side-channel attacks on the HSM — out of scope for this protocol version.

—Collusion between the Issuing Authority operator and an attacker — requires out-of-band governance controls.