# Security Policy

## Supported code

Security fixes are made against the current `main` branch. Historical experiment, diagnostic and development branches are not supported release channels unless a document explicitly says otherwise.

## Reporting security issues

Report suspected vulnerabilities privately to the repository owner. Do not publish credentials, console identifiers, account tokens, private network details, personal data, proprietary dumps, signing material or exploit-sensitive evidence in a public issue.

A useful report includes the affected component and commit, minimal reproduction steps, expected and observed behaviour, impact, and whether the issue crosses an authentication, CSRF, filesystem, process, package, console, deployment or secret-handling boundary.

## Security boundaries

Chimera deliberately separates observation, staging, installation, launch, trophy/save operations and deployment evidence. Contributions must preserve fail-closed capability checks, exact confirmations, provenance, backup/rollback requirements, path containment, secret redaction and the rule that acknowledgement is never equivalent to verified installation or launch.

Never commit live `.env` files, tokens, account sessions, private keys, console credentials, deployment credentials or private operational evidence. Use documented environment variables or the configured secret mechanism.

## Disclosure

Coordinate remediation and disclosure with the repository owner before publishing technical details that would materially increase exploitation risk.