Ambit

Scoped, verifiable spending policies for AI agents on Stellar.

Ambit turns a single recorded transaction flow into a minimal, on-chain enforced policy — so an autonomous agent can pay for the same class of action over and over, safely, without ever holding a key that can do anything else.

Record the flow once. Generate a policy that allows exactly that, and nothing else. Deploy it to a Soroban smart account. Let the agent run.

---

The problem

AI agents are starting to pay for things on their own — API calls, data, compute, tool invocations — using protocols like x402 on Stellar. x402 already answers how a payment happens: Stellar has live facilitators (Coinbase-hosted and an OpenZeppelin Relayer-based facilitator), starter templates, and working demos.

What none of that infrastructure answers is what an agent should be allowed to do in the first place. Today, giving an agent a wallet means giving it a key. A key that can pay $0.001 for a weather API call can, in principle, also drain the account. Spending limits bolted on after the fact are either too loose (agent can still misuse the account) or too rigid (a static allowlist that breaks the moment the agent's task changes slightly).

What Ambit does

Ambit is a policy compiler and enforcement layer, not another payment rail. It sits above the existing x402-on-Stellar stack:

1. Record — capture a transaction an agent has already performed, or a simulated one (which contract, which function, which asset, how much, in what order), using Soroban's simulation output.
2. Compile — derive the smallest policy that permits exactly that sequence: a specific contract, a specific method, a capped amount, an optional expiry or call-count limit. Nothing broader.
3. Deploy — attach the compiled policy to a Soroban smart account (C-address) as a signer/context rule. The account can now execute that exact flow autonomously — and only that flow.
4. Run — the agent calls through its existing x402 client as normal. If a request falls outside the policy's ambit, the smart account rejects it at the protocol level, not by convention.

This is deliberately narrow in scope. Ambit does not build a facilitator, a payment channel, or a settlement layer — those already exist and are maintained by SDF, Coinbase, and OpenZeppelin. Ambit makes the agents that use them safe to run unattended.

Why Stellar

• Soroban smart accounts (C-addresses) support custom authorization logic natively — policies are first-class, not an app-layer workaround.
• Sub-cent fees and ~5s finality make it viable to deploy and update scoped policies as often as an agent's task set changes.
• Native USDC means the policy layer and the payment layer speak the same asset without bridging.
• AI/agent-readiness and smart account adoption are exactly where the Stellar ecosystem is heading — and this gap sits right in the middle of it.

Architecture

┌──────────────┐    ┌──────────────┐    ┌───────────────────┐    ┌────────────┐
│ Trace         │ →  │ Policy        │ →  │ Policy Registry    │ ←  │ Agent      │
│ Recorder (TS) │    │ Compiler (TS) │    │ (Soroban contract) │    │ Runtime SDK│
└──────────────┘    └──────────────┘    └───────────────────┘    └────────────┘
                                                    ↑
                                          existing x402 facilitator
                                          (Coinbase / OpenZeppelin)

• Trace Recorder — wraps soroban contract simulate / RPC to capture the effects of a transaction: contract IDs, invoked functions, assets moved, amounts, ordering.
• Policy Compiler — turns a trace (or a small set of traces) into a minimal policy spec: allowed contract + method, max amount per call, max total, expiry, call-count cap.
• Policy Registry — a Soroban contract that stores versioned policies per smart account, enforces them at authorization time, supports revocation and renewal.
• Agent Runtime SDK — thin TypeScript wrapper an agent (or MCP tool) calls instead of a raw key — it signs within the deployed policy's ambit and surfaces a clear rejection if the agent tries to step outside it.
• Review Dashboard (Phase 2) — lets a human glance at a proposed policy before it's deployed, in plain language ("this lets the agent pay up to $0.05 per call to weather-api.example, max 500 calls, expires in 30 days").

Tech stack

Layer	Choice
Smart contracts	Rust + Soroban SDK
SDK / Recorder / Compiler	TypeScript, Node.js
Stellar interaction	@stellar/stellar-sdk, stellar-wallets-kit
x402 integration	@x402/stellar, @x402/core (consumed, not reimplemented)
Local dev	stellar-cli, soroban-cli
Dashboard (Phase 2)	Next.js, TailwindCSS

Repository structure

ambit/
├── contracts/
│   └── policy-registry/      # Soroban contract: stores & enforces policies
├── packages/
│   ├── recorder/             # Trace capture
│   ├── compiler/             # Trace → policy spec
│   └── agent-sdk/            # Runtime SDK for agents
├── dashboard/                 # Phase 2 — human review UI
├── examples/
│   └── weather-agent/        # Minimal end-to-end demo
├── docs/
├── ROADMAP.md
├── CONTRIBUTING.md
└── README.md

Getting started

# prerequisites
rustup target add wasm32-unknown-unknown
cargo install --locked soroban-cli
node --version   # >= 20

# clone
git clone https://github.com/benelabs/ambit.git
cd ambit

# build the policy-registry contract
cd contracts/policy-registry
soroban contract build

# deploy to testnet
soroban contract deploy --network testnet --source <your-identity>

# install the SDK packages
cd ../../packages/agent-sdk
npm install

Full walkthrough (recording a first trace and compiling a policy) lives in examples/weather-agent/README.md once Phase 1 ships — see ROADMAP.md.

Contributing

See CONTRIBUTING.md.

License

Apache-2.0

Maintainer

benelabs