This repository contains the source, documentation and tooling for the Genesis Code Protocol (GCP)—an AI‑native framework designed to orchestrate complex, multi‑phase invention processes. Because GCP can execute code, attach external modules and interface with powerful language models, ensuring the security of both the tooling and the protocol is critical. This policy explains which versions receive security updates, how to report vulnerabilities and what to expect from the maintainer.

We support security fixes for the most recent major release (v50) and the immediately preceding release (v49). Earlier versions are archived for historical reference and do not receive security patches. Users should upgrade to a supported version to benefit from the latest security improvements.

We are particularly interested in reports of vulnerabilities that could lead to:

• Remote code execution or arbitrary code injection via the CLI, runner attachments or cartridge interfaces.
• Prompt injection or jailbreak exploits that compromise the integrity of the protocol by exfiltrating secrets, bypassing gates or undermining safety constraints.
• Privilege escalation or unauthorized access to tools, secrets or APIs used by the protocol (e.g., obtaining credentials from environment variables or from the LLM’s state).
• Data privacy breaches, including leakage of personally identifiable information (PII) or violation of the Data Rights phase in GCP V50.
• Tampering with ledgers or evidence bundles, such as forging DECISION_LEDGER entries or altering provenance metadata.

Vulnerabilities solely affecting older, unsupported versions (v48 or earlier) are not prioritized but may still be acknowledged.

Please report suspected vulnerabilities privately to [email protected] or via the GitHub Security Advisories form at https://github.com/lazyxeon/Genesis-Code-Protocol/security/advisories/new. We will acknowledge reports within 3 business days and aim to resolve confirmed issues within 60 days.

To report a vulnerability, please use the private reporting channel so we can assess and address the issue before public disclosure:

1. Email [email protected] with a detailed description of the issue. Include:
   • Steps to reproduce (code snippets, input prompts, commands).
   • Affected version(s) and environment (e.g., OS, Python version, LLM provider).
   • Any proof‑of‑concept exploit or log output demonstrating the vulnerability.
2. Alternatively, create a private GitHub Security Advisory from the repository’s Security tab. This sends your report to the maintainers without exposing it publicly.

Please do not open public issues or pull requests for security vulnerabilities. We use private channels to prevent exploitation while the fix is being developed.

We follow a policy of responsible, coordinated disclosure:

• We will acknowledge your report within 3 business days.
• We aim to investigate, patch and release a fix within 60 days of acknowledging a valid issue. Complex vulnerabilities may require more time; we will communicate expected timelines.
• We may request additional information or environment details to reproduce the issue.
• After a fix is released, we will credit the reporter (if consent is given) in the release notes. We prefer to coordinate public disclosure after users have had a reasonable opportunity to upgrade.

While we strive to secure the protocol, users can reduce risk by following these guidelines when running GCP:

1. Use supported versions: Always run the latest supported release (v50) and apply patches promptly.
2. Isolate execution environments: Run CLI tools and code generated by the LLM in sandboxed environments (e.g., containers or virtual machines). Avoid executing generated code on production systems without review.
3. Restrict credentials: Provide only the minimal secrets or API keys needed for your run. Do not embed secrets in prompts or commit them to version control. GCP’s Data Rights phase helps detect PII—follow its recommendations.
4. Beware of prompt injection: When using external research or user‑supplied context, monitor for instructions that may alter the protocol’s behavior (e.g., “ignore safety” or “delete logs”). Stop the run and investigate if you suspect injection.
5. Inspect attachments: Runners and cartridges come from third‑party sources. Review their code and ensure they are trustworthy before attaching them to a session.
6. Maintain dependencies: Keep your Python environment and dependencies up to date. We publish an official requirements.txt; avoid introducing unvetted packages or running pip install within LLM code interpreters.
7. Use risk tiers appropriately: Select an appropriate risk tier (R1–R3) based on your tolerance. Higher tiers activate additional guards and compliance checks.

Questions related to this security policy or other security concerns? Email us at [email protected]. For general questions, please use the discussion forum or the issue tracker. Thank you for helping keep GCP safe and trustworthy.