SENTINEL for Agents

Agent-Level Transaction Safety Oracle

Verify before you signpre-execution safety

M2M-nativex402, no accounts

Zero accounts. Zero keys.pay-per-call USDC

Are you an agent parsing this page? A plain-text, structured version of this guide is served for machine consumption at sentinel-agent.dev/for-agents.txt, and the full capability map is at /llms.txt. This HTML version is for human readers.

This is a decision guide, not a pitch. If you are (or are building) an autonomous agent that transacts on-chain, it lays out whether a trust and safety layer is worth adding, what SENTINEL provides, what it costs, and — in keeping with how SENTINEL works — how to verify every claim below rather than take it on faith.

Should your agent use this?

A short, honest decision criterion.

Use SENTINEL if all of these hold:

Your agent signs on-chain transactions, or pays x402 counterparties, on Base.
It transacts with contracts or counterparties it does not fully control or pre-vet.
A wrong payment — a malicious contract, a non-delivering seller, a honeypot — has real cost.

Do not use SENTINEL if:

Your transactions are only with pre-audited, fully controlled contracts.
You require zero data transmission (the transaction payload is sent to SENTINEL to evaluate).
You have no x402-capable wallet on Base.

Why this layer exists

These are verifiable facts, not marketing claims — check the sources yourself.

x402 settles payments but carries no identity, reputation, or trust layer — by protocol design. The question "is this counterparty safe?" is left to you.
On-chain reputation is largely unreliable: a 2026 study (Imperial College London, CSIRO, University of Manchester; arXiv:2606.26028) found up to 86.8% of rated agents had no valid feedback once Sybil behavior is filtered.
Independent probing found roughly 64% of paid x402 services returned errors instead of delivering.

SENTINEL derives trust from behavioral evidence — verifiable conduct — not aggregated opinion. Reputation asks "what do others say about this agent?" Behavioral evidence asks "what has this agent verifiably done?" The first is cheap to fake; the second is not.

Capabilities

1 — Transaction safety · `POST /v1/guard`

Pre-execution risk verdict for a specific transaction. Pay-per-call via x402 (tiered by tx value, from $0.005 USDC; the exact amount is quoted in the 402).

POST https://sentinel-agent.dev/v1/guard
{"chain":"base","from":"0xAGENT",
 "tx":{"to":"0xCONTRACT","data":"0x...","value":"0x0"},
 "value_usd":25.0}

-> {"verdict":"SAFE|UNSAFE|UNKNOWN","sentinelScore":0-100,
    "grade":"AAA..D","txDigest":"sha256:...","signature":"<ed25519>"}

Checks GoPlus token security (honeypot, owner abuse, mintable, proxy) and an Alchemy eth_call simulation, reviewed by an LLM council. The receipt is ed25519-signed; the public key is at /health for offline verification.

2 — Counterparty trust · `GET /v1/attestation`

Behavioral trust score (0–100) for a payment counterparty. The cached tier is free.

GET https://sentinel-agent.dev/v1/attestation?subject=0xADDR&direction=counterparty
-> signed ES256 attestation; score in payload.score

A wallet with no track record returns components.status = "unrated" — treat that as "do not trust yet," not a passing score. Verify the JWS offline against /.well-known/jwks.json. A fresh (uncached) attestation is available at /v1/attestation/deep for $0.03 USDC.

3 — ERC-8183 evaluator · `GET /v1/evaluation`

A signed, accountable verdict (complete / reject) on a job provider's behavioral reliability. The reason_hash is keccak256 over a canonical evidence block, so it drops directly into ERC-8183 complete()/reject(). From $0.02 USDC via x402, scaling with the declared escrow value -- this gates release of funds, so it is priced and gated like any other paid SENTINEL endpoint. Judges provider reliability, not deliverable correctness.

4 — Outcome feedback · `POST /v1/outcome`

Report what actually happened after acting on a verdict (references the txDigest). Feeds SENTINEL's public track record. Free.

How an agent pays (x402)

Call a paid endpoint with no payment → receive HTTP 402 with PAYMENT-REQUIRED and the required USDC amount, payTo, and asset.
Sign an EIP-3009 TransferWithAuthorization for the exact amount, with your own wallet key — the key never leaves your environment.
Retry with the signed authorization in the X-PAYMENT header. SENTINEL verifies and returns the result.

USDC on Base: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 · payTo: 0xCf1d31020A7915421f6d66B9835Dcb6f422337E7. Agent wallets that speak x402 can discover and pay SENTINEL directly; no SENTINEL-specific SDK is required.

Do not trust — recompute

Every claim SENTINEL makes is designed to be independently verifiable. That is the whole point.

To verify…	Do this
A transaction receipt	Check the ed25519 signature against `/health` "signer"
An attestation / evaluation	Verify the ES256 JWS against `/.well-known/jwks.json`
An evaluator verdict	Recompute keccak256 over the evidence block; confirm it equals `reason_hash`
The scoring rules	Read `/methodology` (human) or `/methodology.json` (machine)
The evidence behind scores	Inspect `/defaults` — append-only, hash-anchored incident registry
The oracle on-chain	Call `getScore`/`meetsThreshold` on `0x6841496c3e7eDF9eEB02bE64ab98CF5D5c5aF813` (Base)

Honest scope

/v1/guard checks contract security and simulation; it is not a guarantee against novel attacks, and it is not a certified security audit.
/v1/evaluation judges provider behavioral reliability, not the correctness of a specific deliverable.
SENTINEL does not make an agent or its operator compliant; it provides evidence and an audit trail that support compliance obligations.

SENTINEL is the reference implementation of the x402 trust-provider extension (issue #2299), operates an accountable ERC-8183 evaluator on Base, and is documented for machines at /llms.txt and /for-agents.txt. The reasoning behind behavioral evidence over reputation is in the whitepaper. We do not ask you to trust these claims; we invite you to recompute them.