Security & data handling
SECURITY &
DATA HANDLING
The posture below is what we have verified about our own pipeline — stated plainly, without security theater.
Atlas is local-first software: in the customer-run model, your repository never leaves your environment, so most of this page does not apply to you. The posture below governs the operator-run founding workflow, where a repository is contractually transferred to us to run a screen on your behalf.
01 · How customer repositories are handled
The operator-run engagement posture
This table governs the current operator-run founding workflow. Under the customer-run local model, transfer, retention, and deletion simply do not occur — the repository never leaves your machine.
| Where processing happens | Under operator-run delivery, customer repositories are processed on a single dedicated engagement machine with full-disk encryption, and no cloud processing occurs during analysis. Under the customer-run local model, processing happens entirely in the customer's own environment. |
| Network | The analysis pipeline has no network code paths — verified by dependency inspection and a strings scan of the release binary. The only network step in delivery is intake and report delivery themselves. |
| AI exposure | No AI provider is involved in the acquisition screen. The engine does not link an AI dependency; no AI service ever touches customer data in this pipeline. |
| Telemetry | None. No analytics, no crash-dump upload — logging is local standard output only. |
| Raw Event Log | Withheld by default. It contains every author name/email pair in the history — more personal data than the screen requires. It is delivered only on explicit request, with the personal-data implication stated in writing. |
| Retention & deletion OPERATOR-RUN ONLY | A Knowlton service policy for the operator-run workflow — not Atlas behavior. Where a repository has been transferred to us, the repository, Event Log, derived stores, and run logs are deleted 7 days after report acceptance by default (method recorded); earlier deletion on written request. The delivered report is retained as a business record. No backups of customer data are kept — deletion is the control. In the customer-run local model there is nothing on our side to delete. |
| Engagement isolation | One folder per engagement; no cross-customer reuse of analysis state — also required for determinism. |
| Credentials | The engine never sees credentials. Intake tokens must be read-only, short-lived, never persisted to our records, and revoked by you same-day after transfer. |
02 · What we do not claim
Honest limits
- We do not call the system "air-gapped." The pipeline is network-free, but the delivery workflow is not: intake and report delivery cross the network. A fully offline run can be arranged for enterprise engagements — and only such an engagement would ever be described as disconnected.
- We do not claim SOC 2, ISO 27001, or HIPAA compliance. No such certification exists today, and we won't imply one.
- We do not scan target repositories for committed secrets. If conspicuous secrets are noticed, we do not open them, do not report their contents, and notify you.
- Transfer security is partly yours. Bundle intake uses your own secure share; we document the handling on our side.
03 · Your side
Customer responsibilities
Engagements require simple representations: that you are authorized to provide the repository, that providing it doesn't breach agreements known to you, and that you will make reasonable efforts not to include production credentials, customer databases, personal-data dumps, PHI, or cardholder data. We never request secrets.
Questions about any of this — before or during an engagement — go to hello@knowltonindustries.com.