Security
This page documents the technical and organisational measures Ultron applies to protect customer data. It is referenced by the Data Processing Addendum and is part of our contractual security commitment. The measures evolve over time; the timestamp in the header reflects the current state.
Overview
Security is treated as a property of the system, not a checklist. The platform is designed so that the most sensitive operations (key management, access to production data, deploys) are the most carefully controlled. Less sensitive operations are designed to fail closed if they touch boundary trust assumptions.
The team holds quarterly reviews of the security posture against industry baselines. Material changes (new categories of processing, new datacentre regions, new attack surface) trigger an out-of-cycle review.
Infrastructure
The application runs on Google Cloud Run in the europe-west1 region. The container image is built by Google Cloud Build and stored in Artifact Registry. The Postgres database lives on Supabase in Ireland. Object storage and edge resources live on Cloudflare. The sandbox runs on E2B's managed infrastructure. Every host is hardened to the provider's baseline image and patched continuously through provider updates.
Encryption
| Layer | Algorithm | Where |
|---|---|---|
| In transit | TLS 1.2 or higher with modern ciphers | Every external endpoint, every inter-service hop on the public internet |
| At rest, application database | AES-256 by provider | Supabase Postgres |
| At rest, object storage | AES-256 by provider | Cloudflare R2, Supabase Storage |
| At rest, edge database | AES-256 by provider | Cloudflare D1 |
| Secrets at rest | Sealed in the cloud provider's secret manager, accessed by the application only at runtime | Google Cloud Secret Manager, Cloudflare Workers secrets |
| Passwords | Argon2 or bcrypt hashes only, never plaintext | Authentication provider |
Access control
Least privilege
Production access is granted by role and reviewed quarterly. The default for any new role is read-only. Write access to customer data is restricted to a small set of incident-response and customer-support functions, time-boxed, and logged. No one has standing production write access without a documented business need.
Separation of duties
The person who writes the code is not the person who approves the merge. The person who approves the merge is not the person who provisions the secret. Build and deploy pipelines are automated and audit-logged so a single individual cannot push an unreviewed change to production.
Authentication
End-user authentication is handled by Supabase Auth with email and OAuth providers. Multi-factor authentication is available to all users and enforced on Enterprise plans. Internal authentication for the team uses single sign-on with hardware-backed MFA on every account that can touch production. Service-to-service authentication uses short-lived credentials or signed shared secrets, never long-lived passwords.
Secure development
Every change reaches production through a pull request reviewed by at least one engineer who did not write it. Continuous integration runs unit tests, type checks, lint rules, and a security review job on every PR. Static analysis runs on every push. Dependencies are pinned and updated on a published cadence, with critical security updates fast-tracked. Production builds are reproducible from a tagged commit; the build pipeline is locked down and audited.
Vulnerability management
| Severity | Time to remediate |
|---|---|
| Critical | 48 hours from confirmation |
| High | 7 days from confirmation |
| Medium | 30 days from confirmation |
| Low | 90 days from confirmation |
We accept reports from external researchers through the Responsible Disclosure programme. Internal scans run continuously across the dependency graph and on the container image at build time. Findings are triaged within one business day.
Logging and monitoring
Every administrative action on production data is logged with the actor, the action, the target, and a timestamp. Application logs are stored centrally and tied to a request id you can quote when you contact support. Anomaly detection runs on authentication events, on the rate of failed access attempts, on unusual data volumes leaving the platform, and on cost-anomaly signals. Alerts page an on-call engineer outside business hours for anything above a low severity threshold.
Incident response
Runbook
We follow a documented incident response runbook covering detection, triage, containment, eradication, recovery, and post-incident review. On detection of a likely incident, an incident commander is named and a dedicated communication channel is opened. Customer-facing communication is centralised to avoid conflicting messages.
Customer notification
For a personal data breach affecting customer data, we notify affected customers without undue delay and at the latest within seventy-two hours of becoming aware, in accordance with Articles 33 and 34 of the GDPR. The notification includes the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken or proposed to address it, and a contact point for further information.
Post-incident review
Every significant incident is followed by a written post-mortem that identifies root cause and action items. Action items are tracked to closure. We share a sanitised summary with affected customers on request.
Continuity and recovery
Production data is backed up at least daily. Backups are encrypted, retained for thirty days, and tested for restoration at least quarterly. The recovery point objective for the primary database is twenty-four hours; the recovery time objective is four hours. The application tier is stateless and can be re-deployed from the tagged image within minutes. The disaster recovery plan is reviewed annually.
Personnel
Everyone with access to production data signs a confidentiality agreement and goes through security training before access is granted. Training is repeated at least once per year and after any material change to the threat landscape. Access is revoked within twenty-four hours of an employee's departure.
Physical security
All infrastructure is hosted with cloud providers that operate certified datacentres with physical access controls, environmental monitoring, and on-site security personnel. Ultron team members do not have physical access to any servers that host customer data.
Supplier risk
New subprocessors go through a security and privacy review before they are added. Existing subprocessors are reviewed at least annually. Material findings either lead to a remediation plan with a deadline or to a replacement search.
Compliance
Ultron is operated in line with the GDPR. Our hosting providers maintain certifications including ISO 27001, SOC 2 Type II, and equivalents; current attestations are available from the provider directly. We do not currently advertise an Ultron-specific certification programme but we are working towards SOC 2 Type II and ISO 27001 within our own scope, on a timeline published privately to enterprise customers.