Chio/Docs
LOGIN · JOIN

Security

Decide which component refuses each unwanted effect, what is only recorded, and which paths your deployment must close.

Overview chio@5f63e6e

On this page

An agent chooses its next action at run time, from text it did not write, so its safety cannot rest on what it intends. It rests on which component can still refuse an effect when the plan goes wrong, and on what the record proves afterward.

Every claim below is scoped to calls routed through the kernel and falls in one of four classes: prevent, where an owner refuses before the effect; detect only; advisory only; and cannot see, where the deployment closes the path.

Security mapSelect a section to see where its controls act.
cannot seeadvisory onlydetect onlypreventaagentrequestsdispatchesfresourcerefusedsignsprovesmapsKκauthorityK′shared boundariesλdata protectiondexecutionσkeys and credentialsedetection and responseρevidenceπshadow rollouthoperations⊢formal verification§compliance
cannot seeadvisorydetectpreventarequestsdispatchesfKκK′λdσeρπh⊢§

Kmediated path κauthority K′shared boundaries λdata protection dexecution σkeys and credentials edetection and response ρevidence πshadow rollout hoperations ⊢formal verification §compliance

Mediated path

The kernel

A request and its capability reach the kernel before any resource. The kernel admits or refuses before dispatch and signs a receipt either way.

Read more in The mediated call.

Each Security section placed on the claim class its controls make, from refused before effect to outside the kernel path. Every claim is scoped to calls routed through the kernel. Individual controls within a section are left out.

Five owners refuse before an effect happens

The kernel at the center of the map admits or refuses each request before dispatch and signs a receipt either way. Around it, each section owns one kind of refusal, and an application usually needs several of them on one operation.

Authority decides who may act, with which grant, and until when: a capability names a subject, a scope, and a validity window under an accepted issuer, delegation narrows it for a child, and invocation limits bound repeated use across the family. Data protection carries labels from a sensitive read through later calls, so a commit message cannot leak a customer's price floor, and a declassification grant authorizes one exact disclosure.

Execution puts enforcement in the component that performs the effect: a confined launch restricts the process, and retained operation state keeps an interrupted refund resolvable without sending it twice. Keys and credentials keep provider secrets in the credential broker, so the model never holds them. Shared boundaries apply when authority crosses to another agent, organization, or tenant: the kernel that serves each action admits it under its own policy.

Read more in Threat model, which places each adversary on the path and names the owner that stops it.

Detection and evidence record what the refusals could not

A signed receipt binds a decision to its signer and the operation it describes, refusals included, and an exported package verifies offline against keys the verifier pinned. Verify security evidence establishes those bindings, and Security receipts lists every record and schema. A receipt proves what the kernel decided; whether a provider's effect happened needs that provider's authenticated status.

Active defense turns signed security events, tripwires, and correlation into findings, and an event drives automatic response only when its producer's trust class allows it. A new cohort starts advisory only: shadow rollout records what its policies would have refused before an operator promotes it.

The deployment closes the paths the kernel never sees

A coding host that keeps its own unrestricted shell can still reach a file outside any mediated tool call. Deployment hardening closes those paths with separate service identities, protected durable state, and launchers that keep the kernel port unreachable. Investigate a session and contain a compromised agent cover the response once something has gone wrong.

Existing infrastructure keeps its part. Identity providers authenticate people and services, resource permissions constrain databases, and operating-system isolation bounds a worker. A policy engine such as OPA returns a decision; Chio also owns what happens after it, retaining the operation before the effect so a replacement process can resolve a lost response. Choose a security profile for the complete path, including the stores that preserve authority through interruption.

Proofs and mappings stand outside the rings

Formal assurance connects the authority rules to machine-checked proofs over their models, with the assumptions a deployment keeps, and threat coverage ties each claim to its tests. Compliance frameworks map regulatory clauses to the signed records an assessor verifies offline.

One run shows a useful read and a refused write

The tutorial puts the pricing project's workspace server behind a governed MCP edge, reads src/pricing.py, and tries to raise the discount tier to 80 percent. It needs the installed CLI, Python 3, and a non-root user:

Terminalbash
chio new security-agent --example security-agent
cd security-agent
python3 run.py
Output
ALLOW read_file: src/pricing.py returned
DENY write_file: src/pricing.py unchanged
Evidence: .chio/receipts.db and .chio/responses.json

Each line prints only after its assertion passes, and the second is checked against the file's bytes, apart from the tool's response. python3 inspect.py then lists the allow and deny receipts.

Next: secure one agent

Start with one agent and one refused write, then carry the same boundary into delegated research and a swarm.