Deployment reference
Running a terminal coding agent inside an approved boundary
How an engineering organization can evaluate and deploy a terminal AI coding agent while keeping model routing, source code, prompts, tools, and logs inside a boundary it controls. The checklist works against any vendor. Atlas is the worked example because it is the one whose tests we can name.
Version 1.0 · Atlas 1.22.0 · Reviewed 2026-08-04 · Atlas by Syntora
1. Architecture and data flow
Where the boundary actually sits
Every outbound call passes through one place. That is what makes the boundary checkable rather than aspirational, and it is what a test can assert about code nobody has written yet.
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 mode2. Deployment patterns
Three shapes, and what each one costs you
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
What leaves, in each mode, stated precisely
Offline is opt-in with atlas --offline or ATLAS_OFFLINE=1. Atlas can run offline. It is not offline unless you ask for it, and any page that says otherwise is overstating.
| 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 and their receipts
Each claim names the test that backs it
Atlas is proprietary, so you cannot read the source. That makes an unfalsifiable claim worth nothing here. Each row states the behavior, the test, and the limitation that travels with it.
Enforced egress boundary
Runs fully offline. In offline mode Atlas sends nothing over the network except to your model endpoint and local services.
egress.test.ts, egress-session.test.ts (a full mixed session, verified at the wire)
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.
egress.test.ts, boundary-contract block
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.
egress-chokepoint.test.ts
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.
codebase-embedding.test.ts
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.
local-provider.test.ts
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.
telemetry/tests/event.test.ts
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.
Reproduce it yourself with the command in the verification section
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.
toolchain/argv-executor.test.ts, which asserts a '; echo pwned' argument arrives intact
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.
toolchain/invoke.test.ts, covering both stdout and stderr
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.
toolchain/classify.test.ts, gh-manifest.test.ts, supabase-manifest.test.ts
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.
toolchain/invoke.test.ts, which asserts the refusal happens before any process is spawned
Atlas surfaces the command for you to run. It does not mean Atlas cannot use credentials that already exist.
4. Tool permission model
Approval scoped to the command, not the binary
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.
6. Verify it yourself
Do not take this page's word for it
Every command below is runnable. The last one is the check we would want from a vendor, so it is the one we suggest you run against us.
See exactly what telemetry could ever contain
atlas telemetry export
Every event name and every field it may carry, generated from the same allowlist the emitter enforces.
Confirm telemetry is off
atlas telemetry status
Reports the current state. ATLAS_DISABLE_TELEMETRY=1 overrides a stored yes.
Start a session that cannot reach anything but your model
atlas --offline
Telemetry, update checks, entitlement checks, and config fetches are refused at the boundary.
Register a local model and check what was found
atlas models --local
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
atlas toolchain && atlas toolchain doctor
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
Run Atlas behind your own egress proxy or packet capture in offline mode
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
Seven questions, useful against any agent
These are written to be useful even when the answer rules Atlas out. A checklist that 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.
5. Limitations and responsibility
What this does not cover
A vendor that cannot name its own gaps has not looked for them. Ours are below.
- 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.
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
8. Version and change history
What changed, and when it was checked
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.
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.
Review the security page