Chio/Docs
LOGIN · JOIN

What You Can Build

Compose the kernel’s mechanisms into systems you could not safely run without it, and find the call where the kernel decides in each.

Concept chio@5f63e6e

On this page

Some agent systems are worth building only if a hostile sentence in their input cannot redirect them. A fixer that merges its own patches, a triage agent that turns a customer’s private ticket into a public issue, and a swarm whose workers share one invocation allowance all read text that strangers wrote. Chio supplies the kernel underneath them: each call meets the authority, data rules, and limits the application set before the agent started.

Each system below combines three or more mechanisms from this section and the Anatomy pages, and each turns on one decision the kernel makes at a specific call. The application keeps its own part: the goals, the models, the review interfaces, and the classification of its data.

Each system turns on one decision

Eight systems built on Chio against the fifteen kernel mechanisms they combinepassports1grant scope4delegation1identity1budgets and quotas4approval4guards3session rules1information flow2confinement1delivery contract1receipts and replay6policy analysis1decoys1revocation2defended coding agent6ticket to public issue3two-person payment4research swarm5honeytoken tripwire4policy canary3reputation-priced autonomy5pay for the artifact3per systemper mechanism33 uses8 decisive
Kernel mechanisms against the eight systems that combine themdefended coding agent6ticket to public issue3two-person payment4research swarm5honeytoken tripwire4policy canary3reputation-priced autonomy5pay for the artifact3passports1grant scope4delegation1identity1budgets and quotas4approval4guards3session rules1information flow2confinement1delivery contract1receipts and replay6policy analysis1decoys1revocation2per mechanismper system

Eight systems, fifteen mechanisms33 uses · 8 decisive

Rows are systems built on Chio. Columns are kernel mechanisms, ordered from authority issued before a call to evidence and response after it. Select a system or a mechanism.

Eight systems against fifteen mechanisms, 33 uses, one decisive mechanism per system.

A mark records that a system’s design relies on the mechanism, as its section on the page describes. The matrix measures no deployment, and a system can use mechanisms its row leaves out.

Read across a row for what one system combines, and down a column for where a mechanism recurs. No mechanism decides more than two of the eight systems. Receipts and replay recur most, in six, because each of those systems hands its signed record to a later check.

A coding agent that publishes only tested patches

Give the fixer a shell and let it carry issue #415, the dependency upgrade, to a published change: it writes the patch, runs the tests, and publishes. Text in the issue, in pull request #421, or in the upgraded dependency can carry instructions, so the system bounds what the shell reaches and the order in which the work can finish.

The fixer’s grant covers /workspace by path prefix. Its shell’s tool server runs under process confinement, which holds only the cage’s grants: named read paths, the exact files it may write, and no network route. The patch-integrity guard checks each patch against size limits and forbidden patterns in added lines. A sequence rule lists the test tool under required_predecessors for the publish tool. Your pricing lead approves publication of the exact tested candidate, and the patch leaves with its signed receipts.

The fixer’s next callDecision
Publish, with no test call earlier in the sessionRefused before dispatch. The session journal holds no call to the required predecessor.
A patch whose added lines include chmod 777Refused by patch-integrity: an added line matches a default forbidden pattern.
Publish, after the tests ranPasses the sequence rule. Publication still waits for the pricing lead’s approval bound to that candidate.

The sequence rule checks that the test tool ran in the session; the application checks that the tests passed for this candidate. Build a software factory runs the repository-scoped tools, binds the test result and review to one candidate digest, and publishes only with a separate approval of that candidate. Run a governed coding task exports the patch with its original signed receipts for a separate checkout to verify. Beyond Blocklists shows the rewrites that the grant and the cage stop.

A private ticket becomes one public issue

The triage agent can read Harbor Goods’ private support tickets and file issues about them on the pricing project’s public tracker. It sees the Harbor Goods contact’s account details while it works, and only text a person reviewed reaches the tracker.

The host classifies ticket reads with the ticket system’s information label, and each read joins that label into the session’s retained state. The tracker’s destination clearance does not cover the label, so the kernel refuses the post at egress however the agent paraphrased the ticket. Your pricing lead reads the draft and signs a declassification grant bound to its request hash, the source label hash, the destination, the tool, and a purpose. The host carries the grant on the request in declassification_grant.

