Capability Host Protocol — Docs
Reference

CHP v0.1 Threat Model

The v0.1 threat model and security posture.

Synced from chp-core/docs/security/threat-model-v0.1.md.

Scope

This threat model covers CHP v0.1 local hosts, schemas, local evidence stores, examples, and conformance. It does not cover hosted multi-tenant services or production SaaS controls.

Assets

  • Capability descriptors
  • Invocation envelopes
  • Correlation IDs
  • Evidence events
  • Local evidence store files
  • Subject metadata
  • Capability input and output data

Trust Boundaries

  • Caller to capability host
  • Capability handler to evidence store
  • Host process to local filesystem
  • Optional bridge surfaces, such as MCP-like tools or agent loops

Threats And Mitigations

Tampering with evidence:

  • v0.1 requires append-only store behavior.
  • The reference SQLite store inserts evidence events and never replaces existing events.
  • This is not tamper-proof. Cryptographic sealing is deferred.

Correlation loss or overwrite:

  • Hosts must preserve caller-supplied correlation IDs.
  • Hosts must generate IDs only when missing.
  • Evidence and results must include the final correlation context.

Sensitive input leakage:

  • Hosts should not copy raw invocation payloads into evidence by default.
  • The reference host records capability URI and explicit redacted handler emissions.
  • Examples avoid secrets and external credentials.

Hidden failures or denials:

  • Failed executions must emit execution_failed.
  • Denied executions must emit execution_denied.
  • Unsupported capability and unsupported mode are denial cases.

Misleading evidence:

  • Evidence contains host_id, invocation_id, capability_id, timestamp, sequence, and correlation.
  • v0.1 does not prove that a host is honest. It only standardizes the structure a host must emit.

Replay confusion:

  • Replay is scoped by correlation ID and ordered by local append sequence.
  • Cross-host ordering is not guaranteed in v0.1.

Bridge abuse:

  • MCP-style or agent tool bridges must validate inputs and avoid blindly trusting tool descriptions.
  • Bridge packages should preserve CHP evidence even when the bridged protocol has different error semantics.

Non-Goals

  • Tamper-evident ledgers
  • Remote attestation
  • Enterprise identity and RBAC
  • Long-term retention policy
  • Full policy evaluation
  • Secrets scanning
  • Multi-host causal total ordering

Required Launch Checks

  • Evidence store uses append-only writes.
  • Correlation IDs are preserved in tests.
  • Failure and denial events are covered by conformance.
  • Demo payloads do not include secrets.
  • Docs clearly state local evidence is not a compliance system by itself.

On this page