What we hold, and what we made sure we never receive
Condux is source-available, so none of this has to be taken on trust. Every measure described here is implemented in code you can read.
The short version, for a security reviewer
- The hosted service runs on infrastructure in Nuremberg, Germany.
- End user IP addresses are discarded at ingest. They are never written to our database.
- Email addresses and credential-shaped values are redacted from every event before storage, and again before anything reaches a model.
- The AI fix engine never receives a source control token, and can only open a draft PR.
- Error data expires automatically after 30 days on Free and 90 days on paid plans.
- We hold no SOC 2 report and no ISO 27001 certificate. Our infrastructure provider holds both ISO 27001 and BSI C5 Type 2 and is audited annually. See below, where we separate the two properly.
- If none of that is enough, run the whole thing yourself and we receive nothing at all.
What gets stripped before anything is stored
Error monitoring has an uncomfortable property: you are shipping fragments of your running system to a third party, and those fragments do not come pre-sorted into safe and sensitive. The design response is to remove what we can before it lands, rather than to promise careful handling afterwards.
- IP addresses are dropped. Not anonymised, not truncated. The field does not survive ingest.
- End user identifiers are hashed. We can tell you how many distinct people an error affected without holding who any of them are.
- Email addresses are redacted wherever they appear in the text of an event.
- Credential-shaped values are redacted, including API keys and access tokens, and any field named like a secret has its value dropped outright.
- The scrub runs twice. Once on arrival, and again before context is assembled for the fix engine, so a secret that slipped the first pass does not reach a model.
The honest limit: scrubbing recognises patterns. It cannot know that a free-text field in your application holds a customer name. What your application sends is ultimately your decision, and the SDKs give you hooks to strip data before it leaves your process.
How the fix engine is kept away from your credentials
An AI agent with repository access is a new kind of exposure, so the Conductor was built to have as little power as it can while still being useful.
- The model never receives a repository token. It proposes a patch. A separate component that holds the credential performs the git operations. A prompt injection in an error message therefore has no token to steal.
- Draft pull requests only. No merge, no push to the default branch, and no configuration flag that changes it. Your CI and your reviewers stand between a proposal and your codebase.
- Scoped context. The agent sees the files the stack trace points at, twice scrubbed, and not your repository.
- Every run is audited, including the tokens it consumed, so the cost and the activity are both visible to you.
- Or move it entirely. On Team and above the agent can run on your own infrastructure, holding your model key and your source token, so neither reaches us.
Platform security
- TLS on every connection, from the SDK to ingest and from the browser to the dashboard.
- Passwords hashed with Argon2id at the parameters OWASP recommends.
- Session tokens and machine credentials stored only as hashes, so a copy of the database cannot be replayed to sign in.
- Customer-supplied secrets, such as a model key, encrypted at rest.
- Tenant isolation checked server-side on every request. A request for another organisation gets a not-found rather than a forbidden, so the existence of other tenants is not discoverable.
- Support access to a customer account is read-only, scoped to one organisation, and recorded in an audit trail that captures the real operator even during the session.
- Automated dependency vulnerability scanning, with remediation tracked.
- Encrypted backups, with a documented and exercised restore procedure.
- Administrative access is least privilege and protected by multi-factor authentication.
Subprocessors
The complete list. We give 30 days notice to account owners before adding or replacing one, and you may object. This list forms part of the data processing agreement. The last column links each one's own data processing terms, so you can read what binds them rather than taking our summary for it.
| Subprocessor | Purpose | Location | Data involved | Their terms |
|---|---|---|---|---|
| Hetzner Online GmbH | Cloud hosting and object storage for the whole service | Nuremberg, Germany. All Hetzner infrastructure we use is inside the EU | All hosted service data | DPA |
| Stripe | Payments, subscriptions and invoicing | United States and Ireland | Billing contact and payment details, which go to Stripe directly and never through us | DPA |
| Anthropic | The model behind the Conductor, our fix engine | United States | A scrubbed extract of the source files behind an error, and only when a fix is requested. Avoidable: bring your own key, or run the agent yourself | DPA |
| Resend | Transactional email: alerts, invitations and account notices | United States | Recipient email address and the content of the notification | DPA |
| GitHub | Repository access when you connect a repo, and where draft pull requests are opened | United States | Only what you already keep there. We act through the installation you granted, on the repositories you selected | DPA |
Certifications, stated honestly
We do not hold a SOC 2 report and we are not ISO 27001 certified. Saying otherwise, or implying it with a badge, would be the fastest way to lose the trust this page exists to earn.
What we can offer instead is unusually concrete. The controls above are implemented in published source code, so your security team can verify them directly rather than reading an auditor's summary of somebody else's testing. We answer security questionnaires. And for organisations whose requirements no vendor attestation would satisfy, the whole system runs on your own infrastructure, with your own model endpoint, at which point our security posture stops being a question you need answered.
Our infrastructure is a different matter, and there the evidence is external. Hetzner is certified to ISO/IEC 27001 (since 2016, the current certificate valid to September 2028, covering all of its German and Finnish locations) and holds BSI C5 Type 2. Its technical and organisational measures are audited annually by TÜV Rheinland, and the February 2026 report covering the Nuremberg, Falkenstein and Helsinki data centres recorded no deviations. We hold an Article 28 data processing agreement with them.
That agreement and the audit report are both confidential documents, so we do not republish them, but we will share them with a customer on request under NDA.
If a formal report about us is a requirement for you to buy, tell us. It is a question of sequencing rather than of willingness, and knowing there is a customer waiting changes when it happens.
Data retention
Raw error events expire after 30 days on the Free plan and 90 days on paid plans. Expiry is a property of each stored row and is enforced by the database itself, rather than by a scheduled job that has to run correctly. Deleting a project or an organisation deletes the data belonging to it. Aggregated counts, which contain no personal data, are kept while the issue exists.
Reporting a vulnerability
Report privately to security@condux.ai, not in a public issue. We aim to acknowledge within three business days, we practise coordinated disclosure, and we will not pursue good-faith research that follows our policy. Our full disclosure policy ships in the repository as SECURITY.md.
Privacy questions and data requests go to privacy@condux.ai.