The postDecision
The draft, with no grantRefused at egress: the retained label exceeds the tracker’s clearance.
The reviewed draft, with the grantAdmitted, and the grant is consumed.
An edited draft, or another destinationRefused with BindingMismatch.
A second post with the same grantRefused with AlreadyConsumed.

The session keeps the ticket’s label after the post, so the agent’s next disclosure meets the original restriction. Your application classifies the ticket reads, sets the tracker’s clearance, and supplies the review interface and the approver’s key; the host chooses which declassification authorities its flow resolver trusts. Declassification runs the same sequence on a research summary against a live receiver, including a retry that authorizes no second send. Information Flow Across Calls follows the label from the read to the refusal.

Payments that need two people past a running total

An agent can issue pricing.refund on its own authority while the day’s running total stays under a threshold. A refund that would cross it needs two of your approvers to sign, and a copied token or another workload cannot stand in for the agent.

The grant carries require_cumulative_approval_above, and the kernel tracks cumulative authorized spend against its threshold. A threshold approval requirement names the eligible approvers, a threshold of two, and a collection window. Proof of possession requires the caller to sign each call with the key the capability names. A workload identity policy admits refund only from the refunds workload’s SPIFFE identity. A signed receipt, checked with its reconciled hold and execution nonce, can authorize accounting.

The refundDecision
Keeps the running total under the thresholdProceeds on the agent’s authority.
Would cross the thresholdStops at the budget check. The kernel prepares a signed approval proposal instead of dispatching.
Two votes from one approver’s keyCount as one approver. The proposal keeps waiting.
Votes from two eligible keys over the proposalThe kernel resumes the original request and evaluates current authority, budgets, and flow again before dispatch.

You supply the approver interface, which shows each person the bound proposal, and the payment rail that moves the refund. Threshold approvals runs a two-of-three decision over a 100 USD spending authorization through real kernel admission, including a refused duplicate signer; its adapter records the authorization in a local journal and settles no payment. Bind Workload Identity requires a named workload before execution.

A research swarm on one shared allowance

The reviewer can split the backlog, issues #417 to #419, across workers, add reviewers as results arrive, and change the plan while it runs. The workers draw on one invocation allowance, and one revocation stops all of them.

Each worker holds a grant delegated from the reviewer’s, narrower in scope and carrying a share of the parent’s budget in budget_share_bps. An aggregate invocation budget with scope delegation_family counts every descendant’s calls against one maximum, so spreading the work across more workers adds no capacity. Each worker’s reads join labels into its retained state, and persistent taint follows the lineage, so a worker cannot publish what its sources restrict. Revoking the reviewer’s capability refuses every descendant’s next call, because the kernel checks each link in a token’s delegation chain.

Six workers, three planned graphsDecision
A family allowance of sixEvery planned send completes.
A family allowance of fourThe first four sends complete. The kernel refuses the next call from any worker at admission.
The root capability revokedThe kernel refuses every worker’s call as revoked.
A worker replays or widens its authorityRefused.

Secure a Swarm runs these scenarios with real calls and a real mailbox. Delegate Sensitive Research carries labels into a narrower delegate and refuses an unreviewed publication. Build a research swarm supplies the coordination itself: it ranks governed assignments from signed observations, and each assigned worker still presents its own capability at the tool call.

A honey tool turns contact into containment

Offer an agent a tool that no legitimate task calls, and a call to it is a signal no ordinary workflow produces. The system refuses that call, records signed evidence, and contains the authority behind it under a reviewed response policy, without guessing intent from the agent’s text.

You register a honey tool in your private decoy registry and list it in the agent’s grant beside the real tools. The kernel’s tripwire guard runs first in its guard pipeline, refuses any call that names the honey tool, and publishes the match as a signed security event through authenticated ingress. The event carries the lineage of the grant the agent presented, so a temporal rule can join it with a later egress attempt from the same lineage into a correlated finding. Blast radius walks that lineage to the exact capabilities it reaches, and an independent response authority admits a plan that suspends that set at its next calls.

