# Trust does not scale at machine speed

> Source: <https://yebo.dev>
> Published: 2026-05-27 06:03:53+00:00

# The checkpoint beforeAI actions execute.

Enforce verified intent at machine speed.

Every sensitive AI action is evaluated against policy before execution. Deterministic, runtime-enforced, and fail-closed by design.

- Policy eval
- <50ms
- Posture
- Fail-closed
- Audit
- Immutable

```
await yebo.verify({
  action: "transfer.funds",
  amount: 4_200_00,
  currency: "USD",
  destination: "acct_8a4f...",
  agent: "ops-runner-3"
})
```

The problem

## Authorization built for humanscannot govern autonomous agents.

AI agents now execute payments, sign contracts, and modify production infrastructure. The systems that decide whether those actions are allowed were not designed for callers that act ten thousand times an hour.

### Agents move at machine speed

An autonomous agent can chain a hundred actions before a human sees the first one. Approval queues that worked for humans collapse the moment they meet inference loops.

### Existing auth assumes humans

OAuth scopes, session tokens, role grants. All of it was designed around a person clicking a button. Hand the same credentials to an agent and the model becomes the security perimeter.

### Actions chain autonomously

One ambiguous instruction becomes ten downstream calls across systems you don’t own. Without a checkpoint at each call, intent drift becomes financial loss, data exposure, or silent state changes.

### Enterprises need runtime verification

Build-time guardrails and prompt filters can’t prove what the agent actually executed. Compliance, finance, and security teams need a deterministic gate at the moment of execution, 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.

### 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"
}
```

### 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
```

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

Use cases

## Wherever an agent can take an action,a checkpoint belongs.

Yebo sits in front of any sensitive operation (financial, contractual, or infrastructural) and enforces what is allowed before the runtime 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

``` js
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 "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

```
{
  "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.

### Immutable audit history

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

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

### Execution traceability

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

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

Infrastructure for the agent economy

## Make every agent actionpass through a checkpoint.

Deploy Yebo in front of one workflow today. By the end of the quarter, every sensitive AI action in your stack ships with a signed, replayable proof of authorization.
