Security

Last updated: 2026-06-07. Effective: 2026-06-07.

This page describes how ZI² Discover protects your data and the data of the sites you scan. We treat security as a product feature, not an afterthought. If you find a vulnerability, please report it to [email protected].

Shared responsibility

Security is a shared responsibility. ZI² secures the platform: infrastructure, the application, encryption, multi-tenancy, sub-processors, and our staff. You secure your account: keep your password strong and unique, enable MFA when available, manage workspace membership, only verify domains you control, and configure fix-applier authority levels you are comfortable with.

Infrastructure

The Service runs on a dedicated bare-metal server (Server B) located in a Tier III data center in Germany. The host operating system is CloudLinux with the Plesk control plane hardened against default credentials, default ports, and unused services.

• Inbound traffic is filtered at the edge by Cloudflare with WAF rules tuned for our endpoints and bot management.
• SSH is restricted to key-only authentication on a non-default port, with fail2ban enforcing rate limits and persistent ban tables.
• System packages and Plesk components are patched on a tracked cadence; critical CVEs get same-day attention.
• Imunify360 protects against known web-layer attacks; PHP and Node runtimes are confined per process group.
• Production credentials are rotated quarterly and on staff change. No shared production accounts.

TLS everywhere

All inbound traffic to discover.zi2.app, the API, and the dashboard is served over TLS 1.3 with modern cipher suites. Certificates are issued by Let's Encrypt and auto-renewed. HSTS is enabled with a one-year max-age and includeSubDomains. Plain-HTTP requests are redirected to HTTPS.

Data at rest

• Postgres data files and write-ahead logs are stored on an encrypted filesystem.
• MinIO object storage (crawl HTML, screenshots, exports) is configured with server-side encryption for object data.
• Sensitive credentials — payment processor secrets, OAuth tokens for connected CMS platforms, AI provider API keys held on behalf of Enterprise customers — are wrapped using ZI² Hybrid: a data encryption key (DEK) is generated per secret, encrypted with AES-256-GCM, and the DEK is itself wrapped with a Kyber post-quantum KEM key. The wrapped DEK is stored alongside the ciphertext; the Kyber private key is held outside the application database.
• Passwords are stored as bcrypt hashes with a per-record salt and cost factor 12 or higher.

Data in transit

Every internal hop between processes uses TLS or a local-loopback socket within the same host. Database connections from the API to Postgres require TLS. Outbound calls to AI engines (Anthropic, OpenAI, Google, Microsoft, Perplexity) and payment processors (Stripe, Paystack, Flutterwave) use HTTPS with certificate pinning where the provider's library supports it.

Authentication

Identity is handled by ZI² Digital ID, our identity service. Sessions are short-lived JWTs signed with EdDSA keys rotated every 90 days. Refresh tokens are stored hashed; revocation is immediate. Email-and-password login uses bcrypt, with throttled attempts and progressive delay on failure. Magic-link sign-in is available; SSO (SAML 2.0 and OIDC) is on the roadmap for Enterprise.

Authorization and multi-tenancy

Multi-tenancy is enforced at the database layer, not the application layer:

• Every tenant-scoped table has a tenant_id column and a Postgres Row-Level Security (RLS) policy.
• The application connects under a role that does not have BYPASSRLS. Any query that forgets to set app.tenant_id returns zero rows by design.
• A scheduled RLS fuzz exercise runs monthly: a test harness attempts cross-tenant reads and writes from a representative set of endpoints. Any leak fails the build.
• Role-based access within a workspace is enforced both in the API and in the dashboard.

Crawler safety

The scanner is the most powerful and the most dangerous part of the Service. We treat third-party sites as adversarial:

• Ownership verification is required before deep crawl. Light reachability checks may run on the marketing-facing URL; nothing more.
• robots.txt is respected, including User-agent: ZI2DiscoverBot rules. Our user agent identifies itself and links to documentation.
• Polite per-host concurrency with a token bucket sized from Crawl-delay directives and adaptive back-off on 429/503.
• SSRF defense: the crawler resolves URLs through a DNS resolver that filters private, loopback, link-local, and metadata-service IPs before any TCP connect. Redirects are re-validated.
• Resource limits on response size, render time, and total artifacts per page.
• Complaints from a target site can have a customer's crawl rights revoked while we investigate.

LLM prompt-injection defense

AI agents in the Service consume signals from your sites; agents are well-known targets for prompt injection through crafted content. Our defenses:

• Agents never receive raw HTML. They receive structured, typed signals extracted by deterministic, pure-function rules. Free-form text from a page is wrapped in a clearly delimited envelope and labeled "untrusted".
• Agent outputs are schema-validated against a JSON Schema next to the agent definition. Outputs that do not validate are dropped, not retried with the same prompt.
• Agent fixers are never authorized above their rule severity gate. A low-severity rule cannot produce a high-impact change. See ADR-0008 for the authority table.
• Outbound tool calls available to agents are whitelisted per agent; the broad "internet access" tool is not.
• AI probe budgets are per-tenant, per-day, with deduplication by canonical query hash to prevent runaway spend.

Audit logging

Every state-changing event — auth, billing, site verification, scan start, fix apply, role change, sub-processor change — writes to an append-only audit_log table partitioned by month. Records are retained for 7 years. Enterprise customers can export their tenant's audit log on request and via API.

Backups and disaster recovery

• Nightly Postgres logical and physical backups, plus MinIO bucket snapshots.
• Weekly full server snapshots.
• 90-day retention with monthly archives held for one year.
• Restoration is tested at least quarterly with a documented runbook.
• RPO target: 24 hours. RTO target: 8 hours for tenant-impacting outages. These are targets, not SLAs absent an Enterprise order.

Incident response

We classify incidents on a four-tier severity scale:

• SEV-1: data exposure, total outage, or active attack. Paged immediately. Customers notified within 24 hours of confirmation, regulators within 72 hours where GDPR Article 33 applies.
• SEV-2: partial outage or significant degradation. Status page updated within 30 minutes.
• SEV-3: minor degradation. Tracked and communicated in the next release notes.
• SEV-4: known issue, low impact. Logged.

Every SEV-1 and SEV-2 incident gets a written post-mortem with root cause, contributing factors, and corrective actions, published to status.zi2.app within 10 business days.

Responsible disclosure

We welcome security research conducted under a responsible disclosure agreement. Report findings to [email protected]. We will acknowledge within 2 business days and aim to triage within 5. Do not run automated scanners against production without prior coordination; do not access data that is not your own; do not degrade service for other customers. Researchers acting in good faith under these guidelines will not face legal action from ZI².

Secrets management

Application secrets — database passwords, sub-processor API keys, signing keys, Kyber private keys — live outside the application code and outside the repository. Production secrets are held in a dedicated secrets store on Server B, mounted into application processes by systemd unit drop-ins or container init. Secrets are never logged. Where a secret must be displayed in the dashboard (for example, a freshly issued API key), it is shown once at creation and then only ever stored as a hash.

Sub-processor keys held on behalf of Enterprise customers — for example, a customer-supplied Anthropic API key used for higher rate-limit AI probes — are wrapped using ZI² Hybrid before storage and are unwrapped only at request time.

Software supply chain

• Dependencies are pinned in lockfiles and reviewed during dependency upgrades.
• We monitor for advisories on the libraries we use and patch on a tracked cadence.
• The build pipeline runs unit, integration, and end-to-end tests; the production deploy will not start if tests fail.
• Static analysis (typecheck, linter, secret scanner) gates merges to the main branch.
• Container and binary artifacts deployed to production are produced by the pipeline, not by individual developer machines.

People and access

• Only named staff have access to production. The list is documented and reviewed quarterly.
• Production access is logged. Access is granted on a least-privilege basis and removed on role change.
• Engineers complete an annual security awareness review covering phishing, credential hygiene, and incident handling.
• Background checks are conducted where legally permitted before granting production access.

Data deletion on request

You can request deletion of your Customer Data at any time from the dashboard or by emailing [email protected]. Confirmed deletion requests are propagated within 30 days across the primary database, MinIO, search indexes, and cache layers. The audit-log record of the deletion request itself is retained for the legal periods stated in the Privacy Policy.

Compliance

• GDPR: we implement Article 32 technical and organizational measures and process EEA/UK personal data under SCCs where the recipient is outside an adequate jurisdiction. See the Privacy Policy.
• CCPA / CPRA: we honor consumer rights and do not sell or share personal information.
• SOC 2 Type II: targeted for month 12 of public availability. Type I report and Trust Services Criteria mapping available to Enterprise prospects under NDA.
• EU AI Act: we monitor obligations applicable to providers and deployers of general-purpose AI systems for the components we integrate with.

Contact

Vulnerability reports: [email protected].
Privacy and DSAR: [email protected].
General: [email protected].

See also: Terms · Privacy · Acceptable Use · DMCA · Cookies