The agent’s callResult
A real tool in its grantAdmitted. The guard finds no registered decoy in the named tool or the presented capability.
The honey toolRefused before dispatch, with a signed tripwire_observation event.
Any call while the decoy registry cannot answerRefused until the registry answers again.

The honey tool must be in the grant: a call outside the grant’s scope is refused at the scope check, before the tripwire guard runs, and no event is published. An incomplete lineage walk returns no affected set, and no containment plan proceeds from it. You choose the honey tool and write the reviewed response policy that decides which correlated findings may act automatically. Decoys and Tripwires covers decoy placement, lifecycle, and custody. Contain a Compromised Agent revokes a running agent’s capability and cancels its process tree. Detect, Contain, Recover follows a honey-tool call in the review of pull request #421 from contact to containment.

A policy canary that runs before rollout

Before a new policy governs any agent, an operator can learn what it newly permits and which recorded calls it would decide differently. A widened rule then surfaces in review, before an agent can use it.

chio policy analyze with --against the current policy checks that the candidate narrows it. When it does not, a refinement_failure finding carries a witness: a concrete request that the candidate allows and the current policy denies, confirmed by the policy evaluator before the finding is reported. chio replay traffic --against evaluates each invocation in a recorded traffic capture under the candidate, runs no tool, and reports drift in verdict, attributed guard, and reason.

Refinement statusMeaning
refinesWithin the analyzed rules, the candidate admits nothing the current policy denies.
does_not_refineThe candidate admits the witness request, and the current policy denies it.
inconclusiveThe change touches policy fields outside the bounded analyzer, and the report says so in an analysis_incomplete finding.

This canary runs offline. The analyzer reports regex rules as not_analyzed, replay rejects policies with post-invocation hooks, and live traffic meets whichever policy the running processes loaded. Policy Rollout runs the replay comparison and the release that follows it. What a Policy Permits explains the refinement check and what the analyzer leaves out.

Autonomy priced by reputation

You can offer more autonomy to a caller whose record supports it: a grant on pricing that lasts longer, spends more, and asks your approver less often. An outside buyer’s agent arrives with an Agent Passport, and you decide what it is worth.

You verify the presented passport and accept or reject its issuer. Your rule maps the accepted trust_tier to grant terms when it issues the capability: a lifetime, a max_total_cost, and a require_approval_above threshold. The tier rests on recorded history: Chio’s local scorecard is computed from signed receipts, and the tier combines a compliance score with a behavioral-anomaly signal. The kernel does not derive authority from a passport score. From issuance on, it enforces the grant: the token expires, spend stops at max_total_cost, and a request at or above the threshold waits for an approval token.

The buyer’s accepted trust_tierA USD 12 batch of quotes
unverifiedYou issue no grant, so there is no call to make.
verified: 1 hour, USD 50, approval above USD 10Waits for your approver’s token.
premier: 8 hours, USD 500, approval above USD 100Proceeds.

The table applies the tier rule set out in Reputation & Passports; an operator writes the rule as part of its issuance policy. Agent Passport creates and verifies a passport and evaluates it under your own trust policy. Human-in-the-Loop follows the approval that the threshold triggers.

Pay for the artifact, not the call

You pay a partner’s build agent to reproduce the pricing-rs release binary, and pay only when the bytes match your own reference build. The same shape fits any purchase where the buyer knows the right output in advance.

You place the digest of the expected output in the agent’s grant as output_digest_sha256. The paid call runs on durable admission with a reversible hold. After the tool returns, the kernel hashes the final value after post-invocation transforms and compares it with the commitment before any payment decision.

The build agent returnsDecision and ledgers
The reproduced binaryAllow. The delivery_contract block reads result: matched, and the kernel captures the cost from the hold.
Different bytesdenied_after_delivery: a signed Deny, the hold released, zero currency charged, one invocation consumed.

A match establishes that the agent delivered the expected bytes. It says nothing about how the agent produced them, or whether they were worth the price. The Delivery Contract works through the reproducible build. Paid Reveal runs the same check on a market purchase, including its failed-delivery path. The build tool’s output envelope and the reference build are yours to define.

Start from a running system