Atlas is pre-1.0. Security fixes are applied to the main branch; there is no long-term support branch yet.

Please do not open a public issue, pull request, or discussion for a security vulnerability.

Instead, use GitHub's private vulnerability reporting for this repository: open the Security tab and choose Report a vulnerability. This creates a private advisory visible only to you and the maintainers — no public disclosure and no email address to expose.

Maintainers: if that option isn't visible, enable it under Settings → Code security and analysis → Private vulnerability reporting.

Please include:

• a description of the issue and its impact,
• the affected component (e.g. atlas/guardrails/, atlas/api/), and
• steps to reproduce or a proof of concept.

We aim to acknowledge reports within a few business days and will keep you updated as we investigate. We support coordinated disclosure and will credit reporters who wish to be named. We will not pursue legal action against good-faith research that respects this policy.

Atlas is a framework, not a hosted service. A few things are intentional and are not vulnerabilities on their own:

• The bundled offline defaults (MockProvider, HashingEmbedder, InMemoryVectorStore) are for local development and are not meant for production use.
• Example credentials and DSNs in .env.example and infra/ are placeholders.
• The guardrail heuristics (atlas/guardrails/) are defense-in-depth, not a guarantee; the red-team suite in data/redteam/ documents known limitations.

The API ships with no authentication layer of its own — put it behind your gateway/ingress auth. Two ingestion behaviours deserve explicit configuration on any shared deployment:

• Filesystem ingestion — POST /ingest {"paths": [...]} reads local files as a dev convenience. Set ATLAS_API__ALLOW_PATH_INGEST=false in production so API callers cannot read server files into the knowledge base; URL, text, and document ingestion keep working.
• URL fetching (SSRF surface) — ingesting URLs (from the API or the Go worker) fetches attacker-suppliable addresses by design. Run the fetching component in a network segment that cannot reach internal metadata services or private ranges, or front it with an egress proxy/allowlist.

Reports about weaknesses in the guardrails that let a realistic attack through are still very welcome — that is exactly what the red-team harness exists to surface.