Agent scenarios (deferred by design)

The spec’s agent dimension (§32, §60) covers an agent-gated workflow — authorized/unauthorized/expired/altered-state/replay — where an agent authorization controls access to confidential operations.

Status: not implemented, deliberately

There is no agent protocol in the underlying Confidential Token model this repository validates. Per the repository’s governing rule — do not invent protocol semantics that do not exist in the underlying implementation (spec §33’s boundary, and §44’s “no invented security”) — implementing agent scenarios would require inventing an authorization scheme the system does not define, then claiming to test it. That is exactly the fake security the project forbids.

What exists that an agent feature would build on

When the underlying implementation defines an agent/authorization contract, the pieces are already in place:

• Authorization failures are a first-class classified outcome (AUTHORIZATION_FAILURE) exercised by the negative pack (wrong owner, unauthorized actor, frozen account).
• The frozen-account / policies fixtures define authorization postures.
• The regression system can pin any agent-authorization bug as a permanent CT-REG-* scenario.
• The issue templates provide an “agent” filing surface via the adversarial/security templates.

When the real protocol adds agents, this doc flips from “deferred” to “implemented” with the pack registered under the standard category/tag machinery — no rework of the runner or reporting layers needed.