# Private AI Coding Deployment Reference > How to evaluate and deploy a terminal AI coding agent while keeping model routing, source code, prompts, tools, and logs inside an approved boundary. Version 1.0. Describes Atlas 1.22.0. Reviewed 2026-08-04. Published by Atlas by Syntora. This reference is not a certification, an audit, an attestation, or legal advice. It describes tested product behavior at a stated version and nothing more. Atlas holds no security certification. Verify anything here that your decision depends on. ## 1. Architecture and data flow Every outbound call passes through one place. That is what makes the boundary checkable rather than aspirational, and what lets a test assert something about code nobody has written yet. ```text YOUR MACHINE +--------------------------------------------------------------+ | | | your repository -----> Atlas (TUI / CLI) | | ^ | | | | | every outbound call | | | edits, diffs v | | | [ egress boundary ] | | | | | | +--- tools <-----------+ | | (argv, no shell) | | | | | +-------------------------------|------------------------------+ | default mode | offline mode +--------------------------+--------------------------+ | | | v v v model endpoint telemetry, model endpoint (your provider) updates, entitlement, + local services + config fetches ONLY local services | X blocked in offline mode ``` ## 2. Deployment patterns ### Local inference only Run a model on the workstation with Ollama or LM Studio, register it with atlas models --local, and start Atlas with --offline. Prompts reach a process on the same machine and nothing else leaves it. **Trade-off.** Local model quality and context length set your ceiling. Update checks and entitlement are blocked too, so upgrades become a deliberate act. ### Approved private endpoint Point Atlas at an endpoint your organization already reviewed, such as a private deployment of a hosted model or a gateway you operate. Offline mode still allows your configured model endpoint. **Trade-off.** Your boundary is now the endpoint's boundary. Atlas can prove what it sent and where; it cannot prove what the endpoint does afterwards. ### Default mode with telemetry disabled Run normally against a commercial provider with ATLAS_DISABLE_TELEMETRY=1. Suitable where the model provider is already approved and the concern is vendor analytics rather than model routing. **Trade-off.** Update, entitlement, and config traffic still occur. This narrows what Atlas reports; it does not narrow where prompts go. ## 3. Egress and telemetry by mode Offline is opt-in with `atlas --offline` or `ATLAS_OFFLINE=1`. Atlas can run offline. It is not offline unless you ask for it. | Destination | What it carries | Default mode | Offline mode | | --- | --- | --- | --- | | Your model endpoint | Prompts, and the file content you or the agent puts in them | Sent, to whichever provider you configured | Sent, and this is the only remote destination allowed | | Local services on your machine | Requests to a local model or embedder you are running | Allowed | Allowed | | Telemetry | A fixed, published list of fields. Counts are sent as ranges | Sent unless you set ATLAS_DISABLE_TELEMETRY=1 | Blocked | | Update checks | The current release version | Sent | Blocked | | Entitlement checks | Account and plan state, when signed in | Sent | Blocked | | Config fetches | Remote configuration and model catalog data | Sent | Blocked | | Hosted embedding service | Code, for semantic index building | Only if you explicitly opt in. Never a silent fallback | Refused entirely | ## Controls, each with the test that backs it Atlas is proprietary, so you cannot read the source. An unfalsifiable claim is worth nothing here, so each control names its test and its limitation. ### Enforced egress boundary Runs fully offline. In offline mode Atlas sends nothing over the network except to your model endpoint and local services. - Evidence: egress.test.ts, egress-session.test.ts (a full mixed session, verified at the wire) - Limitation: Offline is opt-in with atlas --offline or ATLAS_OFFLINE=1. It is not the default. Atlas can run offline; it is not offline unless you ask for it. ### No phone-home in offline mode In offline mode Atlas does not phone home: telemetry, update checks, entitlement checks, and config fetches are all blocked. - Evidence: egress.test.ts, boundary-contract block - Limitation: Only true in offline mode. In the default mode these destinations are reachable. ### Single network choke point No outbound network call in Atlas can bypass the offline boundary. - Evidence: egress-chokepoint.test.ts - Limitation: Holds because every outbound call goes through one fetch path and a test asserts there are no raw sockets. That test passing is the guarantee. ### No silent cloud embedding Your code is not sent to a hosted embedding service. Atlas never falls back to a cloud embedder silently, and refuses one entirely in offline mode. - Evidence: codebase-embedding.test.ts - Limitation: A hosted embedder exists as an explicit opt-in. The claim is about default and offline behavior, not that hosted embedding is absent. ### Bring your own local model When you run atlas models --local, Atlas probes local Ollama and LM Studio endpoints and registers discovered chat models as a first-class provider. - Evidence: local-provider.test.ts - Limitation: Detection is an explicit command, not an automatic startup action. Atlas does not install or configure a model for you. ### Telemetry cannot carry your work Telemetry never contains your prompts, code, file paths, file names, repository names, or error messages. Events carry a fixed list of fields, and counts are sent as ranges rather than exact values. - Evidence: telemetry/tests/event.test.ts - Limitation: This describes what the telemetry system can emit, enforced at build time rather than filtered at send time. It is not a claim that Atlas sends nothing. ### The schema is printable You can print the exact schema of what Atlas would send, from the CLI, with atlas telemetry export. - Evidence: Reproduce it yourself with the command in the verification section - Limitation: The claim is about the schema, not a live buffer of what has been sent. ### No shell in the tool path When Atlas runs one of your command-line tools, it passes arguments as an array and never through a shell, so nothing in a command can be reinterpreted as a second command. - Evidence: toolchain/argv-executor.test.ts, which asserts a '; echo pwned' argument arrives intact - Limitation: Scoped to the toolchain path. The bash tool is a shell by definition and this says nothing about it. ### Credentials removed from tool output Credentials are removed from tool output before it reaches the model, the transcript, or disk. - Evidence: toolchain/invoke.test.ts, covering both stdout and stderr - Limitation: Removes what a provider manifest declares as a secret pattern. It is a declared-pattern filter, not a general secret scanner. ### Destructive commands cannot be silenced Destructive commands ask every time. A verb marked high risk carries no always-allow, and no configuration file can grant one. - Evidence: toolchain/classify.test.ts, gh-manifest.test.ts, supabase-manifest.test.ts - Limitation: True for tools Atlas has a manifest for. A CLI with no manifest still runs through the shell under normal permissions. ### No interactive logins Atlas never runs an interactive login for you. - Evidence: toolchain/invoke.test.ts, which asserts the refusal happens before any process is spawned - Limitation: Atlas surfaces the command for you to run. It does not mean Atlas cannot use credentials that already exist. ## 4. Tool permission model | Decision | Example | Why | | --- | --- | --- | | allow | gh pr list, supabase migration list, reading a file in the project | Classified as reads. They cannot change your system or a remote one, so interrupting on them trains people to click through prompts. | | ask | gh pr create, editing a file, supabase functions deploy | Changes something. The prompt is scoped to that verb, so approving one does not approve its destructive siblings. | | deny | supabase db push, gh workflow run, gh repo delete | Marked high risk in the manifest. These always prompt, and the always-allow option is withheld rather than merely defaulted off. | ## 5. Limitations A vendor that cannot name its own gaps has not looked for them. - Atlas is proprietary software with a free core. You cannot read its source, so every claim here rests on a named test rather than on your own inspection. Weigh that accordingly. - Offline mode is opt-in. In the default mode Atlas reaches telemetry, update, entitlement, and config destinations. - The wire-level egress proof covers a full mixed session through the fetch path. A live TUI session with third-party MCP servers and plugins loaded has not been driven end to end. Those calls go through the same choke point, so the guard covers them, but they have not been separately exercised. - Redaction removes patterns a provider manifest declares. It is not a general secret scanner and will not catch a credential shape nobody declared. - Per-verb command classification applies to tools Atlas has a manifest for. Two ship built in. Anything else runs through the shell under ordinary permissions until you add one. - Atlas holds no security certification. There is no SOC 2 report, no ISO certificate, and no HITRUST certification. Any page telling you otherwise is wrong. - What your model provider does with a prompt after it arrives is outside Atlas and outside this document. ## Shared responsibility ### Atlas owns - Enforcing the egress boundary and keeping the choke point single - Constraining what telemetry can contain, at build time - Classifying tool commands and withholding always-allow from destructive ones - Passing tool arguments as an array rather than through a shell - Publishing the limitations above and keeping this page current with the release ### You own - Choosing the model endpoint and accepting its data handling - Deciding whether offline mode is required, and enforcing it if so - Reviewing which tools have manifests and what each verb is allowed to do - Your own network controls, and verifying the boundary rather than trusting this page - Everything about the repository you point Atlas at ## 6. Verify it yourself Every command below is runnable. The last is the check we would want from a vendor, so it is the one we suggest running against us. ### See exactly what telemetry could ever contain ```sh atlas telemetry export ``` Expect: Every event name and every field it may carry, generated from the same allowlist the emitter enforces. ### Confirm telemetry is off ```sh atlas telemetry status ``` Expect: Reports the current state. ATLAS_DISABLE_TELEMETRY=1 overrides a stored yes. ### Start a session that cannot reach anything but your model ```sh atlas --offline ``` Expect: Telemetry, update checks, entitlement checks, and config fetches are refused at the boundary. ### Register a local model and check what was found ```sh atlas models --local ``` Expect: Probes Ollama on port 11434 then LM Studio on port 1234, and lists the chat models it registered. ### See which of your CLIs Atlas can drive, and how each verb is classified ```sh atlas toolchain && atlas toolchain doctor ``` Expect: An inventory with version, auth state, and readiness, plus the exact fix for anything not ready. ### Watch the boundary yourself rather than trusting this page ```sh Run Atlas behind your own egress proxy or packet capture in offline mode ``` Expect: Traffic to your configured model endpoint and local services. This is the check we would want from a vendor, so it is the one we suggest. ## 7. Vendor evaluation checklist Written to stay useful even when the answer rules Atlas out. A checklist only one product can pass is a brochure. ### Can the agent run with no destination except a model endpoint you approved, and is that a mode or a promise? A configuration flag someone can forget is different from an enforced boundary. Ask which one it is and ask what proves it. ### Is there a single place all outbound traffic passes through, and is there a test that fails if a new call site bypasses it? Boundaries decay as code is added. The test matters more than the boundary, because it is what keeps the boundary true next quarter. ### What can the vendor's telemetry contain at its widest? Ask for the schema, not the policy. A privacy policy describes intent. A schema describes capability. Only one of them constrains a future release. ### When the agent runs your command-line tools, does it build a shell string or an argument array? A shell string means any value in a command can become a second command. This is the injection question, and it has a factual answer. ### Can a single approval grant more than the action in front of you? Ask whether approving one command approves its siblings. Ask whether the destructive ones can be permanently silenced at all. ### Does the agent send your code to a hosted embedding service to build its index, and is that opt-in or a fallback? Semantic search is where code leaves quietly, because it happens at index time rather than at prompt time. ### What is explicitly not covered? Ask for the limitations list. A vendor that cannot name its own gaps has not looked for them. Treat a missing limitations section as the finding. ## 8. Change history - **1.0** (2026-08-04). First publication, against Atlas 1.22.0. Every control verified by running its test on the release commit. The consent claim was deliberately excluded because the first-run prompt is not yet rendered in the TUI. ## Install Atlas ```sh curl -fsSL https://runatlas.sh/install | sh ``` --- Canonical HTML: https://runatlas.sh/private-ai-deployment Source of truth: src/content/deployment-reference.ts (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.