This repository is currently pre-1.0. Security fixes target the latest main branch unless a release branch is created later.
Please do not post exploit details, real customer data, or secrets in a public issue.
If GitHub private vulnerability reporting is enabled for this repository, use that first. Otherwise, open a minimal public issue that says a security report is available, without sensitive details, and the maintainer will coordinate a private channel.
This project should never contain real customer data. Reports, fixtures, tests, screenshots, logs, and demo files must use fake data only.
Examples of data that must not be committed:
- real names, phone numbers, emails, addresses, order IDs, payment records, booking records, message screenshots, API keys, OAuth tokens, cookies, or session files.
Security-sensitive changes should preserve these boundaries:
- privacy filtering before any LLM call;
- no inherited API keys or access tokens leaked into child processes;
- approved-knowledge grounding for auto-send replies;
- staff review for risky or uncertain messages;
- deterministic blocks for medical, legal, financial, payment, refund, booking, delivery, and privacy violations.
The same boundaries apply when this project's patterns are reused for AI-assisted
repository maintenance (PR review, issue triage, release checks). See
maintainer-automation/ and the adversarial cases in
red-team-cases/oss-maintainer-security.md.
- LLM outputs must not auto-merge, auto-send, publish a release, or close issues; those actions stay behind a human maintainer.
- Secrets and customer/personal data must be filtered out of diffs, issues, and fixtures before any model call; a detected secret or PII blocks automation.
- High-risk pull requests, releases, and issues (CI, deploy, lockfile, or security-policy changes; possible data loss) require human review.
- Deterministic checks run in front of LLM workflows and cannot be disabled by text inside a PR, issue, or diff (prompt-injection resistance).