YeboYebo
Request a pilot

Developer Platform

Build on Cryptographic Mandates.

Control execution before it happens. Every action is evaluated, authorized, and verified before it runs.

Read Docs →Request Sandbox Access
authorize.ts
const result = await yebo.authorize({ ... })

Install the SDK: npm i @yebo-auth/sdk Full SDK reference available under sandbox access.

Request Sandbox Access →

SDKs

The TypeScript SDK (@yebo-auth/sdk 1.1.0) is on npm. Python, Swift, Rust and Go are coming soon.

TS
TypeScript
v1.1.0 on npm
PY
Python
Coming soon
SW
Swift
Coming soon
RS
Rust
Coming soon
GO
Go
Coming soon

The Authorization Pipeline

An intent request runs these stages in order: policy first, then the mandate, approval if required, execution (dry run) and the receipt. Sentinel invariants run on the separate /execute path. Payment missions are checked by the gateway's mission gate: scope, amount, payee, expiry and a passkey approval.

  1. INTENT
    Agent or user submits an action via API: what they want to do, with what constraints.
    →
  2. POLICY
    The policy engine returns ALLOW, DENY or REQUIRE_APPROVAL against your rules, limits, and allowlists, and fails closed. A denied action stops here and is logged.
    →
  3. MANDATE
    An allowed or held action is formalized into an immutable mandate: sealed, time-limited, and single-use.
    →
  4. APPROVAL
    If required, a human approves. For payment missions, the passkey approves the mission's limits. Per-payment device signing is live and has been exercised in production: the approver's passkey signs the exact payment (amount, payee, agent, validity window), and anyone can check it offline with yebo-verify 0.2.0.
    →
  5. EXECUTE
    Runs in dry-run mode today: Yebo issues a signed dry-run receipt and no money moves. Live payment execution is coming soon.
    →
  6. RECEIPT
    A gateway-signed receipt (ECDSA P-256) is generated and stored, checkable against the published public keys with the open-source npm verifier, npx yebo-verify@0.2.0.

What the API does

A small number of capabilities cover every integration: submit actions, preview decisions, approve pending requests, and retrieve verifiable records. Full endpoint reference, payload shapes, and authentication details are available under sandbox access.

Request Sandbox Access →
Submit for authorization

Send an action through the pipeline. Yebo returns a sealed mandate and a decision.

Preview a decision

Check whether an action would be allowed without triggering execution.

Verify before execution

Confirm an authorization is still valid: policy compliance, expiry, replay protection.

Approve pending actions

A human approves pending requests. For payment missions, the passkey approves the mission's limits (capabilities, per-transaction limit, payees). Per-payment device signing is live and has been exercised in production: the approver's passkey signs the exact payment (amount, payee, agent, validity window), and anyone can check it offline with yebo-verify 0.2.0.

Retrieve a mandate

Pull the verifiable authorization record: what was requested, who approved it, what policy applied.

Export an audit bundle

Package a gateway-signed evidence bundle for auditors or compliance teams. Bundles verify offline with npx yebo-verify@0.2.0 bundle.

The Mandate

Every action is converted into a mandate, the core authorization primitive. A mandate defines the action, the scope, and the governing policy. Mandates are immutable once created, time-limited, and single-use. Any change requires a new mandate.

Immutable

Sealed on creation

Time-limited

Short expiry window

Single-use

Cannot be replayed

Decision Model

Yebo returns one of three outcomes for every action:

ALLOW

Action proceeds (payments run as dry run today).

REQUIRE APPROVAL

Action pauses until approved.

DENY

Action is blocked and never executes.

Verification

Before execution, Yebo verifies that the action matches the approved mandate, the authorization is valid, the request has not expired, and the request has not been replayed. If any check fails, execution is blocked and a clear reason is returned.

New

Yebo MCP Server

Add the Yebo MCP server to Claude Desktop, Cursor, or any MCP-compatible AI tool with one config block (partner preview: its authorization tools are being updated to the current gateway API).

Partner Access

The MCP server installs with a single config block in Claude Desktop or Cursor and exposes a focused set of authorization tools: preflight a decision, request approval, verify, and pull a mandate. Config snippets, package name, tool surface, and API-key format are available to approved partners under sandbox access.

Request Sandbox Access →
New

Identity setup

One interactive command creates your Yebo identity and generates your config, with a software key on your machine.

Partner Access

The CLI walks you through naming your identity and picking a handle. Binding a device key through the Yebo iOS app is coming soon. The exact command, generated identifiers, config paths, and gateway endpoints are available to approved partners under sandbox access.

Request Sandbox Access →

Yebo does not replace your systems.

It controls what they are allowed to execute.

For actions routed through the gateway: if an action cannot be verified, it does not run.

Request Sandbox Access