PHARN is an audit-grade methodology — taking security seriously is part of the brand, not an afterthought. We welcome coordinated disclosure of any vulnerability in this repository.

This repository is PHARN-OSS — the audit-grade methodology itself, early-stage and in active development. Its security surface is small by design: four trusted markdown spec docs, three slash commands, one PreToolUse write-guard hook (.claude/hooks/protect-trusted-paths.cjs), and one deterministic validator (floor/validate.mjs). No transpile step, no bundled runtime dependencies, no network egress, no secrets — stdlib-only Node (.cjs/.mjs) plus markdown.

PHARN's security model (THREAT-MODEL.md, threat model B) starts from one axiom: prompt injection is not solved. An agent that must read hostile context — code under review, fetched docs, accumulated memory, another model's output — cannot be made to reliably ignore instructions embedded in that content. Defense therefore rests on the deterministic floor (hooks, content-hashes, enum/regex checks that do not depend on model judgment), not on "the model will notice the attack." The security-relevant surfaces of this repo follow from that shape.

We patch security issues against the latest released version only. The current version is recorded in SKILLS_VERSION and package.json.

Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.

Instead, report privately through one of these channels:

1. GitHub Security Advisories (preferred) — use private vulnerability reporting to open a confidential report. No email is exposed and the report stays embargoed until a fix ships.
2. Email — if you cannot use GitHub advisories, email support@pharn.dev with [PHARN SECURITY] in the subject.

Please include as much of the following as you can — it speeds up triage:

• The type of issue (e.g. prompt injection, write-guard bypass, a floor false-negative, path traversal).
• Full path(s) of the file(s) involved.
• The location of the affected code (branch/commit, or a direct URL).
• Step-by-step reproduction instructions, and any configuration required to reproduce.
• Proof-of-concept, if you have one.
• Impact — how an attacker might exploit the issue.

• Initial acknowledgement — within 3 business days of your report.
• Preliminary assessment and severity — within 7 days.
• Resolution target — critical issues within 30 days; other issues within 90 days.

We will keep you informed throughout, coordinate disclosure timing with you, and credit you in the advisory unless you ask to remain anonymous.

• Prompt injection in the trusted spec docs, the /plan /build /review commands, or a capability — content that bypasses the constitution, or launders untrusted data into a guaranteed decision (the trust-fence; THREAT-MODEL.md §5).
• Write-guard bypass — any input that makes protect-trusted-paths.cjs allow a Write/Edit it should deny to a trusted doc (e.g. a path-normalization or path-traversal gap; fix #2, THREAT-MODEL.md §4).
• Floor false-negative — a logic flaw in floor/validate.mjs that reports GREEN for input violating an invariant it claims to enforce (a false guarantee — the exact P0 failure mode).
• Any other defect in the executable floor (the .cjs hook or the .mjs validator) that undermines a guarantee the docs claim.

• Vulnerabilities in a user's own project that adopts the methodology — that is threat model A, the methodology's job rather than this repo's.
• Vulnerabilities in third-party AI providers (Claude, or any model you drive the commands with).
• Vulnerabilities in dev-only devDependencies (ESLint, Prettier, markdownlint) — report those upstream.
• Social engineering, or attacks requiring physical access to a maintainer's machine.
• Denial of service that does not exploit a specific vulnerability.

The write-guard hook and the floor are defense-in-depth, not a guarantee of correctness. When using this repo:

1. Keep the write-guard hook wired in .claude/settings.json — trust-by-location is only real if the trusted docs are write-protected at the floor.
2. Review what the agent produces before you run or merge it — that is the methodology's whole point.
3. Do not over-trust GREEN. The floor guarantees structural shape, never that the architecture or content is correct (see floor/README.md, "Honest scope"). Correctness is /review's advisory job, and yours.

We appreciate the security research community. Anyone who reports a valid issue in good faith will be credited in the resulting advisory, unless they ask to remain anonymous.

Thank you for helping keep PHARN and its users safe.