Security

Source

This page normatively reflects spec/SECURITY.md in the chio repository. Status: Normative shipped surface. Version 1.0, dated 2026-04-13. The keywords MUST, SHOULD, and MAY are normative in that document.

The register and the transport profiles here render from the machine-readable companion, spec/security/chio-threat-model.v1.json, whose shape spec/security/chio-threat-model.schema.json pins: the top-level keys, the boundary surface and asset enums, and the per-threat object. spec/security/coverage.yaml maps each threat id to the in-tree files an operator can read to check the model against the code.

Synopsis

The model is the JSON document with schema id chio.threat-model.v1, last updated 2026-05-02. It covers the agent-kernel-tool trust boundary: the path from one caller holding authority material to one mediated tool execution, across the 4 surfaces named below. It states 20 threats, each with the surfaces it reaches, its controls, and the risk that remains after them.

Boundary

The security boundary is the path from one caller with authority material to one mediated tool execution:

• capability issuance or continuation on the trust-control surface
• hosted or native delivery of that authority to the kernel
• kernel admission and policy evaluation
• transport from the kernel to the selected tool server
• receipt generation and return

Out of scope

• broader wallet, passport, and web3 settlement profiles, except where they directly change sender constraint or delegation semantics at this boundary
• host OS hardening beyond the transport and process-isolation requirements stated here

Primary assets

The model names these assets as the ones the boundary protects, and these surfaces as the ones it spans.

Threat register

The register states the threats the shipped Chio boundary must resist. The surface column carries the model's own surface identifiers, of which there are 11 across the register.

The threats

Each entry below gives the attack, the surfaces it reaches, the controls the model records as existing or implemented, and the risk that remains under them.

Capability token theft

Attack: capability token theft or reuse by an unintended caller.

Surfaces: hosted_mcp, native_chio, trust_control

Controls:

• Capabilities are signed, time-bounded, and revocable.
• Chio-native DPoP can be required per grant, and hosted sender-constrained sessions can bind to DPoP or mTLS continuity.

Residual risk: Compatibility profiles still allow bearer-style capability use when sender constraint is not required, and replay protection weakens across restart or failover when nonce state is only process-local.

Kernel impersonation

Attack: a caller speaks to a fake kernel or hosted edge.

Surfaces: hosted_mcp, native_chio

Controls:

• Capabilities and receipts are signed artifacts and hosted/native version contracts are explicit.
• Cross-host deployments are required to use authenticated transport before authority is trusted.

Residual risk: Plaintext local-development modes intentionally do not provide peer authenticity, and receipt trust still depends on deployment-specific trust-anchor distribution.

Tool server escape

Attack: the selected tool server exceeds its intended confinement.

Surfaces: kernel_to_tool

Controls:

• The kernel mediates capability scope, server id, and tool name before invocation.
• Production tool-server transport is modeled as an authenticated channel instead of anonymous raw TCP.

Residual risk: Chio mediation does not by itself sandbox arbitrary tool-server code; a compromised tool process can still abuse whatever host privileges the operator granted it.

Replay attacks on the native channel

Attack: a captured native request or proof is replayed on the framed lane.

Surfaces: native_chio

Controls:

• Chio-native DPoP can bind a request to capability id, tool target, action hash, freshness, sender key, and nonce uniqueness.
• Capabilities are time-bounded and can be revoked.

Residual risk: The native framed lane has no separate in-band anti-replay mechanism outside the sender-proof and capability systems, so non-DPoP grants remain replayable within their validity window if the transport is exposed.

Resource exhaustion denial of service

Attack: memory, stream, or concurrency pressure denies service.

Surfaces: hosted_mcp, kernel_to_tool, native_chio, trust_control

Controls:

• Native frames larger than 16 MiB are rejected, and hosted sessions keep explicit lifecycle and stream-attachment limits.

Residual risk: Size checks and lifecycle rules reduce but do not eliminate asymmetric workload attacks, and authenticated callers can still consume their own allowed quota share.

Delegation chain abuse

Attack: an attacker widens, truncates, or otherwise abuses delegated authority.

Surfaces: hosted_mcp, native_chio, trust_control

Controls:

• Trust-control delegated issuance already enforces a signed delegation-policy ceiling when one is supplied.
• Chio core exposes delegation-chain and attenuation validators and the runtime already carries revocation state.

Residual risk: The shipped runtime is stronger than unchecked delegation metadata, but it is not yet a universally recursive, fail-closed delegated-authority proof system at every entry point.

SSRF via HTTP substrate

Attack: an agent crafts tool invocations that target internal network endpoints through the HTTP substrate.

