Assurance Model

Zero Ambient Authority

In many systems, a process inherits permissions from its execution context: user accounts, IAM roles, and environment variables. Reducing that authority requires removing permissions after the fact.

In Chio, an agent starts without authority. A Capability Authority must issue a signed token before the agent can read a file, call an API, execute a shell command, or invoke a tool.

This applies least privilege to AI agents. A token limits the action, duration, and constraints available to the agent.

It also lets counterparties determine what another agent was authorized to do. In the autonomous-commerce model, a counterparty can inspect what was authorized and what happened. The kernel is the trusted component; the model states what is proved about it and which assumptions bound the remaining components.

Comparison with Traditional Models

Trust Levels

Each component has a trust level. The level defines its permitted role and the guarantees associated with that role.

Fail-Closed by Default

The kernel uses fail-closed semantics: an error at an evaluation stage results in denial.

• Missing token: deny
• Invalid signature: deny
• Expired token: deny
• Guard throws an internal error: deny
• Tool server timeout: deny
• Budget exhausted: deny
• Kernel panic: deny

A misconfigured or partially deployed system denies the call. Within this model, disrupting the kernel causes a denial of service rather than a privilege escalation.

Principle of Least Privilege

Chio enforces least privilege at multiple levels:

• Tool level: tokens grant access to specific tools by name, not to entire servers
• Parameter level: constraints narrow the arguments a tool can receive (e.g., only paths matching ./workspace/**)
• Time level: token expiration bounds the time window for authority
• Economic level: per-invocation and total cost caps prevent runaway spending even if the scope is valid
• Rate level: velocity guards limit how quickly an agent can act, bounding the damage rate

Component Boundaries and Isolation

The design enforces trust boundaries between components.

Agent and Tool Server Boundary

In the governed-call deployment path, agents and tool servers have no direct communication path. The kernel mediates each tool call:

• The kernel validates the token and evaluates guards
• The kernel checks and records metering information
• The kernel signs and appends a receipt

In this deployment path, tool servers accept connections from the kernel. The boundary prevents an agent from bypassing token validation and guard evaluation.

Tool Server Isolation

Tool servers are sandboxed. They receive pre-validated requests and return results. The kernel need not disclose the requesting agent's identity, capability token, or policy to the tool server. This separation limits what a compromised tool server can use to escalate privileges; it does not remove the server's ability to perform the dispatched work.

Receipt Log Immutability

The receipt log is append-only for the configured receipt-store path. Each receipt is signed with the kernel's Ed25519 key. A verifier with the corresponding public key can detect changes to its signed bytes.

Attenuation

When a capability is delegated, the child token must narrow the parent token's permissions. The kernel enforces this property, attenuation, during token validation.

Concretely, a delegated token must have:

• A scope that is a subset of the parent's scope
• An expiration no later than the parent's expiration
• Invocation limits no greater than the parent's limits
• Cost caps no greater than the parent's caps

In the bounded P1 model, each validated child token has authority no greater than its parent.

CA (root authority)
 └─ Orchestrator token: read_file + write_file, 1 hour, 100 calls
     └─ Research agent token: read_file only, 30 min, 25 calls
         └─ Sub-agent token: read_file only, 10 min, 5 calls

Signed Decision Records

A mediated-decision receipt records the request, decision, guard results, and timing data for a kernel evaluation. The kernel signs the receipt with its Ed25519 key. That signature lets a verifier check:

• The receipt bytes were signed by the kernel key
• The kernel recorded the embedded request in its decision
• A changed signed field causes signature verification to fail

A receipt proves that the kernel key signed a record. It does not alone prove who originated a request, that an external tool performed its effect, or that the receipt store retained every record.

Federation

Chio supports cross-organizational trust relationships through signed capabilities. An organization that recognizes another's issuing authorities can let its agents invoke tools across the boundary. A counterparty in another trust domain can verify the receipts it receives. The bilateral case, mutual authority recognition, and the receipts two organizations settle against are described in Bilateral Federation and Bilateral Receipts.

A capability token includes its signature chain. The receiving kernel performs signature verification locally against the capability-issuer public keys in its trust store; it does not query the issuing organization during that check.

A signed authority profile configures this trust relationship. An operator running the issuer supplies an AuthorityProfileDocument (the lease, governance, BBS, and revocation authorities it trusts, each with a public key and a validity window) plus the local signing seeds. The issuer validates each input fail-closed. A seed signs only when its derived public key matches its profile entry. The issuer signs three record types from that profile:

• ChioIssuanceBundle: capability leases and lease-scope bindings, with a governance receipt for destructive steps.
• SignedChioRevocationCheckpoint : revocation state published under monotonic epoch enforcement; an older checkpoint cannot replace a newer one.
• ChioVerifierTrustBundleDocument : the bundle a verifier loads to decide which authorities, workflows, and disclosure policies it will accept.

# Issue capability leases + governance receipts from a signed authority profile
$ chio federation authority issue

# Publish a revocation checkpoint under monotonic epoch enforcement
$ chio federation authority checkpoint

# Assemble the verifier trust bundle peers load to admit this authority
$ chio federation authority trust-bundle assemble

The issuer does no networking or storage; it performs validation and signing. The admission and reputation contracts live in chio-federation, the network accept-time gate in chio-federation-transport-iroh, and the lease and governance record definitions in chio-governance. Agent identity is also represented in this configuration: a did:chio identifies an agent's Ed25519 public key. An Agent Passport can be presented to a receiving kernel without a registry lookup.

Summary

The kernel denies by default, records signed decisions, and enforces attenuation on delegated authority. Components above the kernel rely on those behaviors through its interfaces.