Cryptographic Mandate Controls

The evidence layer formachine-originated payments.

AI can propose. It cannot execute.

Yebo makes it impossible for money to leave your company without cryptographic proof that an authorized human approved that specific payment. Proof your auditors can verify years later.

Policy eval
<50ms
Posture
Fail-closed
Audit
Immutable
agent.execute()verified
await yebo.verify({
  action: "transfer.funds",
  amount: 4_200_00,
  currency: "USD",
  destination: "acct_8a4f...",
  agent: "ops-runner-3"
})
DecisionALLOW
policy
payments.below_threshold
receipt
rcpt_a1b2c3d4

The problem

Disbursement controls built for humanscannot 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.

A three-stage pipeline sits between every agent and every sensitive action. Each stage is deterministic, recorded, and impossible to bypass.

STEP 01

Intent

The agent declares what it wants to do, in structured form. Action type, parameters, target, caller identity. Every call is a signed proposal, not a side effect.

{
  action: "transfer.funds",
  amount: 4_200_00,
  destination: "acct_8a4f"
}
STEP 02

Policy verification

Yebo evaluates the intent against your policy bundle in milliseconds. Deterministic rules, scoped permissions, threshold checks, and dependency graphs, all enforced before the runtime sees a single side effect.

policy: payments.transfer
match: amount < 5_000_00
       && destination ∈ vendors
=> ALLOW
STEP 03

Authorized execution

Only verified actions reach your runtime. Each one carries a signed receipt that proves what was approved, by which policy, against which agent identity. Replayable, auditable, and tamper-evident.

decision: ALLOW
receipt:  rcpt_a1b2c3d4
policy:   payments.below_threshold
verified: 2026-05-15T17:24:08Z

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, on every action, with no exceptions and no overrides.

  • 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

    Policies execute inline at the call site, not at deploy time. Updates propagate instantly across every agent, every fleet, every region.

  • 03

    Immutable audit trails

    Each verification produces a signed receipt. Replay any decision months later with the exact policy, parameters, and identity that produced it.

  • 04

    Scoped permissions

    Agents receive narrow, time-bound capabilities, never a blanket key. Scope is enforced at the gate, not assumed by the caller.

  • 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.

Live proof flow

Every action moves through the gate.One stage at a time.

A payment executes only after every stage of the mandate pipeline passes. Watch a single request traverse the runtime.

Execution Integrity Monitor
Concept demo
  1. Active

    01

    Request enters

    Agent action received with scoped execution context.

  2. Pending

    02

    Policy engine validates

    Runtime policy checks permissions, limits, and risk rules.

  3. Pending

    03

    Human intent verified

    Approval boundary confirms the action matches authorized intent.

  4. Pending

    04

    Execution fingerprint generated

    Idempotency key and execution hash are created before commit.

  5. Pending

    05

    Side effect committed

    Approved action executes once, with audit proof stored.

Verified execution complete
01 / 05

Deterministic, policy-bound, and fail-closed. AI can propose. It cannot execute.

Use cases

Wherever software can move money,a mandate control belongs.

Yebo sits in front of disbursements over threshold (vendor payments, fund transfers, payouts) and requires proof of human approval before the payment rail ever sees the call.

Payments

Bound transfers, refunds, and payouts to verified policy. Threshold-gated, vendor-scoped, replay-resistant.

amount < 5,000 USD ∧ vendor ∈ approved

Procurement

Verify purchase orders, vendor changes, and budget allocations before they land in your ERP.

po.total ≤ budget.remaining

Contracts

Gate signatures, amendments, and counterparty changes against legal-approved templates and authority matrices.

signer.role ∈ contract.signers

Infrastructure actions

Approve or block production changes (IAM grants, secret rotations, schema migrations) at the moment they execute.

env = prod ⇒ requires.approval

Protected APIs

Wrap any internal or third-party API in a policy gate. Per-call verification with no SDK surgery on the caller.

rate.window(60s) ∧ scope = read

Enterprise workflows

Multi-step automations stay inside policy as they fan out across systems. Drift, escalation, and side effects are rejected at the boundary.

step.k.requires(step.k-1.receipt)

Developer experience

An SDK call, a policy file,and a signed receipt.

Drop Yebo in front of any sensitive call. Policies are versioned text. Verification returns a deterministic decision and a tamper-evident receipt. Nothing else changes about your runtime.

01 · API

Verify before execute

typescript
import { Yebo } from "@yebo/sdk";

const yebo = new Yebo({ apiKey: process.env.YEBO_KEY });

const decision = await yebo.verify({
  agent:  "ops-runner-3",
  action: "transfer.funds",
  params: {
    amount:      4_200_00,
    currency:    "USD",
    destination: "acct_8a4f9c"
  }
});

if (decision.allow) {
  await stripe.transfers.create(decision.params);
}

02 · Policy

Schema as code

policy
policy "payments.transfer" {
  match action == "transfer.funds"

  allow {
    amount      < 5_000_00
    currency    in ["USD", "EUR"]
    destination in vendors.approved
    agent.scope contains "payments:write"
  }

  require {
    receipt
    audit.signed
  }
}

03 · Receipt

Verification artifact

json
{
  "decision": "ALLOW",
  "policy":   "payments.transfer",
  "agent":    "ops-runner-3",
  "params":   { "amount": 420000, "currency": "USD" },
  "receipt":  "rcpt_a1b2c3d4e5f6",
  "verified": "2026-05-15T17:24:08.412Z",
  "signature": "ed25519:b9e3...4f2a"
}

Security & auditability

Cryptographic proof of every decision.For your auditors, your regulators, and you.

Compliance is not a layer on top. It is a property of the gate itself. Every action that touches Yebo leaves behind a verifiable artifact.

01

Immutable audit history

Every verification, allowed or denied, is appended to a tamper-evident log. Reconstruct any decision, byte for byte, years later.

log.append(receipt) → root: 0x9c4e…b1f0
02

Verification before execution

Policy evaluates the full action graph before a single side effect runs. Denials block in microseconds; allowances carry a signed proof forward.

verify(intent) → ALLOW · 38ms
03

Execution traceability

Every receipt links agent identity, policy version, parameters, and downstream call. Investigations end with a single ID, not a forensics project.

rcpt_a1b2c3 → agent · policy · txn
04

Policy enforcement layer

Policies are versioned, signed, and applied at runtime. There is one source of truth, one place to change, one place to audit.

policy@v42 · signed · enforced
Hardware-bound keys
Fail-closed posture
Vendor-independent proof
Auditor re-verifiable

Infrastructure for autonomous finance

Make every payment carryproof of human approval.

Deploy Yebo in front of one disbursement workflow today. By the end of the quarter, every payment over threshold ships with a signed, independently verifiable proof of approval.

Start BuildingView Architecture

No credit card · Pilot in <10 minutes