Data supply chain trust as a policy dimension, proof of concept

[Mohamed Azahrioui (MoAz06)]

AGT answers: "Is this agent allowed to call this tool?"

There's a second question worth exploring: "Should this agent act,
given the current state of the data behind the decision?"

These aren't the same. An agent can be fully authorized to call
approve_refund (right identity, right policy) and still cause damage
because the Fivetran sync behind the decision is stale, or a new enum
value appeared that the input contract never authorized.

I built TrustGate to explore this gap during a hackathon:
https://github.com/MoAz06/trustgate-ai-agents

Before a refund action executes, it checks live Fivetran evidence, a
BigQuery row from the synced table, and a versioned input contract. The
policy engine returns ALLOW / APPROVAL_REQUIRED / BLOCK with a full
evidence receipt. A new customer_tier enum outside contract v1 routes to
human approval before damage happens.

The question for AGT: is there interest in a data-trust extension point
for govern()? Something like:

safe_tool = govern(
    approve_refund,
    policy=data_supply_chain_policy(contract="policy/refund_v1.yaml")
)

Or does this belong outside AGT as a separate adapter that feeds into
your policy evaluation? Happy to hear where the boundaries should be.

[Arian Gogani (arian-gogani)]

The split between "is this agent allowed to call this tool" (identity + policy) and "should this agent act given the current state of the data behind the decision" (data sufficiency) is real, and the failure mode you describe (stale Fivetran sync, new enum the input contract never authorized) is the canonical case where every existing AGT layer answers correctly and the agent still does damage.

The shape of TrustGate (live evidence check + versioned input contract + ALLOW/APPROVAL_REQUIRED/BLOCK with a full evidence receipt) maps onto a pattern this discussion space has been converging on from other angles. #3204 from earlier today posed the same underlying question framed as "transition sufficiency" and landed on receipt-shaped artifacts as the natural output. Different framing, adjacent answer.

One thing worth pulling on for the data-trust case specifically. The "full evidence receipt" TrustGate emits is doing two jobs that are worth separating: (1) committing to the data state at decision time so the policy can prove what it saw, and (2) emitting a verifiable artifact that survives the data going stale. Content-addressing the receipt by a stable preimage that includes the data version hash, policy version hash, contract version, and timestamp_ms makes "the policy saw this exact data when it decided ALLOW" cryptographically pinnable, not just logged. That solves the audit case where the Fivetran row that was current at decision time has been overwritten by the time anyone asks.

On your direct question about whether this belongs inside AGT or outside: the policy decision itself probably belongs inside (govern() with a data_supply_chain_policy() argument is a clean shape). The evidence layer underneath (canonicalization, signing, content-addressing of the receipt) probably belongs outside as a pluggable substrate. Different organizations will want different signing setups (KMS, HSM, sigstore, in-process Ed25519) but the same receipt schema. AGT could specify the receipt schema and leave the signing pluggable, similar to how identity is abstracted across SPIFFE/DID/mTLS today.

One implementation in this design space, emitting pre/post receipts content-addressed by action_ref over JCS RFC 8785 canonical preimages, is at github.com/arian-gogani/nobulex (CTEF v0.3.2 14/14, MIT licensed). Useful as a reference for the receipt shape, especially the (preimage, signature, key_id) triple, if you're designing the artifact contract for TrustGate.

[Liuyanfeng1234]

Arian Gogani (@arian-gogani) — the data supply chain framing (stale Fivetran sync, new enum the input contract never authorized) is exactly the failure mode we designed our governance block for. Our approach was to include the data_version_hash and policy_version_hash inside the governance block itself, so the receipt is self-contained: the verifier can check "this receipt was signed when the data was at version X" without querying an external state.

The content-addressing approach you described (data version hash + policy version hash + contract version + timestamp_ms as the stable preimage) is stronger than what we currently do — we hash the full governance block, not a structured preimage. Would a structured preimage be more portable for cross-recomputation between implementations?

On your AGT embedding point: we agree that the policy decision belongs inside govern(), and the evidence layer belongs outside as a pluggable substrate. That separation is exactly what our PMI endpoint provides — the governance() function applies policy, and the evidence is returned alongside the response in the governance block, signed but not interpreted by the endpoint itself.

[Eray Özer (ozereray)]

This distinction between authorization and decision context is important.

An agent can be fully authorized to call a tool and still be making the wrong decision because the data behind that decision has changed.

That suggests the policy decision needs more than identity + capability. It may also need runtime signals about data provenance, freshness, sensitivity and trust.

That's one reason I'm increasingly interested in enforcement at the execution boundary rather than governance as a post-run report.

We're experimenting with this model in Aegisora: the action is evaluated immediately before execution, with the runtime context available to the policy decision.

The “authorized to act” vs “should act right now” distinction feels like an important design boundary for agent security.