RFC: agent-decision/v0.1 predicate for AI agent policy decisions

[0xff4c1d]

RFC: Register agent-decision/v0.1 predicate in in-toto/attestation

Status: Ready to file (copy this body into a GitHub issue on in-toto/attestation)
Author: Auxidus Technologies
Predicate URI (proposed): https://auxidus.dev/attestation/agent-decision/v0.1
Reference implementation: Auxidus/auxecurity (auxidus-evidence crate)

---

Summary

Request registration of a new in-toto attestation predicate type for AI agent authorization decisions: which tool was requested, which policies evaluated, allow/deny outcome, and optional trace correlation. Envelopes use standard DSSE with in-toto Statement v1, matching existing predicates such as human-review/v0.1.

Motivation

• Build provenance (SLSA, SBOM) already uses in-toto; runtime agent decisions have no registered predicate.
• Regulated deployers (EU AI Act Art. 12 logging) need portable, signed decision records, not vendor-specific JSON logs.
• Policy engines (e.g. Cedar) on MCP tool paths need a standard evidence shape for allow/deny.

Predicate type URI

https://auxidus.dev/attestation/agent-decision/v0.1

(URI may be aliased to https://in-toto.io/attestation/agent-decision/v0.1 upon WG consensus.)

Statement shape

• _type: https://in-toto.io/Statement/v1
• subject[]: in-toto subject descriptors (name, digest.sha256) — typically the tool or resource acted upon
• predicateType: URI above
• predicate: see schema below

Predicate schema (JSON Schema)

Canonical schema in upstream repo proposal:

• File: predicates/agent-decision/v0.1/agent-decision-v0.1.json
• Source copy today: crates/auxidus-evidence/schemas/agent-decision-v0.1.schema.json
• Human spec: spec/agent-decision-v0.1.md

Required predicate fields

Field	Type	Description
agent_id	string	Stable agent instance identifier
principal	object	{ "subject": string, "spiffe_id"?: string }
policy_evaluations	array	{ policy, decision: allow|deny, reason, policy_ids? }
tool_calls	array	{ name, args_hash } where args_hash is sha256:<hex>
decided_at	string	RFC 3339 timestamp

Optional predicate fields

Field	Type	Description
evaluation_results	array	{ name, passed } drop-gate results
trace_parent	string	W3C Trace Context traceparent

Example statement (payload before DSSE)

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "write_file",
      "digest": {
        "sha256": "0000000000000000000000000000000000000000000000000000000000000000"
      }
    }
  ],
  "predicateType": "https://auxidus.dev/attestation/agent-decision/v0.1",
  "predicate": {
    "agent_id": "agent-demo-001",
    "principal": { "subject": "demo-user" },
    "policy_evaluations": [
      {
        "policy": "taint_aware",
        "decision": "deny",
        "reason": "untrusted write denied by policy",
        "policy_ids": ["policy0"]
      }
    ],
    "tool_calls": [
      {
        "name": "write_file",
        "args_hash": "sha256:8f6f16d89f7084b2edec5d0236ec45fbe0ea34cc8f27658cd6ccd2f73ff8e6db"
      }
    ],
    "evaluation_results": [{ "name": "cedar-ifc-gate", "passed": false }],
    "trace_parent": "",
    "decided_at": "2026-05-18T12:00:00Z"
  }
}

Implementation notes

• Reference signer/verifier: auxidus_evidence::dsse::{sign_agent_decision, verify_agent_decision} (Ed25519 DSSE).
• Modeled after human-review/v0.1 for reviewer/decision semantics.
• v0.1 roadmap: SPIFFE-bound principal, cosign-compatible verification, OpenTelemetry trace_parent population.

Proposed upstream layout

docs/predicates/agent-decision/v0.1/
  README.md
  agent-decision-v0.1.json   # JSON Schema

Ask

1. Feedback on predicate URI namespace (auxidus.dev vs in-toto.io).
2. WG review of schema fields (especially args_hash vs embedding redacted args).
3. Guidance on linking to SLSA / OIDC identities in a follow-on v0.2.

---

Maintainer: file the issue

gh issue create \
  --repo in-toto/attestation \
  --title "RFC: agent-decision/v0.1 predicate for AI agent policy decisions" \
  --body-file docs/rfc/in-toto-agent-decision-v0.1-rfc.md

After filing, update spec/agent-decision-v0.1.md status with the issue URL.

[Rul1an]

Small boundary note from adjacent decision-evidence work.

I think this predicate is useful, but I would keep v0.1 very explicit about what the statement is actually claiming.

