Security
What Dalton can see, keep and touch.
Read-only on every integration by default. Dalton keeps a map of your system, not your data, and nothing it proposes reaches production without your approval.
- Signals: alerts, status changes, sharp shifts in a metricqueried when needed, then discarded
- Kubernetes resource dataobjects and how they connect
- Deploys, config changes and versionswhat changed, and when
Raw telemetry, log payloads and the contents of your data stores.
Only what you connect, read-only.
Each integration has its own scoped, read-only credentials. You choose the accounts, clusters, repositories and channels Dalton can reach, and PII is redacted before anything is stored or reaches a model.
- ObservabilityRead-only API keys, scoped per account, org or project. No agent: the vendor already is one.
- Kubernetes & cloudRead-only API keys and roles in each cloud account; optionally one small install in each cluster.
- Code & CI/CDThe GitHub or GitLab app, installed per organization or per repository.
- Knowledge & ticketsOAuth or an API token, scoped to the workspaces and projects you pick.
- ChatThe Slack app, installed once and added channel by channel.
It keeps the map, not your data.
Dalton stores what it needs to understand your system and reads everything else where it lives. Your data never trains a model, ours or anyone else's.
Kept
- The map of your services and how they connect
- Context from your code, or none with BYOC: it stays in your VPC
- Investigations, for as long as your policy says
- Audit logs, one year by default
Not kept
- Logs, metrics and traces: read, used, discarded
- Ticket and document text: only the links stay
- The contents of your data stores
Everything Dalton built about your system is deleted when you offboard.
Nothing, until you approve it.
Writes are off by default. You turn them on per integration, environment and kind of action. Every write needs a person's approval, each time. Each one lands in an audit log you can export, with its evidence and credential.
- Proposed by Dalton, with its evidence attached
- Approved by the on-call engineer
- Merged by the checkout team
- Runs asthe GitHub app, pull requests only
- Loggedwho approved it, when, and the evidence
Audited every year, by someone else.
Dalton is SOC 2 Type II certified and GDPR compliant. The SOC 2 report, the DPA and our subprocessor list are available under NDA.
- AES-256 at rest, TLS 1.3 in transit
- Inference only on AWS Bedrock or Google Vertex, under no-retention terms, or on your own endpoint
- Each customer a separate tenant: no shared storage or inference
- Role-based access, with SSO and SCIM for enterprise
- Regular penetration tests and third-party reviews
- 24/7 security monitoring, backups and point-in-time restore
What security teams ask.
Is Dalton SOC 2 compliant?
Yes. Dalton is SOC 2 Type II certified, and the report is available under NDA.
Does Dalton train models on our data?
No. Your data never trains a model, ours or anyone else's. Nothing that passes through Dalton is used to train, fine-tune or evaluate one, and inference runs on AWS Bedrock or Google Vertex under no-retention terms.
Is Dalton GDPR compliant?
Yes. Dalton is GDPR compliant, and a DPA is available on request.
Can Dalton change our production systems?
Not without your approval. Every integration starts read-only. Writes are turned on per integration, environment and kind of action, and every write needs a person's approval, each time. Each one is logged with its evidence.
How do we limit what Dalton can read?
By scoping each integration's credentials. Limit access by account, environment, namespace, repository or channel. Every read is recorded in the audit log, with the credential it ran under.
What happens to our data if we leave?
Everything Dalton built about your system is deleted. The map of your services and the context from your code are removed when you offboard; investigations follow the retention policy you set.
Review the details with our team.
The SOC 2 report, the DPA and the subprocessor list, under NDA.