Phantom Adversarial is an AI security research tool. We take the security of this project seriously. This document outlines how to report vulnerabilities in Phantom Adversarial itself, and reiterates the ethical use requirements for the tool.

Do not report security vulnerabilities via GitHub Issues.

To report a vulnerability in the Phantom Adversarial codebase (e.g., a bug that could expose users' API keys, compromise evidence chain of custody, allow arbitrary code execution via malicious campaign config files, etc.):

1. Email: security@vibe.coding.inc
2. Subject line: [SECURITY] Phantom Adversarial — [brief description]
3. PGP encryption preferred — key fingerprint available at keys.openpgp.org

Include in your report:

• Phantom Adversarial version affected
• Description of the vulnerability and its potential impact
• Steps to reproduce (as detailed as possible)
• Any proof-of-concept code (PoC)
• Suggested remediation if known

What to expect:

• Acknowledgment within 48 hours
• Assessment and severity classification within 5 business days
• Fix timeline communicated within 10 business days
• Credit in the CHANGELOG and release notes (unless you prefer anonymity)

Disclosure policy:

• We follow a 90-day coordinated disclosure timeline from acknowledgment to public release
• Critical vulnerabilities may be disclosed faster if a patch is available
• We will not pursue legal action against researchers who follow responsible disclosure

If you discover AI model or system vulnerabilities using Phantom Adversarial during authorized testing, follow the disclosure protocol described in docs/methodology/METHODOLOGY-v2.md — specifically Section 8 (Responsible Disclosure).

Severity-based timelines:

• Critical: vendor notification within 24 hours; 45-day embargo
• High: vendor notification within 72 hours; 60-day embargo
• Medium: vendor notification within 7 days; 90-day embargo

Key AI provider security contacts:

Phantom Adversarial is a dual-use security research tool. Its intended purpose is to help defenders identify and remediate AI security vulnerabilities before malicious actors exploit them.

• Test AI systems you own or operate
• Test AI systems under explicit written authorization from the system owner
• Conduct academic research with appropriate IRB approval and ethical safeguards
• Submit findings to vendor bug bounty programs within their defined scope
• Build safety evaluation pipelines for AI systems you develop or deploy
• Conduct red team exercises for authorized clients

• Test any AI system without explicit authorization
• Generate and distribute actual harmful content (even in a "testing" context)
• Attempt to extract CBRN (chemical, biological, radiological, nuclear) weapon synthesis information
• Generate, distribute, or retain CSAM (child sexual abuse material) under any circumstances
• Conduct denial-of-service attacks against AI APIs or services
• Bypass access controls on systems you are not authorized to test
• Resell or redistribute adversarial prompts generated by this tool for malicious purposes

Unauthorized use of this tool against AI systems may violate:

• Computer Fraud and Abuse Act (CFAA), 18 U.S.C. § 1030
• EU Directive on Attacks Against Information Systems (2013/40/EU)
• UK Computer Misuse Act 1990
• Equivalent national and international laws

The authors of Phantom Adversarial assume no liability for unauthorized or malicious use. By using this software, you accept full legal responsibility for your use of it.

1. API Key Exposure: Phantom Adversarial requires API keys stored in .env. Never commit .env to version control. Use the provided .gitignore. For CI/CD, use secrets management (GitHub Secrets, Vault, AWS Secrets Manager).

2. Evidence Files: By default, campaign results and evidence files are stored locally unencrypted. Enable PHANTOM_ENCRYPT_EVIDENCE=true in .env for client engagements and sensitive research.

3. Harmful Content in Results: Campaign results may contain model outputs that include harmful content. These files should be treated as sensitive and stored accordingly. Do not push results directories to public repositories.

4. Prompt Injection in Config Files: Maliciously crafted YAML config files could attempt to inject adversarial content. Only use configuration files from trusted sources.

5. LLM-as-Judge Evaluation: When using judge-gpt4o or judge-claude evaluators, prompt injection payloads are sent to external APIs. Ensure your API usage complies with provider terms of service.