Skip to content

Repository navigation

Security: LLM-4-People/bridlewise-testing

Security

Report a vulnerability

SECURITY.md

Security policy

Warning

Bridlewise is an experimental developer preview. It is not security-audited, not production-ready, and must not be used with sensitive, proprietary, regulated or production codebases.

Supported versions

There are no supported production versions. main is the only development branch, and every release is a preview.

Reporting a vulnerability

Do not open a public issue with exploit details, credentials or private data.

Use GitHub's private vulnerability reporting:

https://github.com/LLM-4-People/bridlewise-testing/security/advisories/new

Include the affected revision, a minimal reproduction, the impact and any suggested fix. A confirmed report is handled in a private security advisory.

There is no incident-response team and no disclosure SLA. Reports are handled on a best-effort basis.

What the design attempts

  • Loopback API binding and a Host check.
  • HttpOnly sessions, a CSRF header on unsafe methods, scrypt password hashes and hashed session tokens.
  • AES-256-GCM field encryption at rest, with keys outside the checkout.
  • Redaction at the model-egress choke point and before user display.
  • A governed tool surface with typed refusals.
  • Landlock confinement for spawned commands and stdio MCP servers on Linux.
  • An append-only, hash-chained timeline.

What it does not provide

  • An audit, penetration test or formal threat-model review.
  • Multi-tenant hardening or a production deployment model.
  • Network confinement.
  • Complete secret or PII detection.
  • A guarantee that every destructive action is reversible.
  • Support or an SLA.

Contributions from forks

Pull-request CI runs on the pull_request event only, with a read-only token and no secrets, for every author alike; a first-time contributor's first run waits for a maintainer's approval. No workflow runs contributor code with write access or secrets.

Secrets and private data

  • Never commit provider keys, database keys, .env files, tokens, private keys or local databases.
  • Keep the database key home outside the repository.
  • Redact logs, absolute paths, project names and personal data before opening an issue.
  • If a credential was exposed, revoke and rotate it first; rewriting history does not undo exposure.

Safety expectation

Use a disposable copy. Assume data loss is possible. Inspect the run record before trusting an outcome. Do not point the harness at a codebase you cannot afford to lose or disclose.

There aren't any published security advisories