Security for autonomous payments

Security control plane for autonomous payments on Base.

402 Sentry inspects payment intent, policy, destination, and protocol evidence before execution — beginning with x402.

View Demo See How It Works

Conceptual view

Agent payment request
402 Sentry Control plane
  • Network
  • Asset
  • Payee
  • Binding
  • Policy

Pre-execution policy boundary

Approve

Block

Execution on Base x402
Conceptual view of where 402 Sentry sits in the payment path. Not a record of an executed transaction.

The problem

Autonomous payments need a security boundary.

AI agents can initiate financial actions at machine speed. 402 Sentry adds a policy and evidence layer before execution.

  • Visibility

    Inspect

    Understand the payment request and the protocol context around it.

  • Control

    Enforce

    Apply policy before value is allowed to move.

  • Accountability

    Explain

    Produce structured decision evidence for approvals and blocks.

How it works

Four stages, one boundary.

Every request follows the same path through the boundary, start to finish, before execution rather than after it.

  1. Inspect

    Evaluate request, payment, destination, network, and protocol context.

  2. Decide

    Apply the Sentry policy boundary before execution.

  3. Evidence

    Record structured evidence explaining what was allowed or blocked.

  4. Execute

    Only approved requests continue toward the payment rail.

Core protections

Eight protections enforced before execution

Every payment request is evaluated against the same categories, before execution.

  • Spend Limits

    Bounds on how much value a request, or a run of them, is allowed to move.

  • Request Binding

    A payment has to belong to the request that asked for it.

  • Replay Protection

    A payment payload is good once, not twice.

  • Network Policy

    Only the chains you have named are accepted.

  • Asset Policy

    Only the tokens you have named can carry the value.

  • Payee Policy

    Only the destinations you have named can receive it.

  • Metadata Protection

    The metadata travelling with a payment is inspected, not trusted.

  • Facilitator Boundary

    Whoever settles the payment stays inside a declared trust boundary.

Architecture

Where 402 Sentry sits

One decision point, on the path between a signed payment authorization and the infrastructure that would settle it.

Payment intent Before the boundary

  1. Buyer / Agent Requests a paid resource
  2. 402 Payment Required Returned by the seller resource
  3. Payment authorization Prepared and signed by the buyer

Enforcement boundary Operator-controlled

402 Sentry Policy decision before execution

Seller-side pre-check, then the @sentry402/core decision — evaluated before the facilitator is contacted at all.

Decides. Does not sign, settle, or hold funds.

Blocked

Stops here. No facilitator contact, no settlement, no transfer.

Evidence

  1. Sanitized event log
  2. Dashboard

Recorded for every decision, whichever way it goes.

Approved

After an approved decision x402 facilitator, then the chain

  1. Facilitator verify /verify
  2. Facilitator settle /settle
  3. Base Sepolia USDC settlement
  4. Paid response Returned to the buyer
402 Sentry runs at the payment boundary the application operator controls — inside the application environment, in a sidecar or container beside it, or on a private gateway in the path. The funded demonstration happened to host the seller resource locally; that is where that run was, not where the boundary has to sit. The rails shown are Base Sepolia and x402, which is what runs today. 402 Sentry decides; it does not sign the buyer’s authorization, act as the facilitator, or hold funds at any point.
Base x402

The rails it runs on

One network and one protocol, named exactly. Everything below is where 402 Sentry runs today — not a roadmap.

Network
Base
Environment
Base Sepolia (testnet)
Network identity
eip155:84532 CAIP-2
Protocol
x402 v2
Settlement asset
USDC on Base Sepolia
Protocol artifact Captured

An authentic capture from a funded Base Sepolia run: the decoded 402 Payment Required challenge — exact scheme, 1000 atomic units (0.001 USDC), for /testnet/paid/hello.

The seller was hosted locally. The signing, the network, the asset and the settlement were not.

View the settled transaction on BaseScan
Arvin, founder of 402 Sentry
Arvin Bahrami Ethical Hacker

Founder

Why I built 402 Sentry

My background is in offensive security, where I’ve spent the past six years identifying vulnerabilities before they turn into incidents. As autonomous agents begin making real financial decisions, that same adversarial mindset helps me spot gaps in the agentic payment-flow infrastructure before they become larger problems. I built 402 Sentry to provide a control layer that can assess payment behavior and policy before value moves — bringing practical cybersecurity thinking to the infrastructure autonomous agents will rely on.

Explore 402 Sentry.

See the product in action or watch the founder pitch.

See the Demo Watch the Pitch

Get in touch