Introduction

Chio is the trust kernel for autonomous work. It sits between agents and the world, enforcing signed mandates and capabilities, producing cryptographic receipts for every action, and making agent work auditable, billable, reputation-bearing, and insurable.

The shift

Agents are becoming autonomous operators. They read production databases, dispatch transactions, commission work from other agents, and are starting to hold budgets, sign contracts, and settle value on their own. Today's stacks vary widely: a harness like Claude Code, an Agents SDK, or a LangChain app, driving native function-calling APIs, MCP or A2A servers, browser automation, or a shell in a container, sometimes sandboxed, sometimes with full desktop or database access. The pattern doesn't vary. All of them describe how to call a tool.

Pieces of the governance story already exist. An identity provider answers who is calling; a framework's tool allowlist answers whether they're allowed; a vendor's billing answers what it cost; an observability tool answers what happened. Each piece lives in its own silo, for its own tools, against its own identity store, in a format only its own product can verify. Nothing today answers all four together, cryptographically, across every protocol, every language, and every organization.

Pick any incident in production and the silos surface. An agent overspends; the identity provider can't see it because budgets live in the framework. An audit log records “user X did Y” and can't tell you whether X was a human or an agent acting on their credentials. A regulator asks for the bytes that prove what happened; the vendor returns a screenshot of its own dashboard, signed by the vendor. Each silo's evidence is only as portable as the silo, and the silos don't agree on identity, scope, or time.

That gap is where trust, money, and accountability break down. Chio closes it as infrastructure, not as a product integration. One kernel, fail-closed by default, at the choke point every agent call already passes through.

What universal means

Chio sits below the agent and above every tool. One kernel, four dimensions of universality:

• Cross-protocol. Wraps MCP, Google A2A, Zed's ACP, OpenAPI/HTTP, Kafka streams, AG-UI event flows, and arbitrary native tool servers, without modifying the server. Every protocol becomes governed without the caller noticing.
• Cross-language. A Rust core with drop-in SDKs for TypeScript, Python, and Go. Every identifier, every wire format, every invariant is frozen in chio-bindings-core so a receipt signed by a Rust kernel verifies byte-identically in a browser.
• Cross-organization. Self-certifying did:chio identifiers and W3C Verifiable Credential passports let capabilities, budgets, and receipts travel across administrative domains. No shared directory, no universal root, no mutual trust assumption.
• Cross-deployment. Run the kernel embedded inline in the agent process, as a native sidecar, as a hosted MCP edge, or as an Envoy ext_authz filter in front of any service. Same invariants in each shape.

What totally secure means

The kernel runs a zero-ambient-authority model: agents are fully untrusted and hold no permissions by default. Every tool call must present a capability token that is signature-valid, in-scope, unexpired, and within its budget. Fail-closed: missing capability, no action.

Eighteen composable guards evaluate the request in order, covering filesystem paths, shell commands, network egress, tool access, secrets, patch integrity, prompt safety, threat intel, velocity and rate limiting, and agent-surface controls (computer use, browser automation, code execution, remote desktop), plus any custom guards you add. Any failure short-circuits the pipeline. Every decision, allow or deny, produces a signed, append-only cryptographic receipt you can verify offline years later against nothing but the agent's public key and the kernel's root.

Each attack class meets the same wall. Prompt injection that tries to escalate the agent past its scope fails at the capability check, not at a model heuristic. Leaked or stolen tokens expire on their own clock and cannot exceed their attenuated scope. A compromised agent runtime cannot grant itself authority it was never issued; the kernel sits outside the agent process and treats every call as adversarial. A malicious tool server can return bad data, but cannot forge receipts, mint capabilities, or widen what the caller is allowed to do next. Supply-chain backdoors hit the same ceiling: the granted capability, nothing further.

The practical guarantee is bounded blast radius. Even if an agent process is fully owned, the worst case is the capability it was holding at that instant: scoped, time-bounded, budget-capped. No lateral movement to other tools, no privilege creep, no quiet upgrade to a wider scope. Every step the attacker takes still produces a signed receipt the security team can replay offline against the public key alone, no original infra required. Forensics that used to take weeks of log archaeology resolves in seconds: the evidence was generated at the point of decision, not reconstructed after the fact.

What economic actor means

Every capability token can carry a MonetaryAmount budget denominated in minor-unit integers: USD cents, EUR cents, USDC, BTC satoshis, whatever. No floats, no rounding errors, no fuzzy reconciliation. The kernel enforces the budget through a three-phase pre-charge / dispatch / reconcile cycle. Money is reserved before the tool runs, dispatched on success, and settled against priced receipts. Cross-currency conversions pull from signed on-chain oracles so the evidence trail survives disputes.

An agent with a $50 budget literally cannot spend $51. A tool priced at 3¢ per call gets paid 3¢ per call, or the call doesn't happen. Agents settle with each other, with tool servers, and across chains, under invariants the kernel guarantees.

Those rails change what agents can do without a human in the loop. Quote, accept, settle, and dispute become first-class operations between two agents, between an agent and a tool server, and between an agent and a smart contract; routine spend needs no approval step because the bounds are cryptographic, not procedural. Per-call pricing and live marketplaces work without invoicing, accounts receivable, or end-of-month reconciliation. The same signed receipts that audit security also reconcile the bill: one substrate carries authorization, evidence, and money, so finance and security read the same artifact instead of arguing over which log is authoritative.

Settlement works across organizations and across chains. A Stripe usage record, a USDC transfer on an EVM chain, and an off-chain ledger entry share one receipt format and one oracle-priced evidence trail; an agent in your org can pay an agent in another org, or a smart contract on a public chain, under the same invariants. Federation handshakes lock in mutual capability and policy attestation up front, so cross-organization spend is bounded by the stricter of the two policies, not the looser. Disputes resolve against signed receipts and signed price oracles, not against vendor support tickets.

The four questions

MCP tells agents how to call tools. Chio answers the four questions MCP leaves open:

Quick example

Wrap any existing MCP server with Chio governance in one command:

$ chio mcp serve --policy ./policy.yaml --server-id srv-files \
    -- npx -y @modelcontextprotocol/server-filesystem ./workspace

Every tool call through that server is now mediated. Capabilities are validated, guards are evaluated, budgets are enforced, and receipts are signed, all before the tool executes.

Architecture at a glance

Five components compose the Chio trust stack:

The trust boundary is deliberate. The kernel is the only trusted component, which keeps the TCB small enough to formally analyze, fuzz exhaustively, and review line by line. The agent stays untrusted not because we expect it to misbehave, but because expecting otherwise is what makes a security model fail; treating it as adversarial costs nothing, because Chio drops in front of an existing agent without asking the agent to change. The tool server stays sandboxed: whatever it does internally, it no longer answers to the agent directly, only to capabilities the kernel has already validated. Concentrating trust in one small surface is what lets everything around it stay as messy as it already is. This is the classic security-kernel design (Anderson's 1972 reference monitor, and capability microkernels like seL4, KeyKOS, and EROS) applied to agent-tool calls rather than CPU and memory.

Next steps

From here, pick the path that matches what you're doing:

• Quick Start: wrap an MCP server and watch the first signed receipt land in under five minutes.
• Installation: install the CLI, SDKs, and kernel in the shape that matches your deployment.
• Architecture: the four-stage kernel flow, the eighteen-guard pipeline, and which pieces sit inside the bounded verified core.
• Capabilities: scoped, time-bounded, delegatable authority, with attenuation that never widens.
• Guards: every guard in the default pipeline, what it enforces, and how to configure it.
• Write a Policy: build your first policy file from the ground up.