Security
Last updated: May 2026 · Version 2.0
Our approach
Security is a continuous practice, not a checkbox. Engineers of AI designs the Service to minimize the personal data collected, encrypt everything in transit, and limit the blast radius of any single failure. This page describes our technical and organizational measures (Art. 32 GDPR) and how to report security issues.
Operator
Infrastructure
- Hosting: the Site is delivered as a static build via Netlify's global CDN. There is no server-side application accepting user input at our perimeter beyond Netlify Forms.
- TLS: all traffic is served over TLS 1.2 or higher. HTTP requests are redirected to HTTPS. We use HSTS to prevent downgrade attacks.
- HTTP security headers: Content-Security-Policy (with nonced sources), X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy locking down camera, microphone, and geolocation.
- Build pipeline: source lives in a private repository. Changes go through code review and CI before deploying. Production deploys are gated and auditable.
- Authentication: account access is brokered by Keycloak via OIDC. We do not store passwords. Tokens are short-lived and validated server-side.
- Secrets management: API keys and credentials are stored in CI secret stores, never committed to the repository. We rotate them on schedule and on suspicion of exposure.
Encryption
- In transit: TLS 1.2+ (ECDHE + AES-GCM or ChaCha20-Poly1305) between the user and our CDN, and between our CDN and all subprocessors.
- At rest: form submissions, account data, and analytics data are encrypted at rest by their respective processors (Netlify, Substack, Google, Keycloak) using AES-256 or equivalent.
- Backups: static site builds are reproducible from source. Form submissions and account data are subject to the backup policies of their processors.
Data minimization
- We collect only what is needed for the purpose described in the Privacy Policy.
- IP addresses captured by analytics are anonymized before storage.
- Server logs are retained ≤ 30 days.
- Contact form submissions are retained ≤ 24 months unless an ongoing conversation requires longer.
Subprocessors and Data Processing Agreement (DPA)
We engage carefully vetted subprocessors under Art. 28 GDPR. The current list of subprocessors and a copy of our Data Processing Agreement (Auftragsverarbeitungsvertrag, AVV) are available on request from [email protected].
For transfers outside the EEA we rely on:
- The EU-US Data Privacy Framework where the recipient is certified;
- Standard Contractual Clauses under Commission Implementing Decision (EU) 2021/914;
- Supplementary technical and organizational measures (encryption in transit and at rest, access controls, audit logging) as required by the Schrems II ruling (C-311/18).
Access control and operational security
- Production access follows the principle of least privilege.
- Administrative accounts require multi-factor authentication.
- Access reviews are performed periodically and on personnel changes.
- Sensitive operations are logged for audit purposes.
- We do not use production data for development or testing.
Incident response
We maintain a documented incident response procedure. In the event of a confirmed personal data breach affecting users' rights and freedoms:
- We notify the competent supervisory authority (Der Sächsische Datenschutzbeauftragte) within 72 hours of becoming aware, as required by Art. 33 GDPR.
- We notify affected users without undue delay when the breach is likely to result in a high risk to their rights and freedoms (Art. 34 GDPR).
- We document all incidents, even those not subject to notification, in our internal breach register.
Responsible disclosure
If you discover a security vulnerability affecting the Service, please report it privately to [email protected] with the subject line "Security Report".
Please include:
- A clear description of the issue and potential impact.
- Reproduction steps or proof of concept.
- Your contact information so we can follow up.
- Whether you want to be credited publicly.
Our commitments to researchers
- Acknowledge your report within 3 business days.
- Provide an initial assessment within 10 business days.
- Keep you informed as we work on a fix.
- Credit you publicly if you wish, once the issue is resolved.
- Not pursue legal action against researchers who comply with this policy in good faith.
Safe-harbor scope
Good-faith security research that complies with this policy is considered authorized under § 202a and § 202c StGB (German Criminal Code). To stay within scope you must:
- Not access, modify, or delete data that does not belong to you beyond what is strictly necessary to demonstrate the issue;
- Not degrade, disrupt, or test the Service's availability (no DoS);
- Not exfiltrate data;
- Report findings only to us until the issue is resolved.
We do not currently offer monetary rewards but we are happy to provide public credit and references.
Out of scope
The following are generally out of scope:
- Vulnerabilities in third-party services we use (report to the vendor directly).
- Denial-of-service attacks or volumetric tests.
- Social engineering of Engineers of AI personnel or contractors.
- Physical security issues.
- Reports based purely on automated scanner output without verified impact.
- Missing security headers without demonstrated impact.
- Self-XSS or issues that require an already-compromised browser.
Business continuity
The Service is a static site rebuilt from source. In the event of a primary hosting outage, the build can be redeployed to an alternate CDN. Source code and content are mirrored. We do not commit to a contractual SLA for the free tier of the Service; for any Paid Service, the applicable SLA is published with the service.
Contact
Security questions, vulnerability reports, or to request the current subprocessor list and DPA:
[email protected]