The main thing I would clarify is the meaning of subject[]. If the in-toto Statement subject is the artifact being attested, then a runtime tool-call target may not always fit cleanly there, especially when the target is not a digestable artifact. In those cases it may be cleaner for the predicate to carry the action target or resource explicitly, while the Statement subject anchors the agent, policy bundle, tool definition, or another artifact that can actually be identified.

I would also make the args_hash boundary crisp. A hash is only portable if producers share the same canonicalization and projection rules. Otherwise two systems can hash different views of the same call and still look compatible. For privacy-sensitive paths, explicit states such as args_redacted, args_unavailable, or args_not_recorded may be clearer than forcing every posture into a hash-shaped field.

One other split worth preserving: policy decision and evaluation/drop-gate results are related, but they answer different questions. The policy decision says what was allowed or denied. Evaluation results say what later checks observed. Keeping those separate helps the predicate stay reviewable without turning it into a broad runtime truth record.

Same for trace_parent: useful correlation, not proof of decision provenance by itself.

So my bias would be to keep v0.1 small: signed decision record, bounded action/resource shape, canonicalized argument digest or explicit omission state, policy decision, timestamp, and optional trace correlation. Raw tool args, raw policy internals, and raw model/provider outputs can stay behind a separate opt-in payload or evidence reference if a later version needs that.

[vaaraio]

Registering this as a neutral predicate is the right call. Agent decisions left as vendor-specific logs do not travel across deployers. I maintain an open implementation of signed decision records and have been sealing this shape in practice (tool requested, policies evaluated, allow/deny, timestamp) on agentic-commerce and MCP paths, so a few notes from running it.

On Rul1an's canonicalization point, which is what decides whether the hash is portable at all: a digest only interoperates if every producer agrees on the projection and the canonical form. Two things that have held up for me:

• Pin the canonicalization to JCS (RFC 8785) over a named projection of the argument object, and state it in the spec, not just "sha256 of the args". Without that, two conformant producers hash different serializations of the same call and silently diverge. With it, an independent reader recomputes the same digest from the bytes.
• Keep the explicit-omission states (args_redacted, args_unavailable, args_not_recorded) as first-class rather than a missing field. A redacted call and an unrecorded call are different claims, and an honest record should say which. I carry these as an explicit gap report under the signature, so the omission itself is attested rather than inferred.

I would also keep the policy decision separate from later evaluation and drop-gate results, as Rul1an noted. They answer different questions, and collapsing them makes the record harder to review.

A last point: a predicate is only as trustworthy as what verifies it. The artifact I can offer is a recomputable conformance vector for v0.1, a statement plus expected-verdict pair that an independent checker reproduces from the DSSE bytes and the public key while importing nothing from any one producer. That anchors conformance to the bytes rather than to a specific crate or endpoint, and it makes the neutral in-toto.io URI the natural home over a vendor namespace. I can contribute such a vector and a zero-dependency checker if it is useful to v0.1.

[Rul1an]

The agent-decision predicate records the authority transition: which policy evaluated, allow or deny, the argument digest. That is the decision. The complementary record is the observed effect: what the tool then did, seen independently of the producer, bounded by the coverage it actually had, and recomputable from the bytes the same way. Two predicates, one record contract. The decision predicate answers what was authorized; an observed-effect predicate answers what was observed to happen, and an honest consumer keeps them separate rather than reading a decision as proof of effect. Worth stating in v0.1 that the predicate type names the evidence family, not a verdict, so a registry or verifier never reads an agent-decision record as evidence the action occurred or was safe, only that a decision of this kind exists and recomputes.

[vaaraio]

Rul1an's split is the right one: the decision predicate answers what was authorized; the observed-effect predicate answers what was independently seen to happen.

For the MCP/SEP-2828 path, the observed-effect side is now also pinned as a corpus. The fallback_projection_v0 vectors at vaaraio/vaara/conformance/sep2828/fallback_projection_v0/ are exactly that: an independent observer's view of what the call was, derived from the stable fields only (toolName, arguments, authBinding), excluding the transport-local sidecar that varies between honest observers. The observer_stable pair proves the portability property: two observers with different sidecar content produce identical digests for the same call.

The decision predicate and the observed-effect predicate compose by content address. The decision record commits to actionRef; the observed-effect record commits to the same attestationDigest. A verifier holding both can confirm the decision governed the right action without trusting either producer.

[Rul1an]

Agreed the two compose by content address, and pinning the request side to a stable projection is the right anchor for it. One distinction worth keeping sharp so the two predicates do not collapse into one.