Surfaces: hosted_mcp, kernel_to_tool

Controls:

• The InternalNetworkGuard blocks egress to private, reserved, loopback, link-local, cloud metadata, and Kubernetes addresses.
• DNS rebinding detection, encoded IP detection, and IPv4-mapped IPv6 handling catch common obfuscated internal targets.

Residual risk: DNS time-of-check/time-of-use gaps remain deployment-sensitive, but substrate callers now require explicit scheme and authority allowlists, address-class denials, redirect ceilings, and response-size ceilings before outbound HTTP is accepted.

PII or PHI exposure in responses

Attack: a tool response leaks PII or PHI (SSN, MRN, ICD-10 codes, email, etc.) to the agent or downstream consumers.

Surfaces: tool_response_pipeline

Controls:

• The ResponseSanitizationGuard scans responses for PII and PHI patterns with configurable sensitivity levels and block or redact actions.
• Pre-invocation scanning prevents PII in request arguments from reaching tool servers, and custom patterns support deployment-specific sensitive data.

Residual risk: Regex-based pattern detection is incomplete, may false-positive in non-medical contexts, and does not scan image or binary response content.

Agent velocity abuse

Attack: a single agent overwhelms the system by issuing requests across many capabilities faster than intended.

Surfaces: hosted_mcp, kernel_to_tool, native_chio, trust_control

Controls:

• The AgentVelocityGuard enforces per-agent and per-session rate limits using token-bucket semantics with configurable burst factors.
• Separate buckets per agent and per session isolate one caller's exhaustion from other agents and prevent cross-session token sharing.

Residual risk: Rate limits are process-local, and an attacker controlling multiple agent identities can multiply the effective allowed rate.

Cumulative data exfiltration

Attack: an attacker exfiltrates data through many small requests that individually appear benign.

Surfaces: session_data_flow

Controls:

• The DataFlowGuard reads cumulative bytes-read and bytes-written totals from the session journal and denies requests when configured limits are exceeded.
• The DataTransferAdvisoryGuard provides early warning before hard limits, and the session journal uses saturating arithmetic for data-flow accounting.

Residual risk: Per-session accounting can be bypassed through many short sessions, and byte counts do not measure semantic information density or compression.

Behavioral sequence attack

Attack: an attacker chains tool invocations in dangerous sequences (e.g., execute then overwrite, or skip required initialization).

Surfaces: session_tool_sequence

Controls:

• The BehavioralSequenceGuard enforces required predecessors, forbidden transitions, max consecutive invocations, and required first-tool constraints.
• The session journal tracks the complete tool invocation sequence, including denied invocations.

Residual risk: The guard cannot prevent cross-session dangerous sequences, non-adjacent forbidden transitions, or semantically dangerous invocations hidden behind benign tool names.

WASM guard resource exhaustion

Attack: a malicious or buggy WASM guard module consumes unbounded CPU or memory.

Surfaces: wasm_guard_runtime

Controls:

• WASM guards execute under a fuel budget that limits CPU per invocation and fails closed on fuel exhaustion.
• WASM guards execute in isolated linear memory with no host filesystem, network, kernel-state, or host-callback access.

Residual risk: Linear memory pressure within the runtime limit and compilation CPU for pathologically complex modules are not fully capped by Chio fuel metering.

Post-quantum signature downgrade

Attack: an attacker substitutes a classical-only signature where a post-quantum protected artifact is required.

Surfaces: hosted_mcp, native_chio, trust_control

Residual risk: Until hybrid signature verification and cryptographic-floor enforcement ship, operators must treat post-quantum protection as planned rather than available.

TEE quote forgery or misbinding

Attack: an attacker forges, replays, or misbinds a TEE quote to claim execution in a trusted runtime.

Surfaces: hosted_mcp, native_chio

Residual risk: Until platform quote verification lands, TEE deployment claims depend on external operator evidence and are not independently verified by Chio.

Passkey credential theft

Attack: an attacker steals or abuses a passkey-backed credential path to obtain fresh capabilities.

Surfaces: hosted_mcp, native_chio, trust_control

Residual risk: A compromised authenticator or issuer account can still request fresh capabilities until revocation propagates, and platform phishing resistance depends on correct relying-party and origin configuration.

Audience confusion

Attack: a capability minted for one audience is presented to another runtime or tool boundary.

Surfaces: hosted_mcp, native_chio, trust_control

Residual risk: Deployments that reuse broad audience names across environments can still create operational confusion even when cryptographic envelope checks are correct.

Weights hash spoof

Attack: a provider lies about loaded model weights to satisfy a signed model-card check.

