You are handing us access to your systems.
So here is exactly what Atlex can and cannot do with it, how one customer’s data is kept away from another’s, what we keep and for how long, and who else is involved.
Read-only by construction
Atlex has no code path that writes to a connected system. The permissions you grant are read-only, so there is no destructive action to misconfigure - and it reads repository structure, never your source.
One customer can't see another
Row-level security in Postgres, an application role that cannot bypass it, and a boot-time assertion that refuses to start the API if it ever could. A cross-tenant request returns 404, not 403.
Credentials encrypted separately
Connector credentials are encrypted with AES-256-GCM before storage, under a key the database never holds, with rotation supported without downtime.
Yours to take, or to delete
Full export on every plan including Free. Disconnect a source and its data goes with it. Delete the organization and the cascade reaches every table.
What Atlex can reach
Atlex is read-only by construction, not by policy. The AWS role you create grants read permissions only, and the GitHub App requests read scopes only - there is no code path in Atlex that writes to a connected system, so there is nothing to misconfigure. It reads repository structure - manifests, workflows, metadata - not your source code. Missing permissions are reported to you, never silently skipped, so you always know whether the picture is complete.
Keeping tenants apart
Every org-scoped table is protected by Postgres row-level security keyed to the organization on the current transaction, and the application connects as a restricted role that cannot bypass it. That last part is asserted at boot: if the database role could ever bypass RLS, the API refuses to start rather than serve a request. A request for another tenant’s resource returns 404, never 403 - we don’t confirm that someone else’s data exists.
Encryption and credentials
Traffic is TLS-encrypted end to end, and data is encrypted at rest by our database and storage provider. The credentials you give Atlex for a connected source are encrypted separately with AES-256-GCM before they are stored, under a key the database never sees, and the scheme supports rotation without downtime - old keys decrypt, the current key encrypts.
What the AI sees
Atlex AI runs on your own model key. There is no shared platform key on this deployment, so questions asked in Atlex go to the provider account you configured, under your own agreement with them - not through ours. Answers are grounded in your graph and cite it; the model is never trained on your data by us, and we do not fine-tune anything on customer content.
What we keep, and for how long
- Raw snapshots from your sources30 days
- Resource change history12 months
- Sync run history90 days
- Product analytics12 months
- Audit logKept for the life of the organization
- Your graph, insights and incidentsUntil you delete them
Where your data lives
Atlex is hosted in Australia, and your graph, snapshots and history stay there. AI processing is the exception, and where it happens depends on a setting you control: connect your own model key and questions go to that provider under your agreement with them; leave it unset and they are answered using a provider Atlex engages, under ours. Either way, only the context needed to answer the question is sent, and no provider we engage may train on your data. If you need a specific region for regulatory reasons, talk to us before you connect anything.
Sub-processors
We rely on a small set of vetted providers - managed database and storage, cloud hosting, transactional email, payments, product analytics, and an AI model provider for organizations that have not configured their own - each bound by data-protection obligations consistent with our privacy policy, where they are named. A current list, with the role each one plays, is provided to customers and to anyone conducting a security review on request.
What our own analytics collects
We measure how Atlex itself is used - which pages are opened, which features are reached, where setup fails - through Google Analytics. Those events carry opaque identifiers, fixed categories and size bands, and nothing else.Nothing from your estate is included. No resource, repository or service names, no finding or incident titles, no questions asked of Atlex AI or answers given, no file paths, cloud account identifiers or URLs. This is telemetry about the product, not about what the product read - so the residency statement above, which covers your graph, snapshots and history, is unaffected.
What you can do at any time
Export everything Atlex holds for your organization, on any plan including Free. Erase an individual’s personal data on request. Disconnect a source, which removes its credentials and the data it produced. Delete the organization outright, which cascades to every table. And read the audit log - an append-only record of security-relevant actions that the application itself cannot alter or delete.
Reporting a vulnerability
Email with the subject Security vulnerability report. We aim to acknowledge within two working days and to keep you updated until it’s resolved. Test only against your own organization, don’t access other customers’ data, and give us reasonable time before disclosing publicly - do that and we will not pursue you. We don’t currently run a paid bounty. The machine-readable version is at /.well-known/security.txt.
Questions before you connect anything?
Ask them first. We would rather answer a hard question now than have you find out later.