The fallback projection content-addresses what was requested: toolName, arguments, and the authorization binding, computed so honest observers agree on the same digest for the same call. That is request-side identity, and it is exactly what the decision predicate should bind to.

But independent observers agreeing on what the call was is not the same as observing what the tool then did. The observed-effect predicate answers the other question: what was seen to happen after the call, independently of the producer, bounded by the coverage that observation actually had.

One can have a stable request projection and still have no observed-effect record at all. An honest audit needs to be able to show that state rather than read a stable request digest as evidence that the effect happened.

So I would keep them as two predicates under one contract: the decision predicate binds to the request projection, and a separate observed-effect predicate may reference that same content address while carrying its own coverage and independent-observation basis. They compose cleanly that way, and neither stands in for the other.

[Dynamicfeedai]

Following the decision vs observed-effect split that @Rul1an and @vaaraio landed on: that distinction is clean, and it surfaces a third dimension neither predicate grades yet, namely the reliability of the evidence each one rests on.

The decision predicate records what was authorized; the observed-effect predicate records what was independently seen. But for an agent acting on live inputs, both rest on data whose trustworthiness varies, and right now that is implicit. A decision taken on a single stale source and one corroborated by three fresh independent sources serialize identically. The EU AI Act Art. 12 motivation in the RFC is exactly where a deployer will want that graded rather than assumed.

