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.
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, 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.
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 call | Decision |
|---|---|
| Publish, with no test call earlier in the session | Refused before dispatch. The session journal holds no call to the required predecessor. |
A patch whose added lines include chmod 777 | Refused by patch-integrity: an added line matches a default forbidden pattern. |
| Publish, after the tests ran | Passes 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 post | Decision |
|---|---|
| The draft, with no grant | Refused at egress: the retained label exceeds the tracker’s clearance. |
| The reviewed draft, with the grant | Admitted, and the grant is consumed. |
| An edited draft, or another destination | Refused with BindingMismatch. |
| A second post with the same grant | Refused 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 refund | Decision |
|---|---|
| Keeps the running total under the threshold | Proceeds on the agent’s authority. |
| Would cross the threshold | Stops at the budget check. The kernel prepares a signed approval proposal instead of dispatching. |
| Two votes from one approver’s key | Count as one approver. The proposal keeps waiting. |
| Votes from two eligible keys over the proposal | The 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 graphs | Decision |
|---|---|
| A family allowance of six | Every planned send completes. |
| A family allowance of four | The first four sends complete. The kernel refuses the next call from any worker at admission. |
| The root capability revoked | The kernel refuses every worker’s call as revoked. |
| A worker replays or widens its authority | Refused. |
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 call | Result |
|---|---|
| A real tool in its grant | Admitted. The guard finds no registered decoy in the named tool or the presented capability. |
| The honey tool | Refused before dispatch, with a signed tripwire_observation event. |
| Any call while the decoy registry cannot answer | Refused 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 status | Meaning |
|---|---|
refines | Within the analyzed rules, the candidate admits nothing the current policy denies. |
does_not_refine | The candidate admits the witness request, and the current policy denies it. |
inconclusive | The 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_tier | A USD 12 batch of quotes |
|---|---|
unverified | You issue no grant, so there is no call to make. |
verified: 1 hour, USD 50, approval above USD 10 | Waits for your approver’s token. |
premier: 8 hours, USD 500, approval above USD 100 | Proceeds. |
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 returns | Decision and ledgers |
|---|---|
| The reproduced binary | Allow. The delivery_contract block reads result: matched, and the kernel captures the cost from the hold. |
| Different bytes | denied_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.