Security

The standalone threat model for the Chio agent-kernel-tool trust boundary. It complements the wire protocol (which defines message shapes and lifecycle flows) by defining the attacks those flows must resist and the minimum transport security posture required for safe deployment.

Source

This page normatively reflects spec/SECURITY.md in the chio repository. Status: Normative shipped surface. Version 1.0. The machine-readable companion artifact 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 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 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.

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.

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.

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

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

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

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

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

Behavioral Sequence Attacks

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

Transport Security Requirements

Transport requirements are surface-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 production-grade 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 surface. Implementations and future standards work SHOULD treat that artifact as the stable registry.

Related

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