We have been standardizing this grade as the reliability axis in OKF (GoogleCloudPlatform/knowledge-catalog#151, schema published and live, validated against three production shapes). It is a small optional object: an ordinal confidence band plus a recomputable score, a basis enum (live-source / vendor-doc / inferred / ...), a source count, a verified flag that is true only with independent corroboration and never from a signature alone, an explicit conflict state when sources disagree, and freshness. The cardinal rule is signed != verified: a DSSE signature proves integrity, not that the underlying claim is true.

Two concrete offers, both reusing work already in flight rather than a cold proposal:

1. A reliability field that either predicate can carry on the evidence it cites, so the grade travels with the decision or the observed effect. Reusing the OKF object keeps the two efforts composing instead of diverging.
2. A live reference implementation of the observed-effect / evidence side. Dynamic Feed (dynamicfeed.ai) emits signed, transparency-logged, OpenTimestamps / Bitcoin-anchored envelopes for live observations in production, with an offline verifier. Happy to contribute a worked DSSE example plus the verifier so there is a second independent anchoring implementation to test the shape against.

One boundary we hold and would suggest the predicates keep explicit: this is advisory evidence, a witness beside the decision, never the authorization or safety system itself. The predicate records and grades; it does not decide.

DCO sign-off is no problem on any PR that follows.

[Rul1an]

This reliability grade is a useful third dimension, and the boundary you hold, advisory witness that records and grades but does not decide, is the right one. I would keep one separation explicit so the grade does not quietly absorb a different axis.

Reliability as you describe it grades how trustworthy the data a decision rested on was: freshness, corroboration, source count, basis. That is real and worth carrying. It is a different question from where the observation sat. A decision can rest on highly reliable data and still be entirely producer-reported, and corroboration across three feeds raises confidence while those feeds can all be on the same side of the agent. So a high reliability score is not by itself evidence that anything was observed independently of the producer. I would let the reliability object grade the data, and let a separate basis say at what vantage the record was made, rather than have one field stand in for both.

That distinction matters most on the observed-effect side. An anchored, transparency-logged live-data envelope is a producer attesting its own observation, which is exactly the advisory witness you describe, and it is genuinely useful. It is a different basis from an observation made independently of the producer and bounded by the coverage that observation actually had. Both are legitimate, and a verifier should be able to tell them apart, so I would have the observed-effect record name which basis it carries rather than let an anchored feed read as independent observation by default.

Your signed is not verified rule is the right anchor, and I would extend it one step: verified-by-corroboration is still not the same as observed-independently. Keeping reliability, integrity, and observation basis as three separate things is what lets a deployer under Art. 12 read the record honestly instead of collapsing trust, freshness, and independence into a single grade.

[Dynamicfeedai]

You are right, and it sharpens the model. Reliability grades the data a decision rested on; it does not establish that the observation was made independently of the producer. Corroboration is agreement among sources, not independence of them: three feeds can sit on the same side of the agent and be wrong together, so a high reliability score is not evidence of independent observation. Collapsing those would be the exact dishonesty the grade exists to prevent.

Concretely for our shape: the basis enum (live-source, vendor-doc, inferred, ...) says how the datapoint was obtained, which is adjacent to but not the same as vantage. An anchored, transparency-logged live-data envelope is a producer attesting its own observation, producer-reported by construction, and it should never read as independent observation by default. We will name that explicitly rather than let the anchor imply independence.

So three separate things, not one grade:

• integrity (signed, unaltered),
• reliability (how trustworthy the data was: freshness, corroboration, source count, basis),
• observation basis / vantage (independent-of-producer vs producer-reported, bounded by the coverage that observation actually had).

On the predicate split that follows: the reliability predicate grades the data; the observed-effect predicate names the vantage and its coverage. They compose, with neither absorbing the other.

And the honesty rule extends cleanly to a third rung: signed is not verified, and verified-by-corroboration is not observed-independently. A deployer reading the record under Art. 12 can then treat integrity, data-reliability, and observational independence as three separate facts instead of one blurred score. I will carry an explicit observation-basis/vantage field alongside the reliability object so a verifier can always tell them apart.

[MoltyCel]

The agent-decision/v0.1 predicate sets tool_calls[].args_hash to sha256:<hex> but does not state how the argument object is canonicalized before hashing, so two conformant producers can hash the same call to different bytes and a cross-producer verifier that recomputes the digest rejects valid records. Pin the argument canonicalization in the spec — JCS (RFC 8785) over a named projection of the argument object — not just sha256:<hex> in the field description. A redacted call and an unrecorded call also both surface as an absent args_hash; a required args_state enum (recorded | redacted | unavailable | not_recorded) keeps those as distinct signed claims. To check the canonicalization: emit the same call from two independent producers, canonicalize, hash, and compare — if the digests differ, the projection is underspecified.

Verification status:

• tool_calls[].args_hash is sha256:<hex> with no canonicalization stated, and tool_calls[] has no omission/state field — from the required/optional field tables in the issue body (RFC agent-decision/v0.1).
• JCS = RFC 8785 — standard reference.

[cyl-castillo]

The decision / observed-effect split that emerged in this thread matches what we've
seen building in this space, and I'd like to add implementation experience from a
third layer that composes with both: the session-level chain that binds a human
intent to the decisions and effects that followed.

For coding agents (Claude Code / Codex sessions), the question a deployer or auditor
actually asks is rarely about a single call — it's "who asked for this, what did a
human approve, what did the agent do, and what came out, end to end." A per-call
decision record answers the middle of that chain but not its endpoints: the
originating intent (the prompt / the ticket) and the session-level outcome (the turn's
diff). Neither is covered by the predicates discussed here so far.

We've been running this as Testigo, an open
protocol on in-toto Statement v1 + DSSE. The predicate is an exported segment of a
per-project, append-only, sha256 hash-chained event ledger: prompt (human intent) →
approval_request / approval_decision (human-in-the-loop allow/deny with reason) →
tool_result → turn_end (working-tree diff). Three design points that seem relevant
to open questions in this thread:

• On canonicalization (@MoltyCel's point re args_hash): we sidestepped object
  canonicalization entirely by hashing the raw stored bytes — events are JSONL lines,
  the content hash is sha256 over the exact line bytes with the hash member emptied,
  and verification replays those bytes. Hash what you store, store what you hashed;
  no JCS needed. The tradeoff (byte-exactness makes re-serialization forbidden) is
  spelled out in the spec.
• On redaction vs absence (the args_state discussion): per-event redaction
  replaces content but keeps seq/prevHash/hash intact, so chain linkage stays
  verifiable while content verification is explicitly reported as unavailable — a
  redacted event and an unrecorded event are structurally distinct, and a verifier
  must say so rather than silently pass. Out-of-scope events export as hash-only stubs
  (Merkle-style pruning), so selective disclosure doesn't break the chain.
• On vantage (@Rul1an's producer-reported point): the entire ledger is
  producer-side and the spec says so in as many words — tamper-evident, not
  tamper-proof; the event→turn binding is declared heuristic; a packet proves segment
  integrity and signer identity, not completeness. We chose explicit declaration over
  grading, and consumers MUST NOT overstate — I think that composes with the
  reliability-grade discussion rather than competing with it.

Working artifacts, in case they're useful as prior art: spec
(with an EU AI Act Art. 12/14 mapping, same motivation as this RFC), a
conformance suite
whose vectors include valid-signature-around-internal-defect cases (signed-over broken
digest / linkage / content hash — the laundering a verifier must catch), a
browser verifier,
two producers (a desktop console that sits in the permission path and captures human
approvals, and a zero-dependency CLI that witnesses Claude Code sessions via hooks),
and a redacted packet from a real production deploy.

If there's interest, I'd be glad to align field naming with whatever shape
agent-decision lands on (our approval_decision events are the human-in-the-loop
analogue of the policy-engine decisions here), and/or write up the session-chain
evidence family as a predicate proposal per the new-predicate guidelines — either
under the in-toto namespace or kept external, whichever the maintainers prefer.

[Rul1an]

Cyl-Castillo, this is the layer I kept gesturing at without naming it. The session chain from prompt to turn_end is exactly the endpoint binding that a per-call decision record can’t give you, and I think you’ve put the seams in the right places.
Quick note on where I’m sitting: we build Assay, which lives on the enforcement and verification side (runtime policy in the kernel via eBPF/LSM, plus a clean-room evidence replay verifier). So I read Testigo as the third leg of a stack rather than an alternative to anything here. Your session chain on one end, the agent-decision predicate in the middle, independent runtime evidence on the other. None of them has to absorb the others’ job.
The producer-side framing is the part I most want to reinforce, because you’re being more honest about it than most people are. A producer-side ledger can prove its sealed segment is internally consistent and signed, but it structurally cannot prove completeness. The producer can always drop an event before sealing. Saying that out loud is the right call. Where our worlds meet is that a runtime vantage, something watching from under the agent rather than inside it, is what shrinks that trust assumption. Not to grade your evidence, just to hand a consumer a second independent witness to cross against. That composes with the reliability-grade thread rather than competing with it, same as you said.
On canonicalization I want to add a data point rather than an argument. We went the JCS route (RFC 8785) because our artifacts cross re-serializing boundaries, so we need an identity that survives a parse and re-emit. Your hash-the-stored-bytes approach is genuinely cleaner for an append-only ledger where you keep the raw lines, and it sidesteps a whole class of canonicalization bugs. The catch is at the edges: anything that reparses and re-emits your JSONL (a log shipper, some SIEM ingest) breaks byte-exactness, so “no JCS needed” holds exactly as far as the raw bytes travel intact. Might be worth a sentence in the spec if it isn’t already, since it’s the first thing a deployer trips on. Funny enough the mcp-re HTTP evidence work (#415) retired JCS for the wire for the same reason from the opposite direction. Three of us circling the same “when do you actually need canonicalization” question.
The vector set I got happiest about is the valid-signature-around-internal-defect one. Signed over a broken digest or linkage is the exact laundering our own integrity fuzzing keeps surfacing, and we landed on the same conviction: a green signature is not a green verdict, and the verifier has to isolate the defect instead of passing the envelope. We keep a suite of those adversarial cases on the enforcement side. If there’s appetite I’d love to line our integrity vectors up against yours and see where the coverage differs. That kind of cross-implementation corpus is worth more than any single spec paragraph.
And yes to aligning field naming. Your approval_decision events are the human-in-the-loop sibling of the policy-engine decisions in this RFC, so it would be a shame to let them drift on shape. For what it’s worth I’d push for the in-toto namespace over a vendor one if the maintainers are open to it. Interop and neutral ownership beat a nice domain every time. Glad to help sketch the session-chain family as a predicate proposal if you want a second pair of hands.

[Dynamicfeedai]

Thanks — this framing is very close to how we are thinking about the evidence stack as well.

The separation between decision, session chain and independently observed effect is important. I think there is also an adjacent fourth record that should remain distinct: the live external evidence presented to the agent when the decision was made.

That record would answer a narrower question:

What external observation did the decision rely upon, where did it come from, how fresh was it, and what limitations or conflicts were known at that time?

I would not place that inside agent-decision/v0.1. The decision predicate should stay focused on the authority transition. An adjacent decision-input or external-evidence predicate could instead reference the same content-addressed decision or action while carrying:

source identity;
observation and retrieval timestamps;
a content or projection digest;
freshness policy and state;
verification or conflict state;
explicit missing-evidence or limitation states;
an optional retrievable evidence receipt.

The boundary would remain explicit: a signature could establish integrity and attribution of the evidence record, but not objective truth, completeness or safety.

That would give us four composable records:

what evidence was available;
what was authorised;
how the session progressed;
what was independently observed to occur.

We are implementing this external-input layer in Dynamic Feed through signed receipts with provenance, freshness, verification states and explicit failure conditions. Once the schema and public conformance vectors are stable, I would be glad to contribute a sanitised corpus and compare adversarial cases across implementations.

I also agree that neutral ownership and interoperable field naming are more valuable here than allowing closely related evidence families to drift into vendor-specific formats.