Skip to content

Security: rx6ru/strata

Security

SECURITY.md

Security Policy

Supported versions

This project is pre-1.0. Security fixes target the default branch until a versioned release policy is published.

Reporting a vulnerability

Open a private security advisory on GitHub if the repository is hosted there, or contact the maintainers through the project's published private reporting channel. Do not open a public issue with exploit details, credentials, private hostnames, tokens, or sample secrets.

Default trust boundary

Strata intentionally ships without application-level user authentication. The default boundary is:

  • loopback binding for local development;
  • private network or VPN binding only when explicitly enabled;
  • SSH and host-level permissions for remote lifecycle control;
  • optional operator-provided reverse proxy or firewall for any broader exposure.

Do not publish the gateway directly on the public internet unless you add your own access control layer.

Secret handling

Strata must never persist secrets, credentials, tokens, passwords, private keys, cookies, environment-variable values, or provider settings. This applies to canonical records, derived indexes, logs, metrics, exports, restore bundles, fixtures, docs, and skill files.

The code includes pattern-based rejection for common secret-like material. Treat this as a guardrail, not a complete data-loss-prevention system. Agents and operators remain responsible for preflight review before writing durable memory.

Integrity handling

The canonical store uses append-only event records, content-addressed objects, idempotency keys, policy acknowledgements, schema checks, root manifests, and export checksums. If an integrity check fails, stop writes, preserve the data directory for investigation, and restore from the latest verified export on a clean destination.

Operational hardening

  • Bind to 127.0.0.1 unless a private-network deployment is intentional.
  • Restrict SSH access to operators and agents that are allowed to start or stop the service.
  • Use a constrained lifecycle wrapper for status, start, stop, and restart; do not grant arbitrary shell access for service management.
  • Store operational credentials outside the knowledge base with restrictive file permissions.
  • Keep backups encrypted at the storage layer if they leave the host.

There aren't any published security advisories