Security

The HCP threat model, what the protocol guarantees and what it leaves to runtimes, and how to report a vulnerability.

Reporting

Report vulnerabilities in the specification, the reference SDK, the CLI, or the gold packs privately. Do not open a public issue.

Email: security@harnesscontextprotocol.io
Include: affected repository and version, reproduction, impact, and whether you believe it is a specification flaw or an implementation bug.

We acknowledge within three business days and aim to publish a fix or an advisory within ninety. Reporters are credited unless they ask otherwise.

Vulnerabilities in third-party runtimes and packs should go to their maintainers; if the root cause is in the protocol, copy us.

Threat model

HCP sits between an agent, whose input is untrusted and possibly prompt-injected, and real-world effects such as money, messages, files, and credentials. The protocol is designed for this position.

Adversaries

Adversary	Goal
Injected agent	Make the harness run a write it should not, or run it without confirmation
Malicious pack	Exfiltrate credentials; run arbitrary binaries; escape the working directory
Compromised host	Spawn binaries directly, bypassing the runtime
Tenant confusion	Act in another tenant or project by argument
Sense abuse	Use a trigger to cause execution or to leak data

Guarantees the protocol makes

Each maps to a normative section a conforming runtime must implement.

Guarantee	Section
No command runs without a Policy entry	§6.3
Writes are classified and gated; `confirm` is enforced by the runtime, not the model	§4.5
Grants are checked before anything executes; fail closed	§9.4 and §9.5
Tenant from session, never from args; `brain` requires project membership	§9.2
Packs carry no credentials; mint at exec; no ambient fallback	§8
Binaries are allow-listed; cwd is jailed; no `PATH` resolution	§10.2
Sense cannot execute, mint, or mutate	§7.2
Hosts route through a runtime; they do not spawn	§12.2
Every write is attributed: Principal + tenant + Binding identity + command	§9.6

What the protocol does not guarantee

Left to runtimes	Notes
Process isolation strength	Allow-list + jail is the floor; containers and microVMs are conforming and encouraged
Network egress control	Runtime profile
Credential storage	The hub's problem; the protocol only says "not in the pack"
Session authentication	How a Principal is established
Rate limiting and quotas	Runtime
Wrapped CLI behaviour	A pack cannot make a hostile binary safe; the allow-list decides what may run
Prompt injection in Skills	`HARNESS.md` is text the model reads. Runtimes should lint for instruction-like content that contradicts Policy; hosts should present Skills as data

Guidance for pack authors

Keep writes few and each behind confirm.
Never put a credential, or a placeholder that looks like one, in any of the three files.
Do not teach the agent to bypass gates ("always pass --confirm").
Health commands must not mint.

Guidance for runtime builders

Implement the pipeline order exactly. Reordering is the most common bug.
Seed the allow-list from activated packs only. Do not add /usr/bin.
Log the audit tuple for every write before returning the result.
Treat native-local as a per-machine trust decision requiring explicit configuration.
Run the conformance vectors in CI.

Guidance for hosts

Never execute wrap.bin yourself.
Show confirm markers to the user; do not let the model auto-satisfy them without a policy that permits it.
Filter tools by grants before the model sees them.

Advisories

None published.

Security

On this page