Proposal: negative conformance vectors for the enforcement layer (valid-but-unauthorized, replayed, and malformed agent actions)

[tyche-dev]

ACS standardizes the point where enterprise controls decide whether an agent action proceeds ("Instrumentable"). What the repo does not yet have is a way for an implementer to prove their enforcement layer actually rejects what it must reject. Positive examples show a control works when everything is right; the security value of an enforcement point is defined by its behaviour on inputs that are almost right.

I propose contributing a small, deterministic negative-vector suite, structured the way we build conformance packages in an open verification toolkit we maintain (tyche-institute/eatf-verifier, Apache-2.0): each vector = frozen input package + expected verdict + expected first-failure code, replayable offline in CI.

Candidate negative classes, from most-often-missed to most obvious:

1. Correctly-signed but out-of-mandate — the action's signature and identity chain verify perfectly, but the requested operation is outside the granted mandate/policy scope. (The class most enforcement layers silently pass, because verification stops at signature validity.)
2. Replayed authorization — a previously valid, already-consumed approval re-presented for a second execution.
3. Expired or revoked mandate — valid at issuance, invalid at execution time; distinguishes implementations that check freshness from those that check only structure.
4. Wrong-context approval — an approval valid for agent A / tool X presented for agent B / tool Y.
5. Malformed evidence with a fail-open consumer — structurally broken action record or trace; the expected verdict is reject, and the vector exists to catch enforcement layers that log an error and proceed.
6. Stripped-observability action — an action whose trace/AgBOM references were removed; tests whether "Traceable" is enforced or merely emitted.

Deliverable shape: conformance/negative/ with one directory per vector (input JSON per ACS interaction schema, expected.json with verdict + failure code, README per class), plus a tiny runner so CI can assert all verdicts. License: whatever the repo prefers (our source material is Apache-2.0).

Two questions before I draft the PR:

• Is specification/ or a new top-level conformance/ the right home?
• Is there an existing enumeration of failure codes to align with, or should the suite propose one?

Happy to bring this to a Tuesday Agentic Security WG call for discussion.

Anton Sokolov, Tyche Institute