Security and data residency
What leaves your network, said before you ask.
You are going to find this in review either way. Volunteering it is the only version of this page worth writing.
The short version
- Model weights, KV cache and inference execution stay on your hardware. There is no path by which any of these reach us, and no configuration that changes that.
- Prompts and responses transit the Atlas gateway. They are held in memory for the life of the request and are never persisted, logged, or used for training.
- Metadata does leave and is stored: GPU health, utilisation metrics, token counts, endpoint names and model names.
- Connections are outbound only. No inbound firewall rules, no VPN, no listener on your network.
- A customer-hosted gateway is on the roadmap. With it, nothing transits Atlas at all. It is not shipped today.
The part most vendors bury
Prompts transit our gateway.
In the architecture we ship today, a request goes from your client to our gateway, and our gateway forwards it to your node agent. That means the prompt — and the response — passes through infrastructure we operate.
While it is there: it exists in process memory for the duration of the request. It is not written to disk. It is not written to an access log, an error log, or a trace. It is not sampled for quality review. It is not used to train or evaluate anything. And it is gone when the connection closes.
That is a meaningful set of controls, and it is still not the same thing as the data never leaving. Those are different claims and they get different answers in a review, so we make the weaker, true one.
On the phrase you will see elsewhere
“Your data never leaves your environment” is the line the rest of this category uses. For Atlas today it would not be true, so it is not on this site, and if you ever hear it from someone here, they are wrong and you should say so.
What is true: your model never leaves your environment, and your prompts pass through one hop that we operate and do not retain.
If that hop is a hard no for your workload — and for some regulated workloads it should be — say so on the first call. We will tell you honestly whether the roadmap timeline works for you, and if it does not, we would rather not waste your procurement cycle.
Data-flow inventory
Every class of data, and where it ends up.
This is the table your security architect is going to build anyway. Here it is already built, and we would rather argue with you about a row in it than about whether it exists.
Model weights
Your hosts, pulled from a registry you nominate
Never transit our infrastructure. If you point the agent at an internal mirror, nothing is fetched from the public internet either.
KV cache
GPU memory on the serving host
Built on the card, read on the card, freed on the card. It is never serialised, never sent anywhere and never written to disk.
Inference execution
Your GPUs
Every forward pass runs on your hardware. There is no remote execution path and no fallback that moves a request off your fleet.
Prompts (request bodies)
Through the Atlas gateway, in memory
Held for the life of the request so the gateway can route it, then dropped. Not written to disk, not written to logs, not used for training or evaluation.
Responses (completions)
Through the Atlas gateway, in memory
Streamed back through the same path under the same rules. Response bodies do not appear in our logs, including error logs — a failed request records the status and the reason, not the content.
Request metadata
Atlas control plane
Timestamp, team, API key ID, endpoint name, model name, prompt and completion token counts, latency, status code. This is what quota enforcement and chargeback are computed from. Default retention 13 months.
GPU and node telemetry
Atlas control plane
Utilisation, memory in use, temperature, ECC errors, driver and engine versions, hostname, node labels. Default retention 13 months.
Deployment configuration
Atlas control plane
Model names, precisions, replica counts, node labels, quota allocations. Model names can be revealing — if a deployment name would disclose something, name it something else.
API keys
Atlas control plane
Stored as a salted hash. The full value is shown once at creation and cannot be retrieved afterwards. The visible prefix exists so you can identify a key in an audit log without holding it.
Console user identities
Atlas control plane
Email address, display name, and the subject identifier from your IdP. No password if you use SSO, because we never receive one.
Audit log
Atlas control plane
Who changed which deployment, quota, key or policy, and when. Default retention 24 months. Exportable to your SIEM.
Network posture
Outbound only
The agent dials out on 443 to the control plane and holds the connection open. Nothing dials in. There is no inbound rule to request from your network team, which for most banks is the difference between a two-week change and a two-month one.
Egress allowlist
Two hostnames: the control plane, and whichever registry you nominate for weights. If your registry is internal, the second one never leaves your network. Both are configurable and both are documented in the agent config.
Mutual TLS
The agent authenticates with a certificate issued at enrolment and rotated automatically. A stolen enrolment token is single-use and short-lived; a stolen agent certificate can be revoked from the console and takes effect on the next connection.
TLS 1.3 in transit
Client to gateway, gateway to agent, agent to control plane. No plaintext hop anywhere in the path, including inside our own infrastructure.
No inbound path to your GPUs
The engine binds to localhost on the serving host. It is not reachable from your own network either, let alone ours, which removes a whole class of lateral-movement questions.
Region pinning
You choose the gateway region for your account, and requests are only routed to gateways in it. Metadata is stored in the same region. Choose it before the trial rather than after.
Compliance
What we do not have.
No certifications, stated plainly
Atlasdoes not hold SOC 2 Type I or Type II, ISO 27001, ISO 27017, HITRUST, PCI DSS attestation, FedRAMP authorisation, or any other certification. We are not “in the process of” anything we can put a date on, and we are not going to imply a pending audit to get through your first gate.
We know what that costs us. It rules us out of some procurement processes outright, and it should — a bank with a hard SOC 2 gate is not doing anything unreasonable by applying it.
What we can give you instead, today, on request:
- A complete data-flow inventory, which is the table above, with anything your reviewer wants added to it
- The current subprocessor list, by name and by function, with the region each operates in
- Our architecture, including the parts that are awkward, in a call with an engineer rather than a questionnaire team
- Answers to your own security questionnaire, with “no” written in the boxes where the answer is no
- A written commitment on breach notification timelines in the contract, which is enforceable in a way a badge is not
If a certification is a hard requirement rather than a preference, tell us on the first call. We will say so if we cannot meet it and neither of us will spend a quarter finding out.
Roadmap
The customer-hosted gateway.
The shipped architecture has one hop we would rather not have. The fix is to let you run the gateway yourself, inside your own network, so that prompts never cross a boundary you do not control. The control plane would keep doing what it already does — inventory, quota, policy, metrics — over the same metadata-only channel.
We are not putting a date on this page, because a date on a marketing site is a promise made to someone who cannot hold us to it. Ask on a call and you will get our current honest estimate, including the confidence attached to it.
What we will commit to in writing: if you sign while the hosted gateway is the only option, moving to the customer-hosted one when it ships is a configuration change, not a migration, and it is not a paid upgrade.
Questions from actual security reviews
- Do prompts leave our network?
- Yes. Prompts and responses transit the Atlas gateway, which runs in our cloud, on their way to and from your node agent. They are held in memory for the life of the request and are never written to disk, never logged and never used for training. Model weights, the KV cache and inference execution never leave your hardware.
- Can we run the gateway ourselves so nothing transits Atlas?
- Not today. A customer-hosted gateway is on the roadmap and is the single most requested item on it. Until it ships, the transit described above is unavoidable, and we would rather you knew that in the first meeting than discovered it in review.
- What inbound firewall rules do we need?
- None. The node agent opens an outbound TLS connection on port 443 to the control plane, and the gateway reaches your nodes over that existing connection. There is no listener on your side, no inbound rule and no VPN.
- Do you hold SOC 2 or ISO 27001?
- No. We hold no certifications today and we will not imply otherwise. We can give you the architecture, a data-flow inventory, our subprocessor list and direct answers from an engineer, which is what an early-stage vendor honestly has to offer.
- Where does the gateway run, and can we pin the region?
- You choose the gateway region at account creation, and requests for your account are only routed to gateways in that region. Metadata is stored in the same region. Tell us the jurisdiction you need before the trial rather than after.
- What happens to our data if we leave?
- Weights and KV cache were never ours to delete — they are on your hardware and stay there. Metadata, telemetry and audit logs are deleted on request within 30 days, and exportable before that.
If your question is not here, it is probably a good one. Send it to us and Priya will route it to whoever actually knows, rather than to whoever writes the answers.
Bring your security architect to the first call
Not the second one. The awkward questions are cheaper to answer now, and if the answer rules us out, both of us would rather know in week one.
Priya Raghavan replies within one working day. No sequence, no SDR, no calendar tennis.