Security and data
This paper answers a security review of Gatlas, as far as our code and our contracts back it.
Gatlas syncs the tools each company in a group uses into one workspace, and agents read that workspace without writing to those tools. Each reader sees only the companies you grant. Every request an agent makes is logged.
The data processing agreement, the privacy policy and the terms are the binding text.
What Gatlas reads
Gatlas reads each company’s tools, such as its ledger, CRM, store and shared drive. The tools a company connects, and the parts of each it turns on, set what Gatlas reads.
Agents are read-only to every company’s tools, whatever their access inside Gatlas. That holds for your own agent, such as Claude, and for the Gatlas agent in Slack.
Gatlas sends data to another tool only where an admin sets it up, such as a spreadsheet export or a Slack channel. No agent can set one up or run one.
The Gatlas agent answers in Slack where an admin sets it to: in named channels and to named people, or across the Slack workspace. Anyone who can read such a channel can read its answers.
We do not use customer data for advertising, for resale or to train models.
Credentials
When a company connects a tool, the credential it gives is stored against that one connection. Only the Gatlas sync service reads it, and only to reach the tool it came from.
Credentials sit in a closed table that no login and no agent key can read. Row-level security admits no session to it, and only the Gatlas service role can call its functions. Gatlas refuses any agent query that calls one.
Credentials are encrypted at rest with the rest of the database, and traffic is encrypted in transit with TLS. Removing a connection removes its credential at once.
An agent key is the credential that lets one agent reach Gatlas. Gatlas matches each key by its SHA-256 hash, and refuses a revoked key.
The key itself is stored encrypted, so a workspace admin can show it again. A personal key, which a person made for their own agent, shows only to that person.
Access
Each reader sees only the companies you grant. A person joins a workspace with a role and a grant of companies, and row-level security in the database holds them to that grant.
People log in to Gatlas with an email and a password. Multi-factor login is planned.
An agent key reaches only the companies its grant names, and whoever makes a key can grant only companies they hold. An agent’s own database queries reach only those companies’ synced tables.
A dataset that covers several companies opens only to a key granted every one of them. The same rule holds for artifacts.
- Only the companies granted
- A workspace admin, or a person for their own agent
- Read-only or Read/write, set for each agent key
- Start as Read/write, to create and edit datasets and artifacts
- For anyone who only asks questions
- Read-only to every agent, whatever its access
- Read tools only, through a Read-only key of its own
Request log
Every request an agent makes is logged. Each row names the agent key, the tool, its outcome and when, and a call Gatlas refuses is logged too.
For a dataset question, the log keeps the dataset and the columns filtered on, and leaves the filter values out. For a database query, it keeps the first 200 characters, which can hold values. Rows are kept for 180 days.
Changes inside a workspace, such as a role changed, a key made or revoked, or a setup link sent, go to its audit log. A member sees the entries for their granted companies, and a member granted the whole workspace sees them all.
Share links
Each artifact has a share link that opens it without logging in. The link shows that one artifact and nothing else in the workspace.
Anyone who holds the link can read the artifact, so share it only with people entitled to its data. The link has no expiry, and it can be revoked or replaced with a new one at once.
An edition, a dated copy of an artifact, has a share link of its own. A guest key, which an admin makes for someone else over some companies, is never shown a share link and cannot revoke one.
Support access
A Gatlas staff member set up for support can open a customer’s workspace to help with it. That access is read-only: the staff member holds the viewer role, the lowest there is, which cannot change the workspace.
Each time a staff member opens a workspace this way, the visit is recorded in its audit log. Members granted the whole workspace see that entry.
Staff who work on production systems hold access on a least-privilege basis and are bound by confidentiality.
Company data
Each company’s tools sync into a space of its own in Gatlas. That space is a database schema of its own, named for the workspace and the company.
Workspaces share one database. Row-level security and the grants above keep each workspace to its own data and each reader to the companies granted.
A missing value shows as missing.
Where data lives
The Gatlas database runs on Supabase in the United States. Our sub-processors may process data in the European Union and the United States. Where data leaves a customer’s jurisdiction, we rely on safeguards such as the European Commission’s Standard Contractual Clauses.
| Sub-processor | What it does |
|---|---|
| Supabase | Database, login and encrypted storage of secrets |
| Vercel | Web hosting, and the AI Gateway that routes each model request to the providers below |
| Railway | Background data syncing |
| Resend | Email for setup links, invitations and notifications |
| Anthropic | Models that run the Gatlas agent and write from company data |
| OpenAI | Embeddings that let search rank passages of company files |
| Voyage AI | Reranking of those passages for the same search |
We give notice before we add or replace a sub-processor, and a customer may object on reasonable data-protection grounds.
What your own agent reads goes to that agent’s provider, which you chose.
Setup links
A workspace admin sends a setup link to whoever manages each company’s tools. An agent with a Read/write key can make one for a company its key reaches. The link is recorded under the admin who made the key.
The person who gets the link needs no Gatlas account, since holding the link is what lets them connect. The page names who sent it and the company it is for, lists the tools to connect, and shows none of the workspace’s data.
A link expires after 7 days, or 30 if the sender chooses, and it can be revoked. An expired or revoked link connects nothing, and every link sent goes to the audit log.
The workspace’s plan covers every company in it, including each one invited through a setup link. A company that connects pays nothing.
Data removal
We delete a workspace’s data within 30 days of a request to privacy@gatlas.ai, unless the law requires us to keep it. Encrypted backups are purged on the database provider’s normal cycle.
Removing a connection removes the data synced from it at once, and it is refused if that data cannot be removed.
Legal documents
The data processing agreement follows Article 28 of the GDPR. The customer is the controller of the personal data in its tools, and Gatlas is the processor.
Send a security questionnaire, or any question this paper leaves open, to privacy@gatlas.ai.
- The company named in the data processing agreement
Commitments
The data processing agreement commits us to each of the following.
- Personal data processed only on the customer’s documented instructions
- Notice without undue delay after we learn of a breach affecting customer data
- Information and audits on reasonable notice, under confidentiality
- Help with data-subject requests, including access and erasure
- The agreement prevails over the terms on personal data