Introduction

Obol sits in front of your agents. Your applications point at one OpenAI-compatible URL, your IDEs and agents point at one MCP URL, and both authenticate with one Obol virtual key. Behind that gateway, your own vendor credentials — OAuth tokens, restricted Stripe keys, BYOK model keys — live in a vault and are injected only on the outbound hop. The result is one identity, one policy engine, one audit log, and one bill across LLM providers, MCP servers, and REST APIs — without your raw vendor credentials reaching an agent. You use Obol as a hosted platform. Sign in at the dashboard, connect a model provider, mint a key, and point your application at the hosted gateway — there is nothing to install and no infrastructure to run. Running the full stack yourself is available on the Enterprise plan; see self-hosting.

Surface	URL
Gateway (agent traffic)	`https://gateway.tryobol.dev`
Control plane API	`https://control.tryobol.dev`
Dashboard	`https://app.tryobol.dev`

These are the production domains. Hosted Control and gateway are still being commissioned; the quickstart requires an enabled workspace.

The name is the coin paid to Charon for passage: a toll at the gateway.

Obol is pre-alpha. The Rust gateway, Python control plane, Next.js dashboard, and contract pack are implemented and under active integration; the Python MCP worker application is not implemented. Pages here mark target architecture where it differs from what runs today.

What Obol guarantees, and what it proves

This distinction runs through every page in these docs, so it is worth stating before anything else. What Obol guarantees before a call is tier-independent. Default-deny authorization, argument-level conditions, approvals, budgets, and revocation apply identically to every provider, because the gateway sits upstream of all of them. What Obol proves after a call is tier-dependent. A native route executed by the gateway can produce gateway_observed evidence. A route executed by a federated catalog broker cannot: its evidence is untrusted or broker_attested, and can never support a verified conclusion. The receipt always names the class.

“Receipts prove what a tool call actually did” is true on a native route and false on a federated one. Never read it unqualified. See Evidence trust.

Who it is for

Teams shipping agents that write to real systems — support automation, ops agents, vertical SaaS agents, and coding agents inside companies that care about audit. They already use MCP and at least two model providers, and they are concerned about tool-call blast radius.

Role	What they get
Founding engineer	One key and one log instead of per-agent MCP configs
Platform / AI infra	A standard path from every internal agent to tools
Security	Default-deny, a vault, one-click revoke, an audit log, no raw keys in IDEs
Finance	Caps that span tokens and tool calls, one invoice
Self-host enterprise	The same binaries in their VPC, their KMS, their keys

What Obol is not

Not a cheaper inference route. Obol routes tools, not tokens, and takes no spread on either.
Not an iPaaS or Zapier clone, and not 1,000 maintained connectors. Long-tail coverage is federated from catalog brokers precisely to avoid that treadmill.
Not a merchant of record. Obol never mints or pools vendor payment keys, and never bills a percentage of your payment volume (ADR-0008).
Not an agent framework.
Not an MCP directory. Catalog size is an input to routing, never the pitch.
Not a guarantee that the model picks the right tool — only that the wrong tool cannot execute.
Not a claim that every tool call is verified. Verification is tier-dependent and the receipt says so.

The one-URL model

Three surfaces, one credential.

curl https://gateway.tryobol.dev/v1/chat/completions \
  -H "Authorization: Bearer ob_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o-mini", "messages": [{"role": "user", "content": "hello"}]}'

{
  "mcpServers": {
    "obol": {
      "url": "https://gateway.tryobol.dev/mcp",
      "headers": { "Authorization": "Bearer ob_live_your_key" }
    }
  }
}

curl https://gateway.tryobol.dev/v1/route \
  -H "Authorization: Bearer ob_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{"task": "scrape a product page", "limit": 5}'

/v1/chat/completions, /v1/responses, /v1/embeddings, /v1/messages — the OpenAI-compatible and Anthropic Messages surfaces.
/mcp — Streamable HTTP MCP, with tools namespaced as <connector>.<tool> (for example stripe.create_refund).
/v1/route — advisory capability resolution. It never dispatches, never unwraps a credential, and never reaches a vendor.

Virtual keys are ob_test_ or ob_live_ followed by 32 random bytes. Obol stores only the SHA-256 hash; the secret is shown once. A key is scoped to a workspace, models, tools, budget, rate limits, environment, and expiry — and it is the only credential an agent ever holds.

Start here

Quickstart

Mint a key, connect a provider, make a governed call.

Architecture

Two planes, the deployables that ship, and how state reaches the hot path.

Invariants

The nine rules no change may violate, and the ADRs behind them.

Glossary

The vocabulary used exactly this way in code, docs, and UI.

Explore by subject

Gateway

The Rust data plane: LLM routes, MCP sessions, and crate layout.

Policy

CEL for visibility, Cedar for permission, approvals for destructive tools.

Security

Virtual keys, the vault, OAuth, credential brokering, egress control.

Connectors

Native, trusted worker, and federated tiers, and how to add one.

Receipts

Evidence classes, idempotency, webhooks, and verification.

Routing

Capabilities over interchangeable providers, chosen deterministically.

Billing

Usage events, Stripe meters, and budgets that span tokens and tool calls.

Observability

The audit log and gateway telemetry.

Enterprise self-host

Running the stack in your own environment, on the Enterprise plan.

Get started

Concepts

Gateway

Policy and authorization

Credentials and security

Connectors

Receipts and verification

Routing and catalog

Billing and observability

Enterprise self-host

Introduction

What Obol guarantees, and what it proves

Who it is for

What Obol is not

The one-URL model

Start here

Quickstart

Architecture

Invariants

Glossary

Explore by subject

Gateway

Policy

Security

Connectors

Receipts

Routing

Billing

Observability

Enterprise self-host

​What Obol guarantees, and what it proves

​Who it is for

​What Obol is not

​The one-URL model

​Start here

Quickstart

Architecture

Invariants

Glossary

​Explore by subject

Gateway

Policy

Security

Connectors

Receipts

Routing

Billing

Observability

Enterprise self-host

What Obol guarantees, and what it proves

Who it is for

What Obol is not

The one-URL model

Start here

Explore by subject