What is Yebo?
Yebo sits between your AI agent and real-world actions. Before any action executes, Yebo checks your policy and decides: allow it, pause it for human authorization, or block it entirely.
No action executes without passing through Yebo first.
The simplest explanation
Your AI agent wants to pay a vendor. Without Yebo:
Agent → Stripe → Money sent
With Yebo:
Agent → Yebo checks policy → ALLOW → Stripe → Money sent
Agent → Yebo checks policy → REQUIRE_APPROVAL → Paused → Human approves → Stripe → Money sent
Agent → Yebo checks policy → DENY → Blocked → Stripe never called
A concrete example
You set a policy with these thresholds:
{
"auto_approve_below": 500,
"deny_above": 10000,
"currency": "USD"
}
Here's what happens:
| Your agent tries to pay | Yebo decides | What actually happens | |------------------------|--------------|----------------------| | $200 to Acme Corp | ALLOW | Stripe executes immediately | | $5,000 to Big Vendor | REQUIRE_APPROVAL | Paused — you receive an approval request on your phone | | $50,000 to Unknown LLC | DENY | Blocked — Stripe is never called |
Every decision comes with a reason:
ALLOW — Amount $200 is below auto_approve threshold of $500
REQUIRE_APPROVAL — Amount $5,000 requires human authorization ($500–$10,000)
DENY — Amount $50,000 exceeds Policy deny_above threshold of $10,000
Why this matters now
AI agents act autonomously. They read emails, check calendars, write code, and — increasingly — move money, access data, and send communications on your behalf.
The problem is not whether your agent is smart. The problem is: who authorized that action?
Without a control layer, you have no way to:
- stop a payment before it executes
- require human sign-off on high-value actions
- prove that a human authorized something after the fact
- block an agent from doing something it was never supposed to do
Yebo is that control layer.
What Yebo controls
Yebo started with payments. It now controls any consequential action an agent might take:
| Action | What Yebo guards | |--------|-----------------| | Payments | Amount, vendor, currency | | Email sends | Recipient count, subject, bulk sends | | File writes | Path, size, cloud storage | | Database mutations | Table, rows affected, operation type | | Deployments | Service, environment (production always requires approval) | | Contract signing | Signers, document value | | API calls | URL, method, outbound mutations | | Data access | PII fields, record count, purpose |
How it works in code
One function call. Before any action runs:
import { protectPayment } from "yebo-protect";
const result = await protectPayment({
type: "payment",
amount: 200,
vendor: "Acme Corp",
currency: "USD",
});
if (result.decision === "ALLOW") {
await runPayment(); // only executes here
}
If the decision is DENY or REQUIRE_APPROVAL, the action never reaches Stripe.
What you get back
Every authorization returns a structured result:
{
decision: "ALLOW", // ALLOW | REQUIRE_APPROVAL | DENY
reason: "Amount $200 is below auto_approve threshold", // human-readable explanation
policy_rule: "auto_approve_below", // which rule triggered
mandate_id: "mnd_7c9c0a4d...", // audit trail ID
}
This is your proof. Every action is traceable, every decision is logged.
Try it in 60 seconds
npx create-yebo
cd yebo-demo
npm run demo
You'll see all three decisions — ALLOW, REQUIRE_APPROVAL, DENY — running locally against a real policy file. No account. No API key.
Get Started
npx create-yebo # sandbox demo in 60 seconds