Surfaces: kernel_to_tool, native_chio

Controls:

• Provider binding requires a signed model card that binds the weights hash to allowed capabilities, banned tools, issuer, and validity window.
• The kernel refuses provider bind when the requested capability set is not a subset of the model card or when a banned tool is requested.
• Model-card verification reuses the existing attestation verifier path instead of introducing a parallel signature root.
• Provider adapters expose a loaded-weight digest surface; local providers recompute the digest from loaded bytes and hosted providers return a typed unavailable error that kernel binding rejects fail-closed.

Residual risk: Hosted providers that do not expose loaded model bytes cannot bind under this check; deployments must use local recomputation or a signed model-card bundle with a provider surface that can produce a recomputed loaded-weight digest.

Mobile attestation replay

Attack: a replayed App Attest assertion or Play Integrity token bypasses issuer freshness checks.

Surfaces: capability_issuance, mobile_android, mobile_ios

Controls:

• App Attest assertions and Play Integrity tokens must bind to a fresh issuer challenge or nonce before a mobile capability is minted.
• The mobile issuer must reject stale, reused, or audience-mismatched attestation evidence fail-closed.
• T0.C verifier fixtures exercise replayed App Attest assertions and Play Integrity tokens before coverage can flip to covered.

Residual risk: Platform attestation services do not protect flows that reuse server challenges or accept broad audiences; deployments must keep nonce state durable enough for their mobile issuance window.

Device key extraction

Attack: mobile signing material is exported or misclassified outside Secure Enclave, StrongBox, or TEE custody.

Surfaces: capability_issuance, mobile_android, mobile_ios

Controls:

• iOS signing keys must remain in Secure Enclave or App Attest managed storage and Android signing keys must prefer StrongBox with TEE fallback explicitly marked.
• Mobile receipts must use per-call signing assertions or hardware-bound key references rather than exportable long-lived signing seeds.
• The issued capability must carry a trust-level marker so downgraded Android API 26-27 devices cannot claim StrongBox-backed custody.

Residual risk: A fully compromised mobile OS can still interfere with UI and request timing; this control only prevents export of the device-bound signing key from being treated as normal custody.

Play Integrity token replay

Attack: a stale Play Integrity JWS is reused to mint a fresh mobile capability.

Surfaces: capability_issuance, mobile_android

Controls:

• The Play Integrity verifier must assert nonce equality against issuer-generated nonce state before minting any capability.
• The issuer nonce store must consume accepted Play Integrity nonces once and reject duplicate presentations.
• T0.C verifier fixtures include stale JWS, wrong-nonce JWS, and wrong-audience JWS cases before coverage can flip to covered.

Residual risk: Google-signed verdict freshness still depends on issuer nonce storage and clock policy; a weak deployment can make a valid token replayable by accepting stale nonce state.

Transport security requirements

Transport requirements are surface-specific. The model states them as one profile per surface, with the value for each requirement and for the posture a deployment falls to when that requirement is unmet.

Additional rules

Three rules hold across every profile. Attestation binding never authorizes on its own: a profile that binds an attestation digest MUST still pair it with DPoP or mTLS continuity over the same request, which the model records as attestation_binding_never_authorizes_alone_it_must_pair_with_dpop_or_mtls_continuity. When a required transport security property is missing, the implementation MUST deny the request or restrict the deployment to an explicitly local development posture, recorded as missing_required_transport_security_must_deny_or_downgrade_to_explicit_local_dev_only_posture.

A deployment MUST NOT claim impersonation resistance, confidentiality, or replay resistance while it operates on plaintext remote transports.

Implementation guidance

• Same-host development can rely on loopback or UDS transport. That is a deployment carve-out, and it does not weaken the production rules.
• Cross-host deployments treat sender constraint and transport authentication as complementary: transport authentication proves the service identity, and DPoP proves the caller possesses the sender-bound key.
• Transport security alone does not make a tool server safe. Chio mediation protects admission and auditability; host-level sandboxing remains the operator's responsibility.

Machine-readable register

spec/security/chio-threat-model.v1.json is the normative machine-readable representation of the threat set, the mitigation and residual-risk mapping for each threat, and the transport requirements per surface. Implementations and standards work SHOULD treat that artifact as the stable registry. The register on this page is read out of it at the pinned commit, so the two do not drift.

Related

• Assurance Model: what each assurance claim rests on.
• Formal Assumptions: the assumptions the proofs admit.
• Fail-Closed: what the kernel does when a check cannot complete.
• Wire Protocol: the message shapes and lifecycle flows these attacks target.