Security

Source

This page normatively reflects spec/SECURITY.md in the chio repository. Status: Normative shipped specification. Version 1.0. The machine-readable companion file is spec/security/chio-threat-model.v1.json.

Boundary

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

• capability issuance or continuation through the trust-control API
• 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 details beyond the transport and process-isolation requirements stated here

Primary Assets

• capability tokens and delegation state
• session identifiers and sender-binding context
• kernel authenticity
• tool-server execution confinement
• receipt integrity and policy verdict provenance
• availability of the mediated runtime

Threat Register

The required threats for the shipped Chio boundary:

Capability Token Theft

Attack: an attacker captures a capability token, session artifact, or other authority handle and attempts to reuse it from a different caller or at a later time.

Existing controls:

• capabilities are signed and time-bounded
• the kernel can require Chio-native DPoP per grant
• the hosted edge can enforce sender-constrained DPoP and mTLS thumbprint continuity
• revocation state exists for capability identifiers

Required mitigations:

• sensitive or cross-host flows SHOULD require sender constraint rather than rely on bearer-only capability use
• operators SHOULD pair capability lifetimes with the smallest feasible validity window
• deployments that scale across restart or failover SHOULD use durable or shared replay state for sender proofs

Residual risk: compatibility profiles still allow bearer-style capability use when DPoP or equivalent sender constraint is not required; replay protection is weaker across restart or multi-node failover when proof nonce state is only process-local.

Kernel Impersonation

Attack: the caller establishes a session or native transport with a malicious service that pretends to be the Chio kernel or hosted edge.

Existing controls:

• capabilities and receipts are signed artifacts rather than unsigned JSON
• version negotiation is explicit on the hosted edge and exact-match on the native lane
• production tool-server transport is modeled as authenticated transport rather than anonymous raw TCP

Required mitigations:

• any cross-host hosted MCP or trust-control deployment MUST use TLS
• any cross-host native deployment MUST use TLS and MUST authenticate the remote peer before authority is treated as valid
• operator distributions SHOULD pin or otherwise securely provision Chio verifier keys, service certificates, or equivalent trust anchors

Residual risk: plaintext local-development modes do not provide confidentiality or peer authenticity; receipt verification still depends on the deployment's trust-anchor distribution discipline.

Tool Server Escape

Attack: an admitted tool server process reads or mutates host state outside its intended scope, or uses the kernel as a path to broader host compromise.

Existing controls:

• capability scope, tool name, and server id are mediated before invocation
• the kernel decides admission before any tool call reaches the server
• production tool-server transport is modeled as isolated transport rather than direct in-process mutation of kernel state

Required mitigations:

• tool servers MUST be treated as less trusted than the kernel unless they are part of the same reviewed binary and privilege domain
• cross-process or cross-host tool servers MUST run behind authenticated transport, and cross-host TCP MUST use mTLS
• operators SHOULD pair Chio mediation with OS or container confinement, least-privilege filesystem access, and outbound-network controls

Residual risk: Chio mediation cannot by itself sandbox arbitrary tool-server code. A compromised tool process can still abuse whatever host privileges the operator granted it outside Chio.

Native Channel Replay

Attack: an attacker captures a native Chio frame or proof and replays it on the length-prefixed channel to obtain duplicate or unauthorized execution.

Existing controls:

• the native lane is framed and typed, which limits parser ambiguity
• DPoP proofs can bind a request to capability id, tool target, action hash, sender key, freshness, and nonce uniqueness
• capabilities are time-bounded and can be revoked

Required mitigations:

• grants for replay-sensitive operations SHOULD require DPoP
• cross-host native traffic MUST use confidential authenticated transport so raw frames and proofs are not exposed on the network
• clustered or restart-tolerant deployments SHOULD avoid process-local-only nonce registries for high-value flows

Residual risk: the native framed lane has no independent in-band anti-replay marker outside the sender-proof and capability systems; non-DPoP grants remain replayable within their validity window if the surrounding transport is exposed.

Resource Exhaustion DoS

Existing controls: native frames larger than 16 MiB are rejected; hosted notification streams allow at most one active stream per session; hosted sessions have explicit terminal states.

Required mitigations:

• deployments SHOULD apply request-rate, concurrency, and time-budget limits at the hosted and trust-control edges
• operators SHOULD bound retained replay buffers, task queues, and per-session state
• high-value multi-tenant deployments SHOULD pair Chio with upstream load shedding and admission control

Delegation Chain Abuse

