Vulnerability disclosure

Reporting

Email security@z4j.com. PGP key: see SECURITY.md in the repo.

Include:

• Description of the issue.
• Steps to reproduce (minimal repro preferred).
• Affected version(s).
• Your contact info for follow-up.

Please do not

• File a public GitHub issue.
• Post to public mailing lists / chat rooms / social before we’ve had time to respond.
• Demonstrate the issue against systems you don’t own.

Safe harbor

We follow the disclose.io baseline. You may research in good faith - we won’t pursue legal action for:

• Testing on your own self-hosted brain.
• Testing against our public dev/demo instance (if/when we host one).
• Accidental access to data during good-faith research - with prompt disclosure.

We will not take legal action against researchers who:

• Stop testing on discovery.
• Don’t exfiltrate data beyond what’s needed to prove the bug.
• Don’t disclose publicly before our patch is available.

Response timeline

Event	Target
Acknowledge receipt	48 hours
Initial triage	5 business days
Patch for critical	7 days from triage
Patch for high	30 days
Patch for medium/low	90 days
Coordinated public disclosure	90 days from patch, or immediate if already disclosed

Credit

We publish a SECURITY_HALL_OF_FAME.md in the repo, with researcher name (or pseudonym) and issue summary. Bug bounty is not currently offered; happy to recognize publicly and in release notes.

Scope

In scope:

• Brain (z4j).
• Agent packages (z4j-*).
• Wire protocol.

Out of scope:

• Third-party queue engines (report to them).
• Third-party infra (Postgres, Redis, etc.) - report upstream.
• Denial-of-service via resource exhaustion on single-tenant self-hosted brain (operator owns resourcing).

Past findings

Internal audit rounds prior to public release found and closed issues across authentication, session handling, and event redaction. Full details in docs/SECURITY_AUDIT_PRERELEASE.md (intentionally public for transparency).