Trust Model

Chio's trust model starts from a single axiom: agents have zero ambient authority. Every permission is explicit, every boundary is enforced, every decision is signed.

Zero Ambient Authority

In traditional systems, a process inherits broad permissions from its execution context: user accounts, IAM roles, environment variables it happens to read. Authority is ambient. It exists by default, and the only way to limit it is to strip it back, one rule at a time.

Chio inverts this. An agent starts with no permissions whatsoever. It cannot read a file, call an API, execute a shell command, or invoke any tool until a Capability Authority issues a signed token that explicitly grants that specific action. Authority is not inherited. It is conferred.

This is the principle of least privilege applied to AI agents. The agent receives the minimum authority it needs, for the minimum time it needs it, with the maximum constraints that still allow the task to succeed.

Comparison with Traditional Models

Trust Levels

Every component sits at a specific trust level. The level decides what the component is allowed to do, and what the system guarantees about its behavior.

Fail-Closed by Default

The kernel operates under strict fail-closed semantics. Any error, at any stage, results in denial. There is no fail-open path.

• 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

This means a misconfigured or partially-deployed system fails safely. An attacker who disrupts the kernel causes a denial of service, not 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: every token has an expiration, keeping the window of authority as small as possible
• 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

Trust boundaries between components are enforced by design:

Agents Never Talk to Tool Servers

This is the most important boundary in the system. Agents and tool servers have no direct communication path. Every interaction flows through the kernel. This means:

• Every tool call is authorized (token validated, guards evaluated)
• Every tool call is metered (cost checked and deducted)
• Every tool call is recorded (receipt signed and appended)

If an agent could bypass the kernel and talk to a tool server directly, every guarantee would collapse. The architecture makes this physically impossible: tool servers only accept connections from the kernel.

Tool Server Isolation

Tool servers are sandboxed. They receive pre-validated requests and return results. They do not know the identity of the requesting agent, the token that authorized the call, or the policy that governed it. This separation means a compromised tool server cannot escalate privileges or forge authorization.

Receipt Log Immutability

The receipt log is append-only. Once a receipt is committed, it cannot be modified or deleted. Each receipt is cryptographically signed by the kernel's Ed25519 key, making tampering detectable by any party that holds the kernel's public key.

Attenuation

When capabilities are delegated, the child token can only narrow the parent's permissions, never widen them. This property is called attenuation and is enforced by the kernel 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

This guarantees that delegation chains monotonically decrease in authority. A chain of length N always has less or equal authority compared to a chain of length N-1.

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

Non-Repudiation

Every kernel decision, Allow or Deny, produces a cryptographically signed receipt. This receipt contains the original request, the decision, the guard evaluation results, and timing data. Because the receipt is signed with the kernel's Ed25519 key:

• The kernel cannot deny having made a decision (the signature proves it)
• The agent cannot deny having made a request (the request is embedded in the signed receipt)
• No party can alter the receipt after the fact (the signature would become invalid)

Non-repudiation is the foundation of accountability. When something goes wrong, the receipt log provides an unambiguous, verifiable record of exactly what happened.

Federation

Chio supports cross-organizational trust through signed capabilities. Two organizations that recognize each other's Capability Authorities can allow their agents to invoke tools across organizational boundaries.

Federation works because capabilities are self-contained. A capability token carries its own proof of authorization (the signature chain). The receiving organization's kernel does not need to query the issuing organization; it validates the token's signature chain locally against its list of trusted CA public keys.

Same shape as TLS certificate chains: a browser trusts a certificate that chains back to a trusted root CA, a Chio kernel trusts a capability token that chains back to a trusted Capability Authority.

# Organization A's kernel trusts Organization B's CA
trusted_authorities:
  - name: org-b-production
    public_key: "ed25519:pub:b7c8d9..."
    # Constrain what federated tokens can do
    max_scope:
      grants:
        - server_id: srv-shared-data
          tool_name: read_file
          operations: [invoke]
          max_invocations: 1000

In one shape

Together those properties define the kernel: deny is the default, every allow is explicit, every decision is signed, and authority only narrows once it has been granted. Everything that sits above the kernel inherits those invariants without having to implement them.