Attack: widening scope during delegation, truncating lineage, continuing from the wrong parent, or exploiting incomplete recursive validation.

Existing controls:

• trust-control delegated issuance already checks a signed delegation policy ceiling when one is supplied
• core helpers exist for delegation-chain validation and attenuation checks
• revocation state exists for capability identifiers

Required mitigations:

• delegated issuance MUST NOT exceed the signed delegation-policy ceiling
• runtime admission SHOULD resolve and validate complete parent lineage for high-trust delegated flows rather than trust presented metadata alone
• operators SHOULD revoke parent capabilities or delegation branches when downstream compromise is suspected

Residual risk: the current runtime boundary is stronger than unchecked delegation metadata but not yet a universally recursive, fail-closed delegated-authority proof system at every entry point; revocation completeness is only as strong as the resolved lineage available to the runtime.

SSRF via HTTP Substrate

Attack: crafting tool invocations that target internal network endpoints (RFC 1918, loopback, link-local, cloud metadata, Kubernetes service endpoints) through the HTTP substrate.

Existing controls:

• the InternalNetworkGuard blocks egress to private, reserved, loopback, link-local, cloud metadata, and Kubernetes addresses
• DNS rebinding detection catches hostnames embedding private IP patterns
• encoded IP detection blocks hex, decimal, and octal obfuscated addresses
• IPv4-mapped IPv6 addresses are resolved and checked against IPv4 rules

Required mitigations:

• deployments exposing HTTP substrate endpoints MUST enable the InternalNetworkGuard with DNS rebinding detection
• operators SHOULD add deployment-specific internal hostnames to the extra_blocked_hosts list
• the guard MUST fail closed on any address parse ambiguity

Residual risk: DNS time-of-check/time-of-use gaps remain. The guard does not inspect redirects that occur during tool execution.

PII/PHI Exposure in Responses

Existing controls:

• the ResponseSanitizationGuard scans responses for PII/PHI patterns with configurable sensitivity levels and block/redact actions
• pre-invocation scanning prevents PII in request arguments from reaching tool servers
• custom patterns can be added for deployment-specific sensitive data

Required mitigations:

• deployments handling healthcare or financial data MUST enable the ResponseSanitizationGuard at Medium sensitivity or higher
• operators SHOULD configure Redact mode rather than Block where partial results are acceptable, to reduce information loss
• operators SHOULD define custom patterns for any deployment-specific identifiers

Residual risk: regex-based detection is inherently incomplete; the ICD-10 pattern may produce false positives on short alphanumeric strings; image or binary content in tool responses is not scanned.

Agent Velocity Abuse

Existing controls:

• the AgentVelocityGuard enforces per-agent and per-session rate limits using token-bucket semantics with configurable burst factors
• separate buckets per agent prevent one agent's exhaustion from affecting others
• separate buckets per session prevent cross-session token sharing

Required mitigations:

• multi-tenant deployments MUST configure per-agent rate limits
• operators SHOULD set per-session limits to bound the damage from a single compromised capability
• operators SHOULD set burst factors close to 1.0 for high-value operations to prevent burst abuse

Residual risk: rate limits are process-local; an attacker controlling multiple agent identities can multiply the effective rate by the number of identities.

Cumulative Data Exfiltration

Existing 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 signals before hard limits are hit
• the session journal tracks all data flow with saturating arithmetic to prevent overflow

Required mitigations:

• deployments with sensitive data stores MUST configure DataFlowGuard limits appropriate to their data classification
• operators SHOULD pair DataFlowGuard with DataTransferAdvisoryGuard promotion rules to detect gradual exfiltration before the hard limit
• operators SHOULD set max_bytes_total in addition to individual read/write limits to catch mixed-mode exfiltration

Residual risk: data flow accounting is per-session; an attacker that establishes many short sessions can circumvent per-session limits. Byte counts reflect content-length, not semantic information density; compressed data may carry more information than the byte count suggests. Denied requests still count toward cumulative totals; the session is effectively terminated once a limit is hit.

Behavioral Sequence Attacks

Existing controls:

• the BehavioralSequenceGuard enforces four types of ordering constraints: required predecessors, forbidden transitions, max consecutive invocations, and required first tool
• the session journal tracks the complete tool invocation sequence including denied invocations

Required mitigations:

• operators SHOULD define forbidden transitions for known dangerous sequences (e.g., bash followed by write_file)
• operators SHOULD require initialization tools as the first tool in sessions that depend on setup state
• operators SHOULD set max consecutive limits to prevent infinite loops on destructive operations

