Security & deployment
Move forward with AI. Stay in control.
Three answers before anything else. Your data stays in your VPC if you choose it. We don’t train models on it. Every agent action leaves through a gateway you control.
Deployment
Runs where you need it: your cloud, or ours.
Two ways to run Atlas. Both are confirmed with your team before anything is built & deployed.
Your VPC
Atlas runs inside your AWS / GCP / Azure / or any other cloud infra. Your network policies apply, your keys encrypt the data, and nothing leaves the boundary unless you route it out.
Managed cloud
For pilots, or for teams without a cloud environment ready: Atlas runs on infrastructure we operate in, single-tenant, with your data encrypted at rest and in transit.
Before implementation, your team gets a data-flow diagram: every system the solution touches, what it reads and writes, and where it’s processed. It goes live when you sign it off.
Your data
What we do with it, and what we don’t.
Not used for training
Your data, prompts and outputs are not used to train or improve models, ours or anyone else’s.
Encrypted both ways
Encrypted at rest and in transit. In a VPC deployment, encryption uses your keys.
Kept only as long as agreed
Retention for conversation and task records is set in your contract, not by us. When you ask for deletion, we complete it within the agreed window and confirm in writing.
Where inference runs
In a VPC deployment, models run inside your boundary and no data leaves it. In a managed deployment, any third-party model provider we use is bound to zero-retention terms, named in your contract, and not changed without telling you.
Our people
When our engineers work in your environment.
Where the work calls for it, our engineers build alongside yours, inside your codebase and systems. That access is granted by you, logged by you, and removed when the work ends.
Access you grant
Engineers work through accounts you provision, with the permissions you set. No shared credentials, no standing admin.
Activity you can see
Work happens in your repositories and your environments, so your existing audit and logging apply to us too.
Off-boarding on a date
Access is removed at the end of each engagement phase. We confirm removal in writing and retain no copies of your code or data.
Control in practice
Clear boundaries. Deliberate access.
Every Atlas deployment runs behind Sylo, our gateway. Agents reach systems through it, and nowhere else.
What an agent can reach
You define the destinations and services. The gateway enforces that list at the network layer, so it holds even if the agent misbehaves.
What an agent can act on
Tools and actions are specified per workflow. Anything you mark for approval stops and waits for a named person.
What you can audit
Credentials are injected at the gateway, never held by the agent, and every request is recorded outside the agent’s reach.
Access
Your identity provider, your roles.
Sign-in through your identity provider. Roles and permissions are set by your administrators, and Atlas staff have no access to your tenant unless you grant it for a defined task.
Documentation
What your security team can have now.
Here is exactly where we stand, and what we’ll send on request.
Available now
Architecture and data-flow document for your deployment
Data processing agreement
Sub-processor list
Completed security questionnaire
Responsible disclosure
Before you begin
Clarity from the start.
Where will our data be processed?
In your VPC, if you choose it, and nothing leaves. Otherwise on our managed infrastructure. Either way you get a data-flow diagram before implementation and sign it off.
How are actions and approvals defined?
In writing, per workflow, before go-live. The list names each tool and action, which steps stop for a person, and who that person is. Changing the list is a change request, not a config edit.
What can our security team review?
The architecture document, the data-flow diagram, the sub-processor list and our questionnaire responses, all before a contract. We’ll also put our engineers on a call with yours.
Do your engineers need access to our production systems?
Only what the workflow requires, through accounts you provision. Most build work happens in a non-production environment you control; production access, where needed, is scoped to the integration and removed afterwards.
Let’s talk through your requirements.
Send the questionnaire, or bring your security team to the first call. We’d rather answer early.