A Signed Input Can Still Be Ignored by an AI Agent

Yesterday I wrote that a transaction hash is not an audit trail for onchain automation.

A commenter raised a harder question:

If an authorization commits to an external context field, can we prove that the field actually influenced the downstream decision?

The short answer is: not from the commitment alone.

Imagine this flow:

1. A risk service produces a signed BLOCK assessment.
2. The application hashes that assessment into an authorization.
3. A principal signs the exact transaction.
4. The transaction executes exactly as authorized.

Every signature and hash may verify.

But the application could still have ignored the BLOCK result and continued anyway.

The evidence proves that the assessment existed and was carried through the workflow. It does not automatically prove that the assessment was load-bearing.

Integrity, binding, and influence are different claims

I now think agent evidence needs to distinguish at least three properties of an input:

Property	What it establishes
Integrity	The input came from the claimed signer and was not modified
Binding	The authorization committed to those exact input bytes
Influence	Changing or removing the input changes whether the action may proceed

A signature can establish integrity.

A context commitment can establish binding.

Neither one, by itself, establishes influence.

How can we test whether an input is load-bearing?

I am finding four tests useful.

1. Counterfactual test

Replace a valid PASS assessment with a separately valid BLOCK assessment.

The outcome must change from “continue” to “deny.” If both inputs produce the same executable path, the assessment may be decorative.

1. Deletion test

Remove the assessment entirely.

A system that claims to require the assessment should fail closed. If execution still succeeds, the field was optional in practice, whatever the schema says.

1. Bypass test

Find every path that can reach the signer or executor.

It is not enough to add a policy callback to one convenient wallet method if another module can call the signer directly. The enforcement point must cover every executable path.

1. Semantic mapping test

The policy must define what each assessment means operationally.

For example:

PASS    → proceed to exact-call authorization
CAUTION → require a new principal confirmation
DANGER  → deny
BLOCK   → deny
missing, stale, or invalid evidence → deny

Without that mapping, a signed verdict is still just data.

Where Insight and PriorSeal fit

In the composition I am testing:

• Insight produces signed advisory risk evidence.
• A policy or governor consumes that evidence and makes a deterministic decision.
• A principal authorizes the exact call.
• PriorSeal binds referenced evidence to that authorization and checks whether the observed execution matched it.

The important boundary is that PriorSeal can verify an exact commitment, but it cannot infer from an opaque digest that an external policy actually used the committed data.

That claim has to be supported at the composition layer—with an enforced gate, explicit decision evidence, and negative tests that fail when the input is changed, removed, or bypassed.

So I would extend yesterday’s three questions:

1. What informed the decision?
2. Which inputs materially constrained the decision?
3. What exact action was authorized?
4. What actually happened?

For developers building agents that can move money, modify infrastructure, send messages, or call privileged APIs:

What evidence would convince you that an input was genuinely load-bearing rather than merely signed and carried along?