AI can propose. It cannot execute.
Stop unauthorized AI payments before they happen.
- Keep AI moving at machine speed.
- Authorize with human intent.
- Prove every action it lets through.
AI operates at machine speed. Yebo checks every AI payment you route through its gateway against your policy before it runs and returns ALLOW, DENY or REQUIRE_APPROVAL. If it cannot decide, it fails closed.
Every action that clears the gate gets a gateway-signed receipt, checkable offline against Yebo's published public key with the open-source npm verifier, npx yebo-verify@0.2.0. Execution runs in dry-run mode today, so no money moves.
Policy Eval
<50ms
Policy evaluation time is server-measured and returned on preflight and sandbox decision responses (X-Yebo-Eval-Ms).
Posture
Fail-closed
If approval or verification cannot be confirmed, the transaction will not execute.
Audit
Signed
Receipts are signed by the gateway (ECDSA P-256, SHA-256) against a published public key and are tamper-evident; offline receipt checks use the open-source npm verifier, npx yebo-verify@0.2.0.
Built for Finance, SecOps, Risk, and Audit teams who need policy control and independently verifiable evidence for AI-initiated payments.
Who This Is For
01
AI Already Prepares Payments
Your AP platform or AI agents prepare or initiate vendor payments as part of normal operations.
02
Unauthorized Payments Aren’t an Option
A single unauthorized payment could create financial loss, regulatory exposure, or reputational damage.
03
You Need Independent Proof
Your CFO, CISO, or auditor expects verifiable evidence that every payment was checked against policy, and against any limits a human approved, before it ran.
If all three are true, you can pilot Yebo in 14 days using a single payment workflow.
The problem
Disbursement controls built for humans cannot evidence machine-originated payments.
Software now proposes and initiates payments. The controls that evidence approval of those payments were designed for human-speed workflows, and the evidence they produce lives in systems you do not control.
- 01
Payments are becoming machine-originated
AP automation already proposes vendor payments; increasingly it initiates them. Finance is moving toward machine-originated execution, and the shift is happening while your control narratives are being written.
- 02
Controls were calibrated for human-speed workflows
Approval workflows, role grants, and review queues assume a person at every step. They are not broken; they are miscalibrated. They evidence that a workflow ran, not that a human approved a specific payment.
- 03
Approval evidence dies with the vendor
Today the approval lives in an AP platform's logs, an email, or a Slack thread. Three years later, when your auditor tests that control, the vendor relationship may be gone and the logs with it. A rail cannot certify itself.
- 04
Executives certify it anyway
Under Sections 302 and 906, your officers personally certify controls over every disbursement, including any that software initiates. They need a durable artifact behind that signature, not a log to read after.
How Yebo works
Intent, verified before execution.
Three stages sit between an agent and every sensitive action you route through the Yebo gateway. Each stage is deterministic and recorded, and the gateway fails closed.
STEP 01
Intent
The agent declares what it wants to do, in structured form. Action type, parameters, target, caller identity. Every call is a proposal, not a side effect.
{ intent: "pay acct_8a4f $4,200.00", amount: 4200, asset: "USD", merchant: "acct_8a4f" }STEP 02
Policy verification
Yebo evaluates the intent against your policy in milliseconds and returns ALLOW, DENY or REQUIRE_APPROVAL. Deterministic rules, capability and payee allowlists and threshold checks, all evaluated before anything runs.
allowed_capabilities: ["payment"] allowed_counterparties: ["acct_8a4f"] transaction_limits: { payment: 5000 } => ALLOW
STEP 03
Signed receipt
Only allowed actions go on to execution, which runs in dry-run mode today: no money moves. Each executed action gets a receipt signed by the gateway (ECDSA P-256) that records the mandate, the policy hash and the agent identity. Tamper-evident; offline receipt verification uses the open-source npm verifier, npx yebo-verify@0.2.0.
decision: ALLOW mandate_id: 3f9c1d2e-... receipt: car-7b41e0a2-... signature: ECDSA P-256
Runtime enforcement
Policy is not a guideline.
It is a gate.
Yebo is the enforcement layer between agent intent and runtime execution. Every property below is checked at call time, for every action you route through the gateway.
NO MANDATE, NO MOVEMENT
- 01
Deterministic verification
Every decision is the output of a pure policy function. Same input, same outcome, every time. No model, no stochasticity, no drift.
- 02
Runtime policy checks
The gateway evaluates policy on every call, not at deploy time. A policy change applies to the next call your agents make.
- 03
Tamper-evident audit trail
Every execution decision on the gateway, allowed or denied, is recorded in the audit log (/preflight checks are advisory and not logged), and each executed action gets a gateway-signed receipt that records the policy hash, the parameters and the agent identity.
- 04
Scoped missions
A mission grants an agent narrow capabilities, a per-transaction limit and a payee list, and the gateway checks every payment against them. Scoped, revocable API keys are coming soon.
- 05
Fail-closed by default
If policy is unreachable, ambiguous, or mid-update, the action does not execute. Silence is denial. There are no implicit allow paths.
Proof flow (concept demo)
Every action moves through the gate.
One stage at a time.
A payment is cleared only after every stage of the mandate pipeline passes. Execution runs in dry-run mode today, so no money moves. Watch a single request traverse the runtime.
Deterministic, policy-bound, and fail-closed. AI can propose. It cannot execute.
- Active
Request enters
Agent action received with scoped execution context.
- Pending
Policy engine validates
Runtime policy checks permissions, limits, and risk rules.
- Pending
Approved limits checked
In a mission, the action is checked against the limits a human approved with a passkey.
- Pending
Execution fingerprint generated
Idempotency key and execution hash are created before commit.
- Pending
Dry-run receipt signed
Approved action runs once in dry-run mode (no money moves) and a signed receipt is stored.
Verified, dry-run receipt signed
Use cases
One wedge:
AI-initiated vendor disbursements.
Yebo sits in front of vendor disbursements and requires an ALLOW decision, or human approval above your threshold, before the call goes any further.
Vendor disbursements
Gate vendor payments on verified policy. Threshold-gated and vendor-scoped. This is the workflow the 14-day pilot validates, in dry-run mode today. Stripe Connect vendor payouts are coming soon.
amount ≥ 10,000 USD ⇒ requires.mandate
AP automation
Your AP platform or AI agents keep proposing payments exactly as they do today. Yebo sits in front of the disbursement and returns ALLOW, DENY or REQUIRE_APPROVAL before anything runs.
agent.propose ∧ policy.allow ⇒ receipt
Approval evidence
Every action the gateway lets through produces a gateway-signed receipt, sampled and tested like any approval control. Offline re-verification with the published key uses the open-source npm verifier, npx yebo-verify@0.2.0.
verify(artifact, public_key) = PASS
Developer experience
An SDK call, a policy file,
and a signed receipt.
Put Yebo in front of any sensitive call. Policies are versioned JSON. The gateway returns a deterministic decision (ALLOW, DENY or REQUIRE_APPROVAL) and, for actions it lets through, a signed receipt. Execution runs in dry-run mode today, so no money moves. Install the SDK with npm i @yebo-auth/sdk.
SDK: authorize a payment
typescript// npm i @yebo-auth/sdk import { Yebo, GatewayError } from "@yebo-auth/sdk"; const yebo = new Yebo({ gateway: "https://gateway.yebo.dev" }); // The agent never holds rail credentials. // The gateway decides; no mandate, no movement. // session_token comes from the user's passkey sign-in. try { const result = await yebo.authorize({ intent: "pay invoice INV-2041 to acct_8a4f9c", amount: 2500, asset: "USD", merchant: "acct_8a4f9c", session_token, }); // result.authorization_status: // "AUTHORIZED_PENDING_EXECUTION" when policy allows the payment // "APPROVAL_REQUIRED" above your approval threshold: the approver // signs this exact payment on their own device before it runs // result.mandate_id: the mandate for this payment } catch (err) { // A policy denial throws GatewayError (status 403, code "POLICY_DENIED") if (!(err instanceof GatewayError)) throw err; }
Install with npm i @yebo-auth/sdk. Execution runs in dry-run mode today, so no money moves.
Policy as JSON
json{
"policy_id": "payments-transfer",
"version": 3,
"allowed_capabilities": ["payment"],
"allowed_counterparties": ["acct_8a4f9c"],
"transaction_limits": { "payment": 5000 }
}Signed receipt (dry run, illustrative)
json{
"decision": "ALLOW",
"mode": "dry_run",
"agent": "ops-runner-3",
"params": { "amount": 4200, "currency": "USD" },
"mandate_id": "3f9c1d2e-...",
"receipt_id": "car-7b41e0a2-...",
"policy_hash": "sha256:9c4e...b1f0",
"issued_at": "2026-05-15T17:24:08.412Z",
"signature": "ecdsa-p256:b9e3...4f2a"
}Security & auditability
Signed evidence, checkable against a published key.
For your auditors, your regulators, and you.
Compliance is not a layer on top. It is a property of the gate itself. Every execution decision is logged, and every action the gateway lets through leaves behind a gateway-signed receipt.
Tamper-evident audit history
Every execution decision on the gateway, allowed or denied, is appended to a hash-chained, tamper-evident log. Each record links to the one before it.
prev_hash: 9c4e…b1f0 → hash: 2a71…d03e
Verification before execution
Policy is evaluated before a single side effect runs, and the evaluation time is returned in a response header.
POST /preflight → X-Yebo-Eval-Ms
Execution traceability
Every receipt links the mandate, the policy hash, the agent identity and the approval. Investigations start from a single ID.
car-7b41… → mandate · policy_hash · agent
Policy enforcement layer
Policies are versioned and hashed, and the hash is applied at runtime and recorded with each decision.
policy_hash: sha256(policy)
- Passkey-approved mission limits
- Fail-closed posture
- Gateway-signed receipts
- Hash-chained audit log
Independent verification
Don't take our word for it
Download a device-signed sample and re-verify it yourself, offline, with the open-source npm verifier (npx yebo-verify@0.2.0), no account and no access to our systems. Then tamper with it and watch verification fail.
{
"decision": "ALLOW",
"policy": "payments.transfer",
"params": { "amount": 420000 },
"mandate": "yac_a1b2c3d4e5f6",
"signature": "ecdsa-p256:b9e3...4f2a"
}Infrastructure for autonomous finance
Make every AI payment carry signed evidence.
Put Yebo in front of one disbursement workflow, in dry-run mode today. Every action it lets through comes with a gateway-signed receipt you can check offline against our published key with npx yebo-verify@0.2.0, and payments over your threshold wait for a human.
Sandbox access same-day · Pilot proposal within 48 hours