An agent contract is a runtime rule that is checked at every agent action, backed by formal methods.
v0.2.0a21 alpha is out.
pip install --pre sponsio. Sponsio can now sit outside the agent's reach:sudo sponsio install --system(Tier 2) runs the daemon as its own user behind root-owned hooks, andsponsio run --sandbox(Tier 3) starts the agent in a sandbox whose only route out is an egress proxy Sponsio decides, with MCP servers behind Sponsio's gateway. A fleet of daemons can pair with Sponsio Cloud: signed rulebooks, rule changes decided by a person in the console, and an audit chain the cloud checks.sponsio doctor --tiersays which tier your machine is at (threat model); see the release notes. TypeScript@sponsio/sdkis unchanged at0.2.0-alpha.10.
On ODCV-Bench (12 frontier LLMs × 80 trajectories), unguarded models cheat in 11.5%–66.7% of runs. With Sponsio, 95.6% of misalignment is avoided on average; 24/36 high-risk scenarios at 100%. On the Financial-Audit-Fraud-Finding scenario, frontier models commit fraud in 16/24 trials; Sponsio blocks 18/19. On RedCode-Exec (1,410 cases), Sponsio reaches 98.9% combined (bash 98.3% · python 99.4%, lifted from 92.4% by a 4-iteration self-improvement loop), with 0 false positives on a 60-file clean-code audit. These are the open-core numbers; with the Cloud version's self-evolving loop, which mines new contracts from execution traces, ODCV-Bench reaches ~99% and RedCode-Exec 99.4%. Enforcement stays deterministic. Book a demo for the Cloud and Enterprise versions.
One contract takes p50 0.0052 ms to check. The heaviest ODCV workload, 19 contracts on every call, takes 0.139 ms. An LLM-as-judge guardrail takes 50 to 800 ms, so this is 5,000× to 60,000× faster, and it calls no model. p99 stays near 1 ms on every workload measured. These are in-process checks; a host hook (Claude Code, Cursor) also starts a short-lived process per tool call, about 33 to 38 ms p50 (host hook path).
See the full benchmark methodology and per-model breakdown, how Sponsio compares against prompt filters, output validators, LLM-as-judge, and sandboxing, or dive into the architecture and formal methods primer.
Two ways in: paste a prompt into your coding agent, or run the CLI yourself.
Paste into Claude Code / Codex / Cursor. The agent walks the full onboarding flow:
Or run the CLI yourself:
pip install --pre sponsio # or: npm install -D @sponsio/sdk@alpha
sponsio init . # asks what you use, then writes sponsio.yamlThe wizard auto-detects your framework and prints the right wrap snippet. For manual wiring, see all supported integrations. OpenClaw users get bundled ClawHavoc and CVE-2026-25253 coverage out of the box. For config reference, observe → enforce flip, and CI wiring, see the full walkthrough.
Watching runs, and sharing a rulebook. Enforcement is local and needs no account. If you want to see what your agent did, or keep the rulebook somewhere a person reviews it before it arms, app.sponsio.dev is the hosted side. One line puts a run on screen:
import sponsio
import sponsio.bridge
guard = sponsio.Sponsio(config="sponsio.yaml", agent_id="mailer", mode="enforce")
run = sponsio.bridge.attach(guard)sponsio push sponsio.yaml uploads a rulebook as a draft. It does not arm. A person publishes it in the console, and sponsio pull or config="sponsio://default" brings the reviewed version back. Sending is best effort, so a console that is down never blocks the agent. See the hosted console.
Drafting contracts from natural language. sponsio validate "<rule in plain English>" turns a plain-English rule into a contract you can read back. Treat the output as a starting draft to review and adjust before you enforce. The determinism is in how contracts are enforced at runtime, not in how they're drafted.
It depends on how Sponsio is deployed. Each deployment tier states what it guarantees, and sponsio doctor tells you which tier a machine is in.
| Tier | Deployment | Guarantee |
|---|---|---|
| 1. Dev (default) | Daemon runs as the agent's user | Every hook path fails closed; changes to rules, mode, wiring and engine are detected and recorded, and weakening changes wait for your review |
| 2. Team | Daemon runs as its own system user, root-owned engine, managed host settings | The agent's user cannot change rules, mode, history, wiring or logs |
| 3. Enterprise | Agent sandboxed; Sponsio owns the tool gateway, credentials and egress | Every tool call and network connection goes through Sponsio |
Tier 1 is the default install. Tier 2 is sudo sponsio install --system, for Claude Code on macOS and Linux; Cursor stays at Tier 1 even then. Tier 3 is sponsio run --sandbox with the MCP gateway and the egress proxy, or a container recipe for servers. See the threat model for the assumptions behind each tier and what each does not cover.
22 contract bundles ship out of the box, organized by tier (always-on / per-tool / per-incident). Each bundle is a YAML pack composed from Sponsio's deterministic patterns. Drop one into sponsio.yaml and your agent is guarded against a known failure class in one line, with no per-contract authoring.
# sponsio.yaml: one-line bundle inclusion
agents:
my_agent:
workspace: "/srv/my-bot"
include:
- sponsio:capability/destructive # gate irreversible actions
- sponsio:capability/shell # if your agent runs commands
- sponsio:capability/filesystem # if your agent touches filesSee the full bundle reference for all 22 bundles, or the 48 underlying patterns for the primitives they compose. Want a bundle for your agent type? That is the most useful thing to contribute right now. Open an issue with your incident, CVE, or pattern.
Patches, issue reports, and new pattern proposals are welcome. Start with CONTRIBUTING.md. Sponsio's threat model draws on public security research; e.g. Simon Willison's "Lethal Trifecta" shaped our multi-tool composition contracts. Have a threat model we should defend against? Open an issue.
Apache 2.0 (LICENSE).
AI agents reading this repo: llms.txt lists canonical doc paths; llms-full.txt is the concatenated full context dump.