---
title: "Security"
description: "Where to report an HCP vulnerability, which threats the protocol defends against, what it guarantees, what it leaves to runtimes and each role's rules."
canonical: https://harnesscontextprotocol.io/docs/community/security
---

# Security

> Where to report an HCP vulnerability, which threats the protocol defends against, what it guarantees, what it leaves to runtimes and each role's rules.

Report a vulnerability privately to `security@harnesscontextprotocol.io`, never
in a public issue. The protocol fixes the guarantees below, which every
conforming runtime must implement, and leaves the rest, such as isolation
strength and credential storage, to the runtime. Pack authors, runtime builders
and hosts each have a short list of rules at the end.

## Reporting

The private address covers the specification, the reference SDK, the CLI and
the gold packs. Send the affected repository and version, a reproduction, the
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 days. Reporters are credited unless they ask otherwise.

Vulnerabilities in third-party runtimes and packs go to their maintainers, and
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.

### 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 one maps to a normative section that a conforming runtime must implement.

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

### 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 put each one 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, because reordering is the most common bug.
- Seed the allow-list from activated packs only, and never add `/usr/bin`.
- Log the audit tuple for every write before returning the result.
- Treat `native-local` as a per-machine trust decision that needs explicit
  configuration.
- Run the [conformance vectors](/docs/specification/conformance#145-vectors)
  in CI.

## Guidance for hosts

- Never execute `wrap.bin` yourself.
- Show `confirm` markers to the user, and do not let the model satisfy them on
  its own unless a policy permits it.
- Filter tools by grants before the model sees them.

## Advisories

No advisories have been published yet.

## Sitemap

- [Documentation](https://harnesscontextprotocol.io/docs)
- [Packs](https://harnesscontextprotocol.io/packs)
- [Glossary](https://harnesscontextprotocol.io/docs/reference/glossary)
- [llms.txt](https://harnesscontextprotocol.io/llms.txt)
- [llms-full.txt](https://harnesscontextprotocol.io/llms-full.txt)
- [OpenAPI](https://harnesscontextprotocol.io/openapi.json)
- [MCP](https://harnesscontextprotocol.io/mcp)