AI Agent Verification Example: From STEP-UP to ALLOW
Three signed records show how the same $0.01 USDC request moved from an over-strict BLOCK to STEP-UP and then ALLOW as verifiable evidence improved.
On this brief
What This AI Agent Verification Example Shows
FLINT submitted the same $0.01 USDC transaction shape on Base through 3 versions of the verification journey. The wallet and amount stayed constant. The available evidence and decision rules changed. The first record returned BLOCK at score 0. After calibration, the cold-start case returned STEP-UP at score 60 with specific remediation actions. After the agent presented a claimed passport, declared scope, and matched the passport-bound wallet, the third record returned ALLOW at score 100 under that record's rules version.
All 3 records are public and signed. That makes this more than a product story. A reader can compare the evidence, verdict, reason codes, and rules version instead of accepting a screenshot or summary on faith.
The First Attempt: BLOCK at Score 0
The earliest build of the decision model had no tolerance for the unknown. An anonymous agent with no passport, no declared scope, and no principal attestation received BLOCK at score 0. The record contained no affirmative sanctions, blocklist, tampering, or mandate-violation finding among the checks it evaluated. The available evidence did not establish that the transaction was legitimate; it showed that the model was treating missing information like adverse evidence.
That distinction matters because missing evidence and adverse evidence require different responses. An unknown agent may need to provide more proof. A compromised or sanctioned agent may need to be stopped. Treating both cases as BLOCK creates avoidable declines and gives the caller no path to resolve uncertainty.
The Fix: STEP-UP, Not a Rejection
Rules v1.3.0 changed the cold-start answer to STEP-UP at score 60. STEP-UP means the current evidence cannot support automated execution yet. It is not a fraud accusation and it is not a permanent rejection.
The response includes a machine-readable remediation menu. In this case, the relevant actions were mint_passport, declare_authorization_scope, and attach_principal_attestation. Each action identifies evidence the next verification can evaluate. BLOCK remains distinct because it requires affirmative adverse evidence under the applicable rules, such as a confirmed sanctions match, tampering, failed authority, a revoked or frozen credential, or a mandate violation.
The Third Attempt: Minting, Declaring, Paying From the Bound Wallet
The agent then minted and claimed an Agent Passport, declared an authorization scope for the amount, counterparty, and time window, and submitted the same $0.01 USDC request from the passport-bound wallet.
FLINT resolved the passport, checked its signature and lifecycle state, read the declared scope, and compared the paying wallet with the passport binding. Under the rules version attached to the third record, that evidence supported ALLOW at score 100. The signed record preserves exactly which evidence produced that result, so later rule changes do not rewrite the historical decision.
A wallet match is useful control evidence, but a passport ID or wallet association is not universal purchase authority. Higher-risk commerce flows can require fresh, transaction-bound proof that covers the specific action, amount, counterparty, and expiry.
What Persists and What Must Be Rechecked
A passport gives identity and reputation a durable attachment point across transactions, restarts, and redeploys. Verified historical outcomes can strengthen future context without forcing the agent to rebuild its identity from zero each time.
Transaction authority does not persist in the same way. The amount, destination, action, mandate version, timing, and runtime evidence can change. FLINT therefore rechecks the current transaction even when the agent has a strong passport and prior history.
Why a Copied Passport ID Is Not Authority
A passport ID is a reference, not a secret. Anyone who sees it may be able to resolve the public passport. Resolution proves that the credential exists. It does not prove that the presenter controls the agent, wallet, or principal authority associated with it.
Control evidence must come from verifiable bindings. In this case, the paying wallet had to match the wallet bound to the passport before the record awarded that evidence. Other transaction types can require signed operator identity, workload attestation, a single-use authorization, or another transaction-bound proof.
How to Read the 3 Signed Records
Compare the records in the same order every time: transaction fields, agent and principal evidence, authorization scope, screening availability, reason codes, rules version, score, verdict, and signature. The rules version explains why the first and second records treated the same cold-start evidence differently. The evidence sections explain why the third record changed again.
Do not compare the score alone. A score compresses evidence for display. The verdict, reason codes, unavailable checks, and hard policy conditions explain what the caller should do.
What These Records Do Not Prove
These are Verify decision records. They show the evidence FLINT evaluated, the rules version, and the resulting transaction verdict. They do not prove that a governed tool invocation was allowed, that an allowed tool executed successfully, that the payment settled, or that a seller fulfilled the request.
FLINT Command produces separate invocation-decision and execution-outcome evidence for calls that pass through the managed pilot. Linking those records under shared identifiers preserves the chain without turning one signed decision into a claim about events it did not observe.
The Public Record
The wallet and $0.01 USDC amount on Base stayed constant. The decision rules changed between the first 2 records, and the third record added passport, scope, and wallet-binding evidence.
- BLOCK · Score 0 flint.network/records/frv_01M03W7E1VMED5WG4CZV788752
- STEP-UP · Score 60 flint.network/records/frv_01M044DG14A1189B9XY9HB0Z9H
- ALLOW · Score 100 flint.network/records/frv_01M044E941C4DAW1GFW5R841BW
Common Questions
Why did the same wallet get 3 different verdicts for the same 1-cent payment?
Because the evidence and rules version changed. The amount and wallet were constant, but the first 2 records used different cold-start calibration and the third added a claimed passport, declared scope, and wallet binding.
Is STEP-UP the same as being rejected?
No. STEP-UP is appropriate when the current evidence cannot support automated execution and no hard policy condition requires BLOCK. It includes a remediation menu for a fresh decision.
What does BLOCK require now that it did not require before?
BLOCK requires affirmative adverse evidence under the applicable rules, such as a confirmed sanctions match, tampering, failed authority, a revoked or frozen credential, or a mandate violation. Missing history by itself supports STEP-UP, not BLOCK.
The 3 records preserve a useful lesson: uncertainty needs a path to resolution, adverse evidence needs a hard stop, and every decision needs a verifiable receipt.
Primary Sources
Related Academy Briefs
Get in touch
If you are building on agentic payment rails and want to talk through how FLINT fits your stack, reach out directly.
contact@flint.network