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.

The proof manifest fixes what is checked. It names the required safety properties, and for each one the kinds of evidence it records. The kinds are the manifest's own words, so a property carried by a Lean theorem imported into the root module reads differently from one carried by an audited assumption about storage, transport, or the concrete cryptography.

The manifest's allowed axioms are Chio.Json.hash_collision_resistant, the symbolic collision resistance of the mechanized canonical hash, recorded under P4 and P7. The manifest also lists what the Lean statements do not reach, among them the concrete Ed25519, SHA-256, canonical JSON, TLS, clock, SQLite, and chain implementations beyond their audited assumptions, and async scheduling, network delivery, subprocess effects, and tool-server behavior after the verified decision core allows a call.

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: a constraint narrows the arguments a tool can receive, such as a path_prefix constraint whose value is /workspace/, which admits only paths starting with it
• 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

Under P1 capability attenuation, each validated child token carries authority no greater than its parent. The kernel also caps how far a chain may run: it validates the presented chain against a configured maximum delegation depth and denies a chain that exceeds it.

The Capabilities page shows a signed delegated token from the capability binding vectors, with the link that records the delegator, the delegatee, and the signature over that link.

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, lease-scope bindings, and governance receipts
$ chio federation authority issue \
    --profile ./authority-profile.json \
    --request ./issuance-request.json \
    --signing-keys ./signing-keys.json \
    --out-dir ./issuance

# Publish a signed revocation checkpoint from local authority state
$ chio federation authority checkpoint \
    --profile ./authority-profile.json \
    --revocations ./revocations.json \
    --signing-keys ./signing-keys.json \
    --out ./checkpoint.json

# Assemble the strict verifier trust bundle peers load to admit this authority
$ chio federation authority trust-bundle assemble \
    --profile ./authority-profile.json \
    --peer-pins ./peer-pins.json \
    --workflow-intersection ./workflow-intersection.json \
    --disclosure-policy ./disclosure-policy.json \
    --checkpoint ./checkpoint.json \
    --out ./trust-bundle.json

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.