Security

This page describes what Zuse does now. It is kept deliberately literal: if a control is not listed under "In place", assume it does not exist yet and ask.

In place

API keys

• Keys are stored only as SHA-256 hashes. The full key is shown once, at creation, and cannot be retrieved afterwards.
• Keys can be revoked at any time. Revocation takes effect on the next request.
• A key authenticates both the REST API and the MCP server.
• A key is checked on every request, before anything else runs, and is read only from the Authorization header, never from the URL.
• Repeated wrong keys from one address block that address for 15 minutes.

Transport

• The API is served over TLS only, and responses carry Strict-Transport-Security.
• Billed responses are sent with Cache-Control: no-store, so nothing between you and Zuse keeps a copy.

Rate limits and abuse controls

• Limits by address, by account, by operation and by day, with 429 and Retry-After when one is reached. See Rate limits and retries.
• An account that runs into the limits repeatedly is restricted automatically, and we are alerted.

Sign-in

• Console sign-in is handled by WorkOS using Google single sign-on. Zuse does not store passwords.
• The console session is an HTTP-only, signed cookie.

Your queries

• What you search for is kept in one place: your team's request history, which the console shows you. Each line is deleted after 30 days, and only members of your team can read it.
• The names, license numbers, ZIP codes, and coordinates you search are not written to the usage record or to application logs. Query strings are stripped from the access log.
• Each usage record holds the operation, the charge, how many records came back, and, for a location search, a keyed fingerprint of the search area (the center, rounded to about a mile). Those last two exist to enforce the daily limits. The ZIP code and coordinates themselves are not stored.
• When a limit is tripped, the event is recorded with the account and the calling address.
• A response sent with an Idempotency-Key is stored for 24 hours so a retry can be answered without being charged again. It is deleted after that.
• What Background and Intro notes find is kept on the records of the team that asked, so the same person is not researched, or charged for, twice. It is read only by that team and is deleted with the team's account.
• License check and Nearby are answered entirely from the Zuse index. Nothing about the query leaves Zuse.
• Background is different: the person's details are sent to a web-research provider to run the search. See "Subprocessors".

Isolation

• API keys and usage records are scoped to a team. Someone outside a team cannot list, use, or see the usage of that team's keys.

Data integrity

• Verified records trace to a licensing board, and each match links to the board's public lookup.
• Every ingest is snapshotted and diffed, and a malformed download is rejected rather than applied.
• Web-derived fields are returned in a separate layer marked "layer": "derived".

Not in place yet

• Third-party certification. Zuse does not hold SOC 2, ISO 27001, or HIPAA attestations.
• SAML single sign-on, SCIM provisioning, and role-based access within an account.
• IP allowlists and key scopes. Rate limits are per account, not per key.
• A customer-facing audit log.

If one of these is a requirement for you, tell us. It helps us order the work.

Subprocessors

Zuse is run by Zuse Live Inc. (Delaware). It shares service data only with these providers, each for the purpose listed.

The Privacy policy has the full account of what is collected and kept.

Reporting a vulnerability

Email security@zuse.live with the details and steps to reproduce. Please do not open a public issue for a security report.