ATLAS is a local, single-user tool. All services (proxy, TUI, v3-service, geometric-lens, llama.cpp inference, sandbox) run as containers or processes on the operator's own machine and are intended to be reachable only from that machine (all published ports bind 127.0.0.1). There is no hosted component and no multi-tenant deployment target. Internal requests are additionally authenticated with a per-installation token (secrets/service-token, generated by atlas init, sent as Authorization: Bearer); installs that never ran atlas init fall back to unauthenticated localhost-only operation and atlas doctor warns.

Within that model:

• In scope: command injection or path traversal that lets model output escape the workspace or sandbox; container escapes from the sandbox; unverified downloads of model artifacts; secrets written to disk or logs; vulnerabilities in the install scripts.
• Out of scope: attacks that require the ATLAS ports to be exposed to an untrusted network (the compose files bind to localhost by default), multi-tenant isolation between users on the same machine, and prompt-injection making the model produce bad code (the sandbox and diff review exist so the operator can catch that before it lands).

Model-generated tool calls are treated as untrusted input: file edits are constrained to the workspace and shell commands run in the sandbox container (read-only rootfs, no-new-privileges, pids limit, /workspace as the only writable host mount). If you find a way around either boundary, that is exactly the kind of report we want.

Two current limits of that boundary, so reports can be calibrated against what is actually enforced: the sandbox has outbound network access by default (toolchains need to fetch dependencies) — ATLAS_SANDBOX_NET_INTERNAL=true cuts all egress from executed code; and the resource caps are host-sized only when atlas init writes them — a raw docker compose up without the wizard falls back to conservative caps (4g memory, 2 CPUs, 1024 PIDs), never unlimited.

Model-authored commands from a newly-opened repository are untrusted content. ATLAS_TRUST_MODE makes the execution decision explicit — set it in .env; compose forwards it to the proxy container:

• untrusted — command execution is refused (run_command and run_background); no repository commands run.
• trusted (default) — commands run only in the isolated sandbox container (non-root, cap_drop ALL, resource-capped).
• fully-trusted — additionally permits host execution (ATLAS_VERIFY_IN=host), dropping the container backstop; for working codebases that depend on host state, chosen deliberately.

Under trusted, a host-execution request is downgraded to the sandbox rather than silently honored, so the trust level can't be escalated by a stray ATLAS_VERIFY_IN=host. A raw docker compose up (no wizard) runs the sandbox with conservative memory/CPU/PID caps, never unlimited.

Two defaults reduce accidental data exposure:

Sensitive-file exclusion — the agent's read tools refuse known credential-bearing files (.env and variants, .netrc, .npmrc, .pypirc, key files, SSH/AWS/kube/docker credential stores, secrets/service-token, secrets/api-keys.json) so their contents never enter model context, session files, or lens training samples by default. A user who knows a specific file is non-sensitive can include it explicitly by setting ATLAS_ALLOW_CREDENTIAL_READS=1 on the proxy (the refusal message says exactly this). .env.example stays readable — it's a template.

Private-value filtering — log output across all services passes through a shared filter that masks credential-shaped values (assignments with secret-like key names, bearer headers, URL passwords, private-key blocks) with [FILTERED] before serialization. The pattern spec is pinned by a synthetic fixture corpus (tests/fixtures/private_value_fixtures.json) that every implementation must pass (Go: proxy/private_values.go; Python: three byte-identical copies enforced by tests/contracts/test_private_value_filtering.py). Filtering is a backstop for accidents, not a guarantee against adversarial encoding; the exclusion rule above is the primary control.

Please report vulnerabilities privately via GitHub Security Advisories rather than opening a public issue.

Include what you can of: the affected component (proxy, TUI, CLI, v3-service, geometric-lens, sandbox, install scripts), reproduction steps, and the impact under the single-user local model above.

You can expect an acknowledgment within a week. Fixes for confirmed vulnerabilities land on dev and are promoted to a release as soon as they are validated; credit is given in the changelog unless you ask otherwise.

If GitHub advisories are unavailable to you, open a minimal public issue saying "security — need a private channel" without details, and the maintainer will provide one.

This is a single-maintainer project; targets are best-effort but taken seriously.

Confirmed Critical/High reports stay embargoed until a fixed release is published, targeted at ≤90 days from confirmation. The fix may land on dev with a neutral commit message during embargo. Reporters are consulted on the advisory text and credited. CVE IDs are requested through GitHub's advisory CNA flow when a report warrants one.

Security fixes are released for the current release (N) and backported to N−1 within its 90-day window (see SUPPORT_MATRIX.md). A security release follows the normal release pipeline (immutable sha-* images, test-gated tag promotion) plus a changelog entry marking it security-relevant and an advisory publication.

If a published model, Lens, or ASA artifact turns out to be bad (malware, corruption, wrong calibration, license problem):

1. The artifact is removed or replaced at its HF location.
2. The registry's pinned SHA-256 for it is updated or the entry's status is downgraded in a patch release — installers verify hashes, so already-published pins stop matching the bad artifact and refuse to install it.
3. The changelog and a pinned issue name the affected hashes so users can check installed files with atlas model verify / atlas doctor.