Residual risk: forbidden transitions only check the immediately preceding tool; a dangerous pair separated by an innocent tool in between will not be caught. The guard operates on tool names, not on the semantic content of the invocations.

WASM Guard Resource Exhaustion

Existing controls:

• WASM guards execute under a fuel budget (default 10,000,000 units)
• fuel exhaustion immediately terminates the guest and the invocation is treated as denied (fail-closed)
• WASM guards execute in isolated linear memory with no access to host filesystem, network, or kernel state
• no host callback functions are exposed to the guest

Required mitigations:

• operators MUST set fuel limits appropriate to the complexity of their custom guards
• operators SHOULD test WASM guards in advisory mode before enabling them as blocking guards in production
• operators SHOULD monitor fuel consumption to detect guards that consistently approach their fuel limit

Post-Quantum Signature Downgrade

Attack: an attacker replaces or strips post-quantum signature material so a verifier accepts a classical-only artifact even when policy requires a post-quantum protected receipt, capability, or compliance certificate.

Existing controls:

• capabilities and receipts are already signed artifacts
• capability, receipt, and compliance-certificate verifier surfaces preserve explicit algorithm identity for classical and hybrid signing paths
• capability verification, compliance-certificate verification, the core receipt verifier API, and governed parent-receipt validation can enforce allow_classical, allow_hybrid, or pq_required

Required mitigations:

• signed artifacts that opt into the post-quantum profile MUST carry policy-visible algorithm metadata
• receipt, capability, and compliance-certificate verification MUST reject classical-only artifacts when the configured cryptographic floor requires post-quantum protection
• migration tests SHOULD cover both classical compatibility and rejection of downgraded artifacts under a post-quantum-required policy

Residual risk: verifier paths that do not receive a policy crypto_floor still use the explicit allow_hybrid compatibility floor, which accepts classical and hybrid receipts but does not require post-quantum protection. Compatibility callers that invoke helpers such as receipt verify_signature() directly do not enforce a post-quantum floor unless they route through the floor-aware verifier API.

TEE Quote Forgery or Misbinding

Attack: an attacker forges, replays, or misbinds TEE quote evidence so a verifier accepts a runtime as confidential or hardware-attested when the quote does not correspond to the kernel signing key and receipt root being verified.

Existing controls:

• receipt signatures already provide artifact integrity once the verifier has accepted the signing key
• attestation alone is not sufficient authorization under the transport rules in this document

Required mitigations:

• quote verifiers MUST validate platform evidence for Intel TDX, AMD SEV-SNP, and AWS Nitro before accepting confidential-runtime claims
• accepted quotes MUST bind report data to the kernel signing key and receipt root
• verifiers MUST fail closed on malformed, stale, mismatched, or unsupported quote evidence
• pinned positive and negative fixtures SHOULD cover each supported platform backend

Residual risk: platform quote verification is planned but not yet implemented in the shipped verifier crate; TEE deployment claims currently depend on external operator evidence rather than independent Chio quote verification.

Passkey Credential Theft

Attack: an attacker steals, compromises, or abuses a passkey-backed credential path and attempts to obtain fresh Chio capabilities from the issuer.

Existing controls:

• capabilities remain signed, time-bounded, and revocable
• kernel admission verifies capability signatures before use

Required mitigations:

• passkey-backed browser flows MUST present WebAuthn assertions to a server-side issuer rather than mint authority in the browser
• browser clients MUST NOT hold root capability or issuer signing material
• issuers MUST bind minted capabilities to the credential id, audience, scope set, and short expiry
• issuers MUST reject failed WebAuthn assertions and treat authenticator, challenge, or origin ambiguity as fail-closed

Residual risk: a compromised authenticator or issuer account can still request fresh capabilities until revocation propagates; phishing resistance depends on correct relying-party and origin configuration by the deployment.

Audience Confusion

Attack: a capability minted for one audience is replayed or presented to another runtime, hosted edge, or tool boundary that should not accept it.

Existing controls:

• Chio capabilities are signed artifacts with explicit scope and target data
• kernel admission already evaluates the requested tool boundary before invocation

Required mitigations:

• passkey-issued capabilities MUST carry an explicit audience in the signed envelope
• kernel verification MUST reject capabilities whose audience does not match the target runtime or tool boundary
• custody tests SHOULD include cross-audience presentation and envelope bit-flip cases

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

Weights Hash Spoof

