Security

Synopsis

The model is one JSON document with schema id chio.threat-model.v1, last updated 2026-05-02. It covers the agent-kernel-tool trust boundary across 4 boundary surfaces and states 20 threats. Each threat carries an id, a name, the surfaces it reaches, its mitigations, and its residualRisk. The transport requirements hold 4 profiles plus the attestation and failure rules.

{
  "schema": "chio.threat-model.v1",
  "updatedAt": "2026-05-02",
  "boundary": {
    "focus": "agent-kernel-tool trust boundary",
    "surfaces": [4 surface ids],
    "assets": [7 asset ids]
  },
  "threats": [
    {
      "id": "capability_token_theft",
      "name": "…",
      "surfaces": ["hosted_mcp", "native_chio", "trust_control"],
      "mitigations": [{ "control": "…", "status": "…" }],
      "residualRisk": "…"
    }
    … 19 more
  ],
  "transportRequirements": { "profiles": [4 profiles], … }
}

Boundary

The security boundary is the path from one caller with authority material to one mediated tool execution. It runs through five steps:

1. Capability issuance or continuation on the trust control service.
2. Hosted or native delivery of that authority to the kernel.
3. Kernel admission and policy evaluation.
4. Transport from the kernel to the selected tool server.
5. Receipt generation and return.

Out of scope

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

Primary assets

The boundary protects these assets: capability_tokens, delegation_state, session_sender_binding, kernel_authenticity, tool_execution_confinement, receipts, runtime_availability.

It spans these surfaces: native_chio, hosted_mcp, trust_control, kernel_to_tool.

Threat register

Each entry gives the attack, the surfaces it reaches, the controls that apply at the runtime boundary, and the risk that remains under them. Search by threat name, surface identifier, or control; every entry keeps a stable link.

Capability token theft

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

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

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

native_channel_replay

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

resource_exhaustion_dos

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

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: Authority must be verified at the entry point accepting the delegation. Offline structural checks and unsigned delegation metadata do not establish request authorization, revocation freshness, or authenticated issuer trust.

SSRF via HTTP substrate

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

pii_phi_exposure

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

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

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

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

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 use isolated linear memory and only configured host imports; they receive no ambient host filesystem, network, or kernel-state authority.

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

pq_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

Controls:

• Hybrid signatures pair a supported classical algorithm with ML-DSA-65 under an algorithm-tagged encoding.
• Verification with a configured cryptographic floor rejects signature material outside that profile before accepting the artifact.

Residual risk: The verifier must apply the intended cryptographic floor. Classical compatibility remains a distinct policy choice; an algorithm hint alone does not enforce post-quantum protection.

TEE quote forgery or misbinding

tee_quote_forgery

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

Surfaces: hosted_mcp, native_chio

Controls:

• Runtime attestation verification checks platform evidence against operator-configured trust material and accepted measurements.
• Quote and report-data bindings connect the attested runtime to its signing identity; authenticated transport and sender continuity remain separate checks.

Residual risk: Attestation depends on platform trust roots, measurement policy, freshness and revocation state. A valid quote does not authorize a tool call or make an untrusted measurement acceptable.

Passkey credential theft

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

Controls:

• A server-side issuer verifies WebAuthn assertions against the relying party, origin and fresh challenge before issuing a capability.
• Credential-bound capabilities have bounded lifetimes and revocation checks; durable nonce state prevents repeated assertion redemption.

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

audience_confusion

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

Surfaces: hosted_mcp, native_chio, trust_control

Controls:

• Passkey capability envelopes bind an explicit audience and scope into the signed record.
• The custody verifier compares the signed audience with its configured audience and rejects a mismatch.

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

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

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

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

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

Each surface has one transport profile: the value for TLS, mTLS, and DPoP, and the posture a deployment falls to when the requirement is unmet.

Additional rules

Two 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. The carve-out applies to development and leaves the production rules unchanged.
• Cross-host deployments pair sender constraint with transport authentication: transport authentication proves the service identity, and DPoP proves the caller possesses the sender-bound key.
• Chio mediation protects admission and auditability. Host-level sandboxing of the tool server is the operator's responsibility, under the mediation boundary every deployment shares.

Machine-readable register

spec/security/chio-threat-model.v1.json is the normative machine-readable form 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 file as the stable registry.

Threat identifiers, attacks, surfaces, and transport profiles render from the register. The control descriptions also carry the runtime contracts for hybrid cryptography, attestation, passkey issuance, and audience verification.