Why a Successful Agent Transaction Can Still Fail Authorization Checks

An AI agent submits a transaction. It executes without reverting, and the dashboard displays “Success.”

That label leaves an important question unanswered: did the agent execute the call the user authorized?

Consider a hypothetical swap. The user approves calldata that sends the output to wallet A. The observed transaction uses the same chain, executor, and nonce, but different calldata directing the output to wallet B.

The execution can complete while the authorization comparison fails.

A transaction review needs three separate results:

• Evidence validity: do the receipt, signatures, hashes, and supported relationships pass verification under the reviewer’s trusted configuration?
• Execution outcome: what execution state does the evidence report?
• Authorization compliance: does the correlated execution match the signed authorization within the supported checks?

In PriorSeal receipt v3, a verifier summary can therefore look like this:

{
  "valid": true,
  "code": "OK",
  "outcome": "COMPLETED",
  "executionStatus": "CONFIRMED",
  "complianceStatus": "NON_COMPLIANT"
}

This is an illustrative result, not a record of a live transaction.

The issuer signed a record of the mismatch. The verifier can accept that record while confirming that the observed call differed from the authorization. In the calldata example, the receipt’s compliance reasons include CALLDATA_MISMATCH.

Editing the receipt after signing would be a different problem: its integrity verification would fail.

Keep those results separate in the application.

Here is a small integration outline using the local verifier:

import { verifyReceiptLocally } from 'priorseal-sdk/verifier';

const result = await verifyReceiptLocally(receipt, {
  trustedKeys: confirmedKeys,
  expectedAudience: confirmedAudience,
});

if (!result.valid) {
  throw new Error(result.code);
}

if (result.requiredExternalChecks.length > 0) {
  throw new Error('Complete the required external checks first');
}

console.log({
  evidence: 'VERIFIED_WITHIN_LOCAL_SCOPE',
  execution: result.outcome,
  authorization: result.complianceStatus ?? 'NOT_ASSESSABLE',
});

The application supplies the exported receipt, independently confirmed issuer keys, and the expected deployment audience. A key included in an imported bundle does not establish its own trustworthiness.

The SDK verifier documentation describes the supported checks. ERC-1271 authorization and EVM anchor evidence can require additional chain-state verification. The local verifier reports those requirements explicitly.

“Not assessable” also needs its own place in the interface.

Missing evidence, insufficient finality, a reorg, or an unrelated transaction may prevent the verifier from assessing authorization compliance. Those cases should remain NOT_ASSESSABLE.

A confirmed transaction with the expected chain, executor, and nonce but changed calldata provides a different result: an attributable mismatch.

These distinctions also explain why authorization review and market risk assessment remain separate. An authorized trade can still produce a poor economic result. Insight supplies oracle and risk assessments; PriorSeal supplies authorization and execution evidence. Their combined workflow preserves both scopes.

A receipt records the evidence available for review. Preventing an unauthorized transaction also requires the signing and submission paths to enforce the authorization checks.

If your application currently displays one “Success” badge, what would a user see when execution completes but the authorization comparison fails?