---
title: "Introduction"
description: "Obol is a control plane for agent traffic: one identity, one policy engine, one audit log, and one bill across LLM providers, MCP servers, and REST APIs."
---

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](/get-started/self-hosting).

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

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

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

<Note>
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.
</Note>

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

<Warning>
"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](/receipts/evidence).
</Warning>

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

<CodeGroup>

```bash OpenAI-compatible
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"}]}'
```

```json MCP client config
{
  "mcpServers": {
    "obol": {
      "url": "https://gateway.tryobol.dev/mcp",
      "headers": { "Authorization": "Bearer ob_live_your_key" }
    }
  }
}
```

```bash Capability resolution
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}'
```

</CodeGroup>

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

<Columns cols={2}>
  <Card title="Quickstart" icon="rocket" href="/get-started/quickstart">
    Mint a key, connect a provider, make a governed call.
  </Card>
  <Card title="Architecture" icon="layers" href="/concepts/architecture">
    Two planes, the deployables that ship, and how state reaches the hot path.
  </Card>
  <Card title="Invariants" icon="shield" href="/concepts/invariants">
    The nine rules no change may violate, and the ADRs behind them.
  </Card>
  <Card title="Glossary" icon="book-open" href="/concepts/glossary">
    The vocabulary used exactly this way in code, docs, and UI.
  </Card>
</Columns>

## Explore by subject

<Columns cols={3}>
  <Card title="Gateway" icon="server" href="/gateway/overview">
    The Rust data plane: LLM routes, MCP sessions, and crate layout.
  </Card>
  <Card title="Policy" icon="scale" href="/policy/overview">
    CEL for visibility, Cedar for permission, approvals for destructive tools.
  </Card>
  <Card title="Security" icon="key" href="/security/virtual-keys">
    Virtual keys, the vault, OAuth, credential brokering, egress control.
  </Card>
  <Card title="Connectors" icon="plug" href="/connectors/overview">
    Native, trusted worker, and federated tiers, and how to add one.
  </Card>
  <Card title="Receipts" icon="receipt" href="/receipts/overview">
    Evidence classes, idempotency, webhooks, and verification.
  </Card>
  <Card title="Routing" icon="route" href="/routing/overview">
    Capabilities over interchangeable providers, chosen deterministically.
  </Card>
  <Card title="Billing" icon="gauge" href="/billing/metering">
    Usage events, Stripe meters, and budgets that span tokens and tool calls.
  </Card>
  <Card title="Observability" icon="activity" href="/observability/audit-log">
    The audit log and gateway telemetry.
  </Card>
  <Card title="Enterprise self-host" icon="container" href="/get-started/self-hosting">
    Running the stack in your own environment, on the Enterprise plan.
  </Card>
</Columns>