Every payment crosses seven decision gates.

The Decision Trust Protocol screens each agent payment in the authorization window: seven decision gates and two system steps, resolved in 23 milliseconds, on the rails you already run. Decisions are APPROVE, DECLINE, or STEP_UP, and every one is advisory: your engine keeps final authority.

Book a demo Engine docs

Why this exists

Because the window is the only place prevention exists.

Everything after authorization is recovery: chargebacks, clawbacks, write-offs. Years of operating card programs taught us that the milliseconds of the authorization window are where a loss is prevented or accepted. So that is where we built.

The second reason is what the research says about defending agents. Detectors that read a hijacked agent's text get bypassed by whoever moves second; deterministic constraints on the action hold. The pipeline never trusts what an agent believes. It checks what the agent is allowed to do, and the public benchmark shows the difference: 75.0% attack success undefended, 1.4% behind the mandate stack.

The pipeline

Seven decision gates. Two system steps.

01 · Agent resolveIdentify the agent; load its mandate, trust tier, and behavioral profile from the registry.

02 · Intent verificationParse the intent context; validate reasoning quality, confidence calibration, and task alignment.

03 · Anomaly gateSix-dimensional anomaly detection against the agent's behavioral baseline, scored with EDQS.

04 · Mandate enforcementVerify the transaction against spending limits, merchant allowlists, and time-of-day policies.

05 · Behavioral overlayAssess the agent's current behavioral state (degradation, drift, prompt injection) before the network sees it.

06 · Risk scoringComposite risk across merchant reputation, transaction patterns, velocity, and geographic signals.

07 · KYA decisionGenerate the Know Your Agent trust score and map it to a trust zone.

S1 · Persist + webhooksWrite the decision to the hash-chained audit log; fire webhooks for downstream systems.

S2 · Async post-decisionEnqueue behavioral model updates, regulatory checks, and cross-agent correlation.

Two rails

Card and x402. One trust engine.

On the card rail, decisions travel as advisory risk data in ISO 8583 authorization fields. On the x402 rail, approvals bind a signed attestation to one exact USDC transfer on Base. Same gates, same mandates; the rail only changes the evidence.

Back office overview with fleet trust score, authorization pipeline, and outcome split — Decision overview · demo environment

What's different

Prevention in the window, not detection after it.

In the authorization windowThe decision happens before money moves, inside your latency budget: 23 ms P50, under 100 ms P95, under 200 ms P99. Not a batch fraud score that arrives after settlement.

Action-constraining, benchmark-provenThe gate never inspects injected text; it constrains the action. A hijacked agent may believe anything and still cannot move money outside its mandate. Public result: attack success 75.0% to 1.4% at 68.8% task utility on AgentDojo, re-runnable by anyone.

Honest failure semanticsFail-closed by default. If we cannot be consulted, the advisory answer is a decline recommendation; fail-open below an amount threshold is your documented, per-principal choice, decided before certification.

Advisory, in writingYour engine keeps final authorization authority, and the liability allocation in the MSA reflects it. We strengthen your decision; we do not take it from you.

← 01 · IdentityKnow Your Agent Next · 03 · RecordSystem of record →

Inside the window or pre-presentment.

Issuers consult the protocol during decisioning; agent platforms call it before a transaction exists. Both get the same enriched, advisory decision.

I'm an issuer / processor I'm an agent platform