Do not open a public issue for a security problem.

Use GitHub's private vulnerability reporting — the Report a vulnerability button under Security → Advisories. That is the primary channel. It needs no key exchange, it reaches the maintainers listed in CODEOWNERS, and it gives you a private thread to follow the fix in.

If private reporting is unavailable to you, email <SET-A-MONITORED-ADDRESS> with [SECURITY] at the start of the subject line.

Anyone publishing this repository must replace that placeholder with a mailbox a human actually reads. It is deliberately left unfilled rather than pointed at a plausible-looking address, because an address that accepts mail and discards it is worse than none: the reporter believes they have filed something, the clock in the table below never starts, and the coordinated-disclosure commitment on this page is one nobody is in a position to keep.

A good vulnerability report includes:

• Description — what the vulnerability is and its potential impact.
• Steps to reproduce — a minimal, reliable reproduction path.
• Affected component — which service, file, or endpoint is affected.
• Suggested fix — optional, but appreciated.
• Your contact details — so we can keep you updated and credit you.

We follow a coordinated disclosure model. We will not take legal action against researchers who report vulnerabilities in good faith and follow this policy.

• The AtOM backend (backend/app/)
• The frontend (frontend/)
• Authentication and authorization logic
• LLM proxy and egress handling
• Sandbox isolation
• Any component in this repository

• The partner platform. It now lives in its own repository — report against https://github.com/npci/atom-partner-platform instead. Findings in the A2A wire code as it exists in this repository remain in scope here.
• Vulnerabilities in third-party dependencies (report those upstream)
• Social engineering attacks
• Physical security
• Denial-of-service attacks that require significant resources

Pre-1.0. Only main receives fixes. There is no long-term-support branch and no backporting.

This platform generates code, reviews it, drives git, and invokes builds. That is a larger blast radius than a typical web application, and the honest posture matters more than a reassuring one.

Specifications, uploaded documents and retrieved corpus chunks are untrusted input that reaches a model with tools. The platform wraps untrusted content and carries anti-injection instructions, and generated code is gated behind a build and a human-opened merge request.

None of that is a proof. A sufficiently clever document may still influence generated output. Treat every generated artifact as a proposal requiring human review, never as an authority, and do not ingest documents from sources you would not accept a pull request from.

• Code is generated, reviewed and built. It is not deployed — see the README's Capabilities and limits.
• Opening a merge request is human-gated.
• The first dispatch of a change to partners should be human-gated.

• Never expose the backends directly. They sit behind nginx, which terminates TLS and enforces mTLS and rate limits. Binding backend ports on a public interface bypasses all of it.
• Set every secret explicitly. SECRET_KEY, SESSION_JWT_SECRET and the database passwords have no safe defaults. Rotate the seeded admin passwords immediately.
• Keep CAPTCHA_ENABLED=true anywhere reachable by others; it is a real brute-force control.
• Redis backs login lockout, CAPTCHA answers and the JWT denylist. Losing Redis degrades those controls — run it with persistence and monitoring.
• Give the platform the narrowest git credentials that work. A token that can push to main is a token an injected prompt can try to use.

We would rather tell you than have you find out:

• This is pre-1.0 software that has not had an external security audit. Assume the controls described above are the ones we know about, not a complete set. Review it yourself before putting it anywhere internet-facing.
• Dependencies include a GPL-licensed transitive package and several LGPL-licensed ones — see THIRD-PARTY-NOTICES.md if that matters to you.

What the platform uses, what is quantum-resistant, and the trigger for revisiting. In short: the symmetric layer (HMAC-SHA256, bcrypt, HS256) needs no migration, TLS key exchange offers hybrid post-quantum X25519MLKEM768, and certificates remain RSA pending a CA that issues ML-DSA.

Dependencies are hash-locked — requirements.<arch>.lock installed with --require-hashes — so the supply-chain pin audit that used to be listed here as outstanding is done.

scripts/ci/hygiene-check.sh and .gitleaks.toml gate secrets, internal hostnames and confidential file types on every change. Run the hygiene check locally before opening a pull request:

bash scripts/ci/hygiene-check.sh

The gitleaks configuration carries custom rules for credential formats this project mints itself. Off-the-shelf scanning missed two real leaks here; if you add a new credential format, add a rule in the same commit.

This security policy is part of AtOM, licensed under the MIT License. See LICENSE for details.