Trust and data handling
Checked against our code and configuration on Oct 30, 2026.
What the OpenWAF edge sees when it terminates TLS, what it keeps, for how long and where, who can reach it, and how to keep the sensitive parts of your product away from it. Every statement here is checked against our code and configuration, and the limits are listed too.
In short
Is it in production? Is there an SLA?
OpenWAF is in production in front of real sites. There is no SLA yet. Live status, the uptime of each component over 90 days and the incident history are public at status.openwaf.dev, measured every minute from Cloudflare’s network, outside our servers.
What is the licence? Which version runs?
OpenWAF Cloud is a proprietary managed service. Its open-source parts (Verify, Egress, Egress Action) are Apache-2.0 on GitHub. The edge and the control plane are deployed continuously; every change is dated in the public changelog. See licence and versions.
Are the numbers marketing?
Every number on this site is counted in our code or documentation and links to where you can check it: see where every number comes from. We publish no traffic or customer figures.
It terminates TLS: what does it see and keep?
It sees the requests to the names you proxy. It records security events (no bodies, cookies or Authorization headers) and deletes them after 30 days, in Germany. Names you leave DNS-only, such as a data room or a signing subdomain, never reach it. See what the edge keeps and how to keep parts out.
Do I have to hand over my DNS?
No. Delegate your nameservers, or keep your DNS where it is and point only the names you choose at OpenWAF with a CNAME. You can put one subdomain behind OpenWAF and leave everything else as it is.
What the edge sees and what it keeps
On a proxied name the edge terminates TLS: it decrypts each request to inspect it (WAF, rules, bots) and encrypts it again towards your origin. Seeing a request is not storing it. This is everything the service keeps about your visitors’ traffic:
| Data | What it contains | Kept |
|---|---|---|
| Security events: a request blocked, challenged or logged by a rule | Time, client IP, country and ASN, host, method, path without the query string, status, rule id and name, a short message about the decision (never request bodies), user agent and TLS fingerprint | 30 days |
| AI agent events, only with Bots and AI agents switched on | The same request fields, the bot and how it was verified. For AI endpoints and MCP Shield: the id of each detector that matched and the matched text, up to 160 bytes (credentials found by MCP Shield keep only their first 4 characters), the MCP method and tool name, and a fingerprint of the token (the first 8 bytes of its SHA-256, never the token) | 30 days |
| Core Web Vitals, only with real-user monitoring switched on | Host, path, page timings, device type, country, traffic source and a visitor id that changes every day; no IP address and no user agent | 30 days |
| OpenWAF Verify statistics | Counts per time window (challenges issued, solved and failed, solve times); no individual requests | 30 days |
| Edge cache, off by default | Cacheable responses (static files unless you add rules), on the edge nodes. Responses with Set-Cookie, private or no-store are never stored, and personal documents (PDF, Office files, archives) requested with a cookie or an Authorization header only if your origin sends explicit freshness | Until they expire or you purge them |
| Edge node process log | Diagnostic lines for blocked requests (IP, host, path, reason), on that node only. Of the query string only the parameter names are written (?token=…&email=…), never their values; earlier versions wrote the whole query string, and those lines were deleted with the containers this version replaced | Capped at 5 files of 50 MB per proxy container; deleted when the container is replaced at each update |
| Configuration and audit log | Your zones, records and settings, every version, and who changed what and why | While the account exists, then up to 30 days |
Never recorded: request or response bodies (apart from the matched text above and the cache), cookies, Authorization headers, form fields and passwords. Database backups are kept 90 days and system backups at most 6 months; after you close your account your data are deleted from live systems within 30 days, as set out in the Data Processing Agreement.
Keep sensitive parts away from the edge
You decide, name by name, what goes through OpenWAF. For an investor data room, a document-signing service or any name whose traffic you don’t want a third party to decrypt:
- Leave the name DNS-only. A DNS-only record is answered exactly as you write it and visitors connect straight to your server: no TLS termination, no inspection, nothing recorded by the edge. See proxied and DNS-only records.
- Keep your DNS elsewhere. In an external zone your DNS stays with your provider and only the names you point at OpenWAF with a CNAME (or an A record at the apex) go through the edge. See external zones.
- Tune a proxied name or path. Each name can have its own WAF mode and level, including
log(record, never block) andoff, and a WAF exception switches rules off on a path such as/upload/*. See per-name settings and WAF exceptions. - Leave the cache and real-user monitoring off, as they are by default, on names that serve private documents.
- Challenges without third parties. OpenWAF Verify is served from your own host. Its browser challenge sets one first-party cookie,
__waf_pass, signed with HMAC-SHA256 and holding only its expiry, the visitor’s network prefix (/24 or /64), its scope and when it was issued. There is no third-party script, iframe or cookie.
TLS certificates and keys
- Certificates for proxied names are issued automatically by Let’s Encrypt, from our control plane, and renewed 30 days before they expire; you can upload your own instead. Let’s Encrypt only receives the host names.
- Certificate private keys, ours and uploaded ones, are stored encrypted with AES-256-GCM. They reach the edge nodes inside the configuration document, which is signed with Ed25519 and sent over TLS. Each node keeps its last applied document in a file with owner-only permissions (0600), so it can restart without the control plane.
- Towards your origin:
fullencrypts,full_strictalso verifies the origin’s certificate (the default for new domains). The OpenWAF Origin CA issues origin certificates for up to 15 years from your own CSR, or from a key it generates, returns once and never stores. - With authenticated origin pulls each edge node presents a client certificate (ECDSA P-256, valid 30 days and rotated automatically), so your server can refuse every connection that doesn’t come from OpenWAF.
- Hybrid post-quantum key exchange (X25519 + ML-KEM-768) is preferred towards visitors and towards origins.
Details: edge certificates, origin TLS, Origin CA.
Where the data is and who can reach it
- Location. Control plane, databases, DNS servers and backups in Germany (Hetzner). Edge nodes in Germany (Hetzner) and Madrid, Spain (Vultr); events from the Madrid node are stored in Germany.
- In transit. TLS from visitors to the edge and from the edge to HTTPS origins; edge nodes fetch their configuration and send their events over HTTPS, each configuration document signed by the control plane and each event batch signed by its node; zone transfers between our DNS servers are signed with TSIG.
- At rest. Certificate and ACME account keys, Origin CA keys and the edge client keys are encrypted with AES-256-GCM; provider keys and infrastructure secrets live in a secrets manager (OpenBao); file-system backups are encrypted before they leave the server. The event and configuration databases are not encrypted at the database level; they are reachable only from our own hosts.
- Who on our side. Only OpenWAF platform operators: SSH with keys only, two-factor authentication always on their dashboard accounts, and secrets access through per-host roles with an audit log. AI Services LLC is a US company and its staff may access data from outside the EEA, under the EU Standard Contractual Clauses.
- Who on your side. Members and API tokens with roles, limited to one client or one domain if you want; every change carries a reason and is in your audit log.
Sub-processors
| Company | Where | What for |
|---|---|---|
| Hetzner Online GmbH | Germany | Control plane, databases, DNS, German edge nodes, mail, backups |
| The Constant Company (Vultr) | Madrid, Spain | The Madrid edge node |
| Cloudflare, Inc. | USA and its network | DNS of openwaf.dev and a proxy in front of this website, the dashboard, the control-plane endpoint our nodes use (configuration documents, including certificate keys, pass through it in transit) and the AI egress endpoint. Your visitors’ traffic to proxied names does not go through Cloudflare. |
| Let’s Encrypt (ISRG) | USA | Issuing certificates; receives host names only |
We tell customers by e-mail at least 30 days before adding or replacing one. Full list: Sub-processors.
Who operates OpenWAF
OpenWAF Cloud is operated by AI Services LLC (trade name OpenWAF), 99 Wall Street #2351, New York, NY 10005, USA. For your visitors’ traffic we act as a processor under the Data Processing Agreement (PDF), which you accept when you create your organization; transfers outside the EEA rely on the EU Standard Contractual Clauses. See also the Privacy Policy and the Legal Notice.
Licence and versions
OpenWAF Cloud (the edge, the control plane, the dashboard, the API and the MCP server) is a proprietary managed service: you use it, you don’t install it. These parts are open source:
| Component | What it is | Licence | Latest release |
|---|---|---|---|
| openwaf-dev/verify | OpenWAF Verify client: proof-of-work widget, protocol and siteverify libraries | Apache-2.0 | v0.1.0 |
| openwaf-dev/egress | OpenWAF Egress, the outbound gateway for AI agents | Apache-2.0 | v0.2.2 |
| openwaf-dev/egress-action | GitHub Action that puts a CI job’s outbound traffic behind an allowlist | Apache-2.0 | v0.3.2 |
The WAF engine is Coraza with the OWASP Core Rule Set 4.25, both open source (Apache-2.0). The edge and the control plane have no version numbers: they are deployed continuously from their main branches, each deployment identified by its git commit, and every change customers can see is dated in the changelog.
Status, SLA and what we don’t have yet
status.openwaf.dev shows the live status of the website, documentation, dashboard, API, MCP server, edge network (Germany and Spain), authoritative DNS, Verify and AI egress, with uptime over 30 and 90 days, response times and the incident history (Atom and RSS feeds). It is measured every minute by probes on Cloudflare’s network and hosted on Cloudflare Pages, apart from our servers.
- No service level agreement (SLA) yet.
- No SOC 2 report: SOC 2 Type I readiness is in progress and no audit has been performed.
- No ISO/IEC 27001 certificate: our ISMS is aligned with ISO/IEC 27001:2022, and the certification audit has not been performed.
- No independent penetration test report.
Controls in place today and how to report a vulnerability: Security.
Where every number comes from
Every number on this site and in our llms.txt comes from one file, with the date it was counted (Oct 30, 2026) and a public page where you can check it.