RFC: Representing tool decisions (allow/deny) in verifiable attestations without overstating evidence limits

[Alex-Proof]

Hi everyone,

I've been working on offline-verifiable attestations and execution traces for autonomous AI agent workflows (reference implementation and verifier: Alex-Proof/alex-mrtb-verify-bundle).

A core question that occupies me most is this:

How do you represent a security-relevant tool decision (especially an active deny) so that a verifier can bind it — without turning the deny into a universal “this could never have happened” statement?**

Concrete Scenarios (Negative Records)

In our execution runtime, a deny is not claimed by the agent itself. It is observed by an enforcement layer/sandbox and written into a signed record. Typical cases we test against:

• Network egress outside allow-list:** Intercepted by kernel/sandbox, logged, signed into the trace.
• Strict proxy-only boundaries:** Direct host connections blocked and recorded.
• Workspace escapes / Self-replication:** File writes or copies of the agent payload outside the bounded path trapped.
• Unbound capabilities:** Access to unauthorized endpoints or tools denied.

In these cases, an independent verifier intentionally does not return VERIFIED, but a deterministic failure state (e.g. non_verified_outcome:failed). The violation was detected and proven by the enforcement layer.

What I currently consider for representing such an event

Crucial Distinction
An agent’s own statement "I denied the request" is fundamentally not the same as a signed record from a trusted enforcement component + observer.

Even the latter only attests to what those specific components observed and bound — it does not prove that no other execution path or out-of-band side channel existed.

Open Questions (Where I would value feedback)
What minimum fields does a verifier need to bind a decision or a human approval to a concrete run and (optionally) to the resulting artifact?

How should a schema express the strength and the limits of a negative claim without overstating it?

Should the event record always be bound to the source diff / artifact, or is the run identity sufficient?

Are there already established predicates or schemas (in-toto, Sigstore, SCITT, …) that cleanly cover this pattern (signed negative claim + evidence strength)?

I am deliberately not proposing a finished predicate specification here. I first want to understand what the community already considers solved cleanly and where the real gaps are.

The verifier kit and test fixtures are open source and offline-verifiable:

https://github.com/Alex-Proof/alex-mrtb-verify-bundle

Feedback, counter-examples, and pointers to existing work are welcome!

{
  "event": "tool.execution",
  "tool": "network.request",
  "requestDigest": "sha256:…",
  "decision": "denied",
  "enforcer": {
    "type": "sandbox",
    "policyDigest": "sha256:…"
  },
  "observerReceipt": { … },
  "approval": null,
  "previousEventDigest": "sha256:…",
  "boundTo": {
    "runId": "…",
    "artifactDigest": "sha256:…"
  }
}

[renezander030]

For the approval case, the verifier needs the approval to name the requestDigest the approver actually saw, so an approval can't be carried over to a call whose arguments changed after the decision. I'd also chain an effect event after every allowed call (succeeded, failed or unknown), since an allow followed by silence is the one record an incident review can't use once the action has reached an outside system.

I bind approvals to payload hashes and fail closed at dispatch here: https://gist.github.com/renezander030/ad81c7a805a09a844983f881e2c487e5