INITIALIZING

  • RENDERERDETECTING
  • CONTROL PLANECONNECTING
  • PAYMENT ENV…
  • AI…

VANTA · Trust layer for agentic commerce

INTELLIGENCE IN MOTION.TRUST IN CONTROL.

VANTA governs AI-driven purchasing before money moves. Agents can discover, assess and recommend; deterministic policy and a human decide whether anything is paid.

How VANTA governs a purchase

Six stages. One gate the AI cannot open.

Agents propose. Policy decides. People authorize. Payment happens last — and only if every earlier stage still holds when the server checks again.

  1. 01 · SCOUT

    Discover

    Searches the connected catalogue for candidate products and offers. Only what a listing actually states is kept; everything else stays unknown.

  2. 02 · RISK

    Assess

    Scores seller, price, delivery and evidence coverage. Missing evidence is labelled unknown — never scored as safe.

  3. 03 · OPTIMIZER

    Optimize

    Ranks only the offers that pass hard gates, comparing price, quantity, delivery and constraints by the weights in your versioned policy.

  4. 04 · POLICY GUARD

    Govern

    A deterministic engine checks the exact purchase against your rules and limits. The most restrictive result wins: BLOCK, REQUIRE APPROVAL, or ALLOW.

  5. 05 · HUMAN

    Authorize

    Where policy requires it, a person approves the exact snapshot — items, amount, currency, policy version — before an order can exist.

  6. 06 · PAYMENT AGENT

    Transact

    PayPal checkout proceeds only after the server re-validates the policy decision and approval. The browser never chooses the amount. Every step is audited.

Scout: a radar sweep picking out candidate offers from a field of listings
Risk: an evidence grid of verified, uncertain and unknown signals; unknown is never treated as safe
Optimizer: offers plotted by price and delivery, with the best eligible offer inside the budget cap highlighted
Illustration: agents converge into the Trust Core; one lane leaves through policy and human gates toward checkout

The agent network

Every agent bounded. None can pay.

Each role has one job and a narrow interface. They can propose; only the server — after policy and, where required, a person — can move money.

  • Scout: radar sweep over a field of candidate offers

    Scout

  • Risk: grid of verified, uncertain and unknown evidence signals

    Risk

  • Optimizer: offers plotted by price and delivery with a budget cap

    Optimizer

  • Policy Guard: a hexagonal gate with rule lines passing or failing

    Policy Guard

  • Human approval: a snapshot card next to a fingerprint pattern

    Human approver

  • Payment Agent: an order lane passing two gates before capture, labelled sandbox only

    Payment Agent

Policy Guard

Rules, not vibes. Most restrictive wins.

Policy is a versioned configuration evaluated by deterministic code. An AI's confidence is never an input. Every check reports PASS, REQUIRE APPROVAL or BLOCK, and the strictest result becomes the decision.

ALLOW
Checks pass; a person still authorizes checkout
APPROVE
An approver signs the exact snapshot
BLOCK
No order can be created
Inspect the active policy

LIMITS

  • Mission budget & per-purchase maximum

    Over the maximum blocks; over the mission budget blocks or asks for approval, as configured.

  • Automatic-purchase ceiling

    Anything above it needs a person, even when every other check passes.

  • Approval threshold

    Amounts above it always route to an approver.

EVIDENCE

  • Known total

    Undisclosed shipping or tax blocks — or, if allowed, becomes a capped authorization hold that an approver signs.

  • Evidence coverage & risk score

    Below your minimum coverage or above your risk ceiling, the purchase is blocked or escalated.

  • Instructions hidden in listings

    Prompt-injection attempts in product text block the offer outright.

SCOPE

  • Seller verification

    Only retailer domains you trust count as verified; others block or escalate.

  • Allowed & blocked categories

    A blocked category, or one outside your allow-list, blocks.

  • Duplicate window

    A repeat purchase inside the window blocks or asks for approval.

01

Bound approvals

An approval is tied to the snapshot hash, the policy version and an expiry. Change any of them and it no longer counts.

02

Re-checked at the gate

Before an order is created the server evaluates the current policy again. A stale approval is invalidated, not honoured.

03

A ledger that remembers

Append-only, hash-chained audit events are written in the same database transaction as every state change.

Audit trail

Every decision, on the record.

These are the latest audit events for your session, read from the same hash-chained log the console uses. Swipe a row — or use its menu — to mark it reviewed, hide it from this list, or open the full record.

Marks and hiding apply only to this view. The audit log itself is append-only, and no gesture here can approve, capture or change a payment.

Payment Agent · PayPal

Money moves last. Through PayPal.

VANTA uses PayPal Orders for checkout, capture and authorization holds. Without credentials it runs a clearly labelled simulation; with Sandbox credentials it uses PayPal's test environment. Live payments are refused by default.

This deployment:Connecting
  1. 01

    Order created server-side

    Amount and items come from the approved snapshot, never from the browser.

  2. 02

    Buyer approves in PayPal

    The PayPal checkout window is the second, independent approval.

  3. 03

    Verified, then captured

    The server confirms the PayPal order matches amount, currency and IDs before capture or hold.

Nothing on this page is a real payment. Transactions appear only after you run a mission, approve it and complete checkout.

AI agents can act.

VANTA makes sure they act within policy.