Security

• 1. Reporting
• 2. What to include
• 3. What to expect
• 4. Safe harbour
• 5. Scope
• 6. How credentials are handled
• 7. If you leak a key
• 8. Probe content
• 9. security.txt

1. Reporting

Report security issues privately, through GitHub private vulnerability reporting. That channel is preferred because it keeps the report, the fix and the advisory in one place, and it lets us credit you when it is published.

If GitHub is not available to you, write to support@foxxception.com with “security” in the subject line. Please do not open a public issue, and please do not post a working exploit publicly before a fix exists.

2. What to include

• the version — halligan --version — and how you installed it;
• what an attacker gets out of it, in one sentence;
• reproduction steps, or a minimal config that triggers it;
• any log or artifact that shows the behaviour, with your own credentials removed.

3. What to expect

We aim to acknowledge a report within seven days, to confirm or reject it with reasoning once we have reproduced it, and to keep you updated while a fix is in progress. When it ships we publish a GitHub advisory and credit you by the name you choose, or not at all if you prefer.

This is a small project, not a funded programme: there is no bug bounty and we cannot pay for reports. We would rather say that plainly than leave it implied.

4. Safe harbour

If you make a good-faith effort to follow this policy, we will treat your research as authorised: we will not bring a claim against you, we will not report you to law enforcement, and if a third party does bring a claim, we will make it known that you were acting within this policy.

Good faith means you:

• test only against your own installation of Halligan, or against halligan.dev itself — never against another user's systems;
• stop as soon as you have confirmed a vulnerability, and do not access, modify or exfiltrate data that is not yours;
• do not degrade the service for anyone else — no denial of service, no spam, no social engineering of maintainers or users;
• give us reasonable time to fix the issue before disclosing it. We suggest ninety days, and are happy to agree sooner for a low-severity finding.

5. Scope

Halligan is a testing harness that runs on your machine, so the realistic failure modes are narrow and specific:

• Credential leakage — a key reaching logs, a run artifact, a report, or a commit.
• Artifact exposure — sensitive conversation text escaping the redaction filter, or being written somewhere unexpected.
• Supply chain — a compromised dependency, or a tampered release artifact, reaching a user or a CI pipeline.
• Code execution — a suite, pack or target file that can execute code when it is only supposed to be parsed.
• halligan.dev — the site itself, though it is static files with no server-side logic and no user data.

Out of scope: a model saying something objectionable when you probe it — that is the tool working, and it belongs in a suite rather than a security report. Also out of scope are findings that require an attacker to already control your machine, missing hardening headers with no demonstrated impact, and reports produced by a scanner with no analysis attached. Vulnerabilities in GitHub, PyPI or Cloudflare belong with those vendors.

6. How credentials are handled

Halligan never takes an API key as a command-line argument, and never writes one to disk. Keys are read from the environment only, loaded from a gitignored .env at startup. Every run artifact passes through a redaction filter that masks known key formats — sk-, sk-ant-, AIza, bearer tokens, and generic high-entropy strings — before anything is written or printed.

Two independent scanners back that up: gitleaks runs in CI on every push and pull request across the full history and fails the build on a hit, and a pre-commit hook runs detect-secrets and gitleaks locally so a leak is caught before it reaches the remote. The repository security policy is canonical here and carries the setup commands.

7. If you leak a key

Order matters — revoke first, scrub second. A key pushed to a public repository should be assumed compromised the moment it lands; rewriting history does not unpublish it. Rotate at the provider, then remove it from history with git-filter-repo, then verify with a fresh gitleaks scan. The repository policy has the exact commands and the provider console links.

8. Probe content

The suites deliberately contain adversarial prompts — jailbreak attempts, emotional-coercion framings, and arguments for positions this project rejects. They are test inputs, not endorsements. Probes are data, never executable content, and the runner never replays a model's output into another model except as text to be graded.

9. security.txt

Machine-readable contact details are published at /.well-known/security.txt, per RFC 9116.