Attack: a provider claims to have loaded one model artifact while actually running a different weights blob, then relies on that false hash to satisfy model-card policy.

Existing controls:

• provider binding is mediated by the kernel before tool execution
• Chio has a shared attestation verifier path for signed provenance evidence
• runtime provider bindings persist model-card identity fields, and provider health fails closed for required model-card modes when signed-card material, separately supplied runtime-observed loaded-weight evidence, or a matching live card digest is absent

Required mitigations:

• provider binding MUST require a signed model card when policy requires weights identity
• the signed card MUST bind the weights hash to allowed capabilities, banned tools, issuer, and validity window
• kernel binding MUST reject requested capabilities outside the card's allowed set and any requested tool listed as banned

Residual risk: until providers expose independently recomputable loaded-weight hashes, a malicious provider can lie about the loaded artifact before runtime health receives trustworthy provider-side loaded-weight evidence.

Mobile Attestation Replay

Attack: an attacker replays a valid App Attest assertion or Play Integrity token against a later capability-mint request, bypassing issuer freshness checks.

Existing controls:

• mobile capability issuance is modeled as an issuer-mediated flow rather than a local-only bearer token grant
• Chio already treats missing attestation freshness as a deny-or-downgrade condition under the transport rules

Required mitigations:

• App Attest assertions and Play Integrity tokens MUST bind to a fresh issuer challenge or nonce
• the mobile issuer MUST reject stale, reused, or audience-mismatched attestation evidence fail-closed
• verifier fixtures SHOULD include replayed assertion and wrong-audience cases

Residual risk: platform attestation services cannot compensate for deployments that reuse broad audiences or keep replay nonce state only in a volatile local process.

Device Key Extraction

Attack: a compromised mobile process exports or misclassifies signing material that should remain bound to Secure Enclave, StrongBox, or TEE custody.

Existing controls:

• Chio mobile receipts are signed artifacts, and capability issuance can bind the audience to a device-attested key id
• the mobile kernel adapter keeps the JSON-in / JSON-out boundary separate from platform keystore implementation details

Required mitigations:

• iOS signing keys MUST remain in Secure Enclave or App Attest managed storage
• Android signing keys SHOULD use StrongBox on API 28+ and MUST mark TEE fallback explicitly on API 26-27
• mobile receipts MUST NOT rely on exportable long-lived signing seeds when a hardware-backed key is available

Residual risk: a fully compromised mobile OS can still manipulate UI, timing, and network behavior; the mobile custody claim is scoped to non-exportability and evidence binding, not total device-compromise prevention.

Play Integrity Token Replay

Attack: an attacker reuses a stale Google Play Integrity JWS to mint a fresh mobile capability after the original issuer nonce should have expired or been consumed.

Existing controls:

• Play Integrity is only an input to issuer-side minting and does not authorize tool calls by itself
• Chio's custody nonce store already has replay-resistant patterns from the passkey issuer surface

Required mitigations:

• the Play Integrity verifier MUST assert nonce equality against issuer-generated nonce state
• accepted Play Integrity nonces MUST be consumed once and rejected on duplicate presentation
• stale, wrong-nonce, and wrong-package JWS fixtures SHOULD be part of the mobile verifier corpus

Residual risk: Google-signed verdict freshness still depends on issuer nonce durability and clock policy; weak deployments can make valid tokens replayable by accepting stale nonce state.

Transport Security Requirements

Transport requirements are interface-specific. The matrix below defines the minimum shipped rules.

Additional Rules

• Attestation alone never substitutes for sender proof. If a profile binds an attestation digest, it MUST still pair that with DPoP or mTLS continuity over the same request.
• A deployment MUST NOT claim impersonation resistance, confidentiality, or replay resistance when it intentionally operates on plaintext remote transports.
• If a required transport security property is missing, the implementation MUST deny the request or restrict the deployment to an explicitly local development posture.

Implementation Guidance

• Same-host development can rely on loopback or UDS transport, but that is a deployment carve-out, not a general weakening of the production rules.
• Cross-host deployments should treat sender constraint and transport authentication as complementary: transport authentication proves the service identity; DPoP proves caller possession of the sender-bound key.
• Tool servers are not made safe by transport security alone. Chio mediation protects admission and auditability, but 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 minimum threat set, the mitigation and residual-risk mapping for each threat, and the transport requirements per interface. Implementations and future standards work SHOULD treat that file as the stable registry.

Related

• Trust Model
• Formal Assumptions
• Fail-Closed
• Wire Protocol