API Privacy Notice

You send us identifiers about a person. We look them up in sources we can reach. We return an answer. Most of what follows is detail on that sentence, but four things are worth knowing before the detail, and one of them is uncomfortable.

First: which endpoint you called changes where the data goes, and we are not going to blur the two together.

• ⭐ A Verification reaches exactly one third party — the search provider — and makes zero model calls. No enrichment vendor. No breach vendor. No court-records source. No username site. One site:-scoped query, one recipient, one answer.
• A Scan reaches more. In addition to the search provider it may reach identity enrichment, breach and stealer-log lookup, court records, and public username pages, and it uses model inference on tokenized data for parts of its adjudication and phrasing.

Second: some of what a Scan reaches is data we pay for. The identity-enrichment vendor and the breach-corpus vendors are commercial subscription data, not public web pages. That is true, it is in Section 5, and it is stated there rather than softened.

Third: what we keep, in three cases. A synchronous Verification or Scan does not persist the identity you sent or the answer we returned. An asynchronous job holds both for 24 hours, then the sensitive columns are emptied. And every authenticated call writes one activity row — who called, which endpoint, how long it took, what it billed — containing no request body and no response body, and therefore nothing about the Subject. That row has no expiry today. We would rather write that sentence than tell you we keep nothing.

Fourth: two commitments that are permanent. We do not sell the Identifiers you send us or the Output. We do not use them to build, seed, train, or enrich a separate product or a people database. Those two are floors, not snapshots, and a later version of this notice will not weaken them retroactively for data already collected.

This notice covers the Sirveil Exposure API — every call to POST /api/v1/verify, POST /api/v1/scan, GET /api/v1/jobs/{id}, GET /api/v1/whoami, and the read-only agent surface at POST /api/v1/mcp — and the account and billing data that goes with it.

It does not cover the Sirveil consumer application, which has its own separate Privacy Policy. That policy is not modified by this one, and this one does not govern the app.

Where this notice and the Terms differ on a subject the Terms address, the Terms control (Terms Section 3). Where this notice and any Sirveil marketing surface, listing, or datasheet differ on what the Service does with data, this notice controls. Section 5 says so specifically, and says why.

The service-provider terms are in the agreement itself. Section 8 of the API Terms of Use carries the covenants the California Consumer Privacy Act requires of a service provider — no sale, no sharing, no use outside the stated business purposes, no combining with other sources, notice to you if we can no longer meet those obligations, and your right to verify and to stop and remediate. No separate data processing addendum is needed for Sirveil to act as your service provider. Where your own regulator or customer requires an addendum on their paper, write to [email protected] and we will review it.

From a call — about the Subject

Required, on both endpoints: firstName and lastName. A Verification additionally requires a domain. The name is the anchor every candidate record is scored against; without it the Service has no way to tell whether the record it found is the right human being. A request missing a required field is refused with 400 identity_incomplete before any lookup runs and before anything is charged.

Optional, and entirely your choice: phone number, email address, street address, city, state, date of birth, and one or more usernames. The more of these you send, the more the query planner has to work with — it leads with a held identifier where it has one, in the order phone → email → street address → name. Supplying a username is what switches on the username lane at all; the Service does not guess a handle from an email address.

A field we cannot parse is dropped rather than guessed at, and the name of the dropped field is returned to you in dropped_fields.

What you must not send. Passwords, password hashes, session tokens, full payment-card data, government-ID images, face images, face embeddings, biometric templates, and data from a breach or dump you have no lawful right to hold. That is Terms Section 7(4) and Section 4.4 of the AUP, and it is a contractual prohibition, not a filter — the Service does not inspect your payload for prohibited content and will not catch it for you.

From every call — for metering and abuse prevention

Every authenticated call writes exactly one activity row, from the Service's own accounting path. It contains:

• the account and the key that made the call (the key by its stored identifier, never its secret);
• the endpoint, the timestamp, the HTTP status, and the latency;
• the billable units and the outcome (served, unserved, refused);
• an internal run identifier, which is what makes an answer traceable to the logic that produced it; and
• an internal cost figure of Sirveil's own — what the attempt cost us, not a price to you, and not information about the Subject.

⭐ It contains no request body and no response body. No Identifier and no Answer is written to it. That row is the billing record, and an invoice you can audit depends on it existing.

Refusals are accounted for too, and honestly. An authenticated call that is refused writes a row with an outcome of refused, a refusal code, zero billable units, and a null cost — deliberately null rather than zero, because zero would assert a measurement we never made. An unauthenticated refusal — a missing or invalid key — writes no row at all, because the table is keyed on an account; that volume exists only in ordinary request logs.

About your account

A business email address, an organization name, the records of the keys we issued (a hash, a short non-usable prefix, and a revocation state), and the invoice ledger.

Billing is handled by your purchase channel. Payment is taken by that channel and we never see or store card numbers.

This is the section a security reviewer should read first, and it is the section most privacy notices for a service like this get wrong by averaging two different products into one sentence. We are not going to do that.

A Verification reaches exactly one third party and makes zero model calls. One site:-scoped query to the search provider, and it stops there. A failover search provider may stand in where the primary fails; that is the same single category of recipient and the same single call, not an additional one. Nothing about a Verification reaches an enrichment vendor, a breach vendor, a court-records source, a username site, or a model.

A Scan reaches more, and some of what it reaches is data we buy. The identity-enrichment vendor is a purchased-data enrichment service. The breach and stealer-log corpora are commercial subscription services. These are paid vendors, not public web pages, and a Scan queries them on your behalf.

⛔ This Section controls over any contrary statement on a Sirveil surface. If a Sirveil marketing page, listing, or datasheet says or implies that answers come from publicly indexed pages only, with no purchased data about your subjects, that statement is accurate for a Verification and is not accurate for a Scan, and this Section is the one that describes the Service. The correction to those surfaces is tracked in Section 15 as a conforming change.

Breach-lane vendors report whether, not what. The breach and stealer-log lane returns whether an identifier appears in a corpus. Nothing in the product uses, returns, replays, or tests a breached credential, and nothing in the product logs in anywhere, solves a captcha, or circumvents an access control. AUP Section 6 describes that conduct in full.

The username lane behaves. It requests only public profile URLs for a handle you supplied. It fetches, parses and honors robots.txt, failing closed — treating a 401, a 403, a 5xx, a timeout, and an unparseable file as Disallow. It sends an honest identifying user agent with a contact URL, performs zero retries, and truncates at 32 KB.

5.1 The PII firewall — what it protects, and the gap it does not close

Before any model call, sensitive values are replaced with placeholders: a name becomes PERSON_1, a phone number becomes PHONE_2, an address becomes ADDR_1. The protected class is name, phone number, email address, street address, date of birth, government identifier, and exact geolocation — none of these may reach the model layer.

The control is not a convention. A check runs on the outbound payload, and if a raw protected value has survived tokenization the check throws and the outbound call is aborted rather than sent, with a per-call trace recorded. A model call that would have carried a real identifier does not happen; it fails.

Model routing is pinned to a US-host allowlist, configured with data collection denied and zero data retention requested on every provider. Providers hosted outside the United States are excluded by policy. Section 12 carries the open question about the standing of that policy.

⭐ The gap, stated because you would find it anyway. Tokenization protects the model path only. The retrieval vendors — search, identity enrichment, breach and stealer-log lookup, court records — necessarily receive the Identifier in clear text, because that is what a lookup is. There is no way to ask an index whether a phone number appears on a page without sending the phone number. We are not going to pretend otherwise, and a vendor who tells you their retrieval works differently is describing a different operation.

This describes how the Service operates; it is not a warranty. Terms Section 15 states what Sirveil warrants and Section 15.1 states what Sirveil does not have. And note the asymmetry that follows from Section 5: because a Verification makes no model calls at all, this firewall is not exercised on a Verification — there is no model path on that endpoint to protect.

We use the Identifiers you submit solely to run your query against the sources the Service is built to query, to shape the answer, and to return it to you.

We use activity and account data to bill accurately, to enforce the limits described in Terms Section 11.1, to prevent and investigate abuse under the AUP, to support you, and to measure our own performance.

We do not:

• sell the Identifiers you submit or the Output;
• share them for cross-context behavioral advertising;
• use them to build, seed, train, or enrich a separate product or a people database;
• enrich or append the identities you send us for our own purposes;
• combine them with data from another source except as needed to answer your call; or
• use your query patterns to compete with you or to inform anyone else's product.

The first three are permanent as to data already collected, and a later change to this notice will not weaken them retroactively. As to the rest, we will not weaken them for data already collected without your consent. None of this stops us using aggregated, de-identified signals about abuse, security, and performance to run and protect the Service.

A cached answer is still processing, and it is still billed. A short-lived query cache holds normalized query text — which contains the Identifier — in memory only, partitioned by account, for minutes rather than hours. Serving from it is still processing of the Identifier, and Terms Section 10 says plainly that a cache hit bills and consumes quota exactly like a fresh call. Neither document buries that.

⛔ The activity row, stated honestly. There is no expiry column on that table and no purge routine. That is an unresolved decision, not a designed choice — nobody chose indefinite retention for that row; indefinite is what exists because no period was ever set. A stated period would be better disclosure than this paragraph, and setting one is on the list. Until it is set, this is what is true, and we would rather say so than write that the API accumulates nothing.

We do not keep asynchronous results as a convenience archive. When the 24 hours are up, the identity and the result are gone and there is no restore. A poll after expiry returns an explicit result_expired, not a silence you would have to interpret.

Revocation does not delete a key row. Revoking a key sets a revocation timestamp; the row stays, so historical usage can always name the key that produced it. That is deliberate — it is what makes an invoice auditable — and it is described in Terms Section 5.

We disclose subprocessors by category rather than by name, because a named list is also a map of our supply chain and it goes stale the moment a vendor changes.

The categories are: search and retrieval · identity enrichment · breach and stealer-log lookup · court records · model inference · username probing · cloud infrastructure and database hosting · billing and payment channels.

Section 5 states what each category receives. Each is engaged under contract to use the data only to provide its service to us.

The current list of named subprocessors is available on request at [email protected], and we will provide it to a Marketplace reviewer or an enterprise buyer under a confidentiality undertaking. We will give notice of a material change to the categories. Sirveil may add, remove, or replace a subprocessor within these categories.

Two shapes worth naming, without naming the vendor. For some breach-corpus sources, an email address appears in a request URL path rather than as a hashed or k-anonymized lookup — that is the vendor's interface, not our choice, and it is disclosed here because a security reviewer will want to know. And model-inference vendors receive tokenized placeholders only, behind the fail-closed control in Section 5.1.

Vendor names are deliberately not printed here — a published list is also a map of our supply chain. They are available to you on request at [email protected].

Keys. An API key is generated from 192 bits of randomness from a cryptographically secure generator. It is stored as a SHA-256 hash only, together with a short non-usable prefix for identification. The plaintext is displayed exactly once, at issue, and is never stored — we cannot recover it, re-display it, or email it to you. An account may hold a maximum of ten unrevoked keys. Revocation never deletes the key row.

Database access. Row-level security is enabled on the account, key, activity and job tables with an empty policy set — the safest policy set for a billing table is the empty one — and access is service-role only. Supporting operational tables additionally carry explicit revokes from the anonymous and authenticated database roles.

Responses are built by whitelist. Both public response shapers build every field explicitly and never spread an internal object, so vendor names, internal cost figures, model identifiers, build identifiers, raw scoring inputs, and provider-configuration flags cannot reach a customer payload by being added upstream. An independent gate asserts that no vendor name, cost field, or build identifier appears in a Scan response.

Cross-tenant correlation resistance. The internal correlation label — a stable hash over a Subject's identifiers, which would otherwise be identical across two accounts querying the same person — is dropped before a response is built. Scan identifiers and card identifiers are minted per response. Match probabilities are rounded, so internal cluster boundaries cannot be recovered from a distribution of answers. Two customers querying the same person cannot learn that fact from anything the Service returns.

Tenant isolation. A job identifier belonging to another account returns 404, never 403 — we do not confirm the existence of someone else's job.

Encryption, stated exactly. Data is encrypted in transit with TLS. Encryption at rest is provided by our hosting and database platforms and has not been independently confirmed in either vendor console. There is no application-level field encryption, and nothing in the product claims otherwise.

⛔ No certifications, no audit, no penetration test. Sirveil holds no SOC 2 report, no ISO 27001 certification, and has not had a third-party penetration test, and holds no other security or privacy certification, attestation, or audit report for the Service. Terms Section 15.1 states the same thing and states it as a term. If your organization requires one as a condition of purchase, the answer today is that we do not have one — ask before you subscribe.

Incidents. We will notify you without undue delay after we confirm a security incident affecting data you submitted or your account, and will give you the information you reasonably need for your own notification duties. We do not state a fixed hour count here. A number in a published notice is a commitment measured against operations, and we would rather give you a real one in a negotiated agreement than a round one on a web page. Ask, and it is negotiable.

Yours, as the customer

Ask us for a copy of what we hold about your account, correct it, or delete it, at [email protected]. We respond within 30 days of a verified request, at no charge.

Two honest limits. The per-call activity row described in Section 4 is the billing record; we retain it, and Terms Sections 8 and 19 say so. Key rows are not deleted on revocation, by design. Neither contains an Identifier or an Answer.

Your Subjects'

A person whose Identifiers you submitted deals with you first. You are the controller, you know why the query was run, and you hold the relationship. That is not a deflection — it is the allocation in Section 3, and it is the one the law contemplates.

⭐ The honest limit, said plainly: Sirveil generally holds no dossier to disclose or delete for a Subject. A synchronous call persists neither the identity submitted nor the answer returned. The activity row contains no Identifier, so it cannot be searched by Subject at all — there is no per-Subject store to look in. A request to "delete everything you hold about me" usually has nothing to act on, and we will say that rather than perform a deletion ceremony over an empty set.

What we can actually do for a Subject:

• tell them we act for a business customer, and explain this role honestly;
• refer them to that customer where we lawfully can;
• assist that customer in responding, on their instruction;
• where an asynchronous job containing their identifiers is still inside its 24-hour window, purge it early on our customer's instruction — this is the one case where there is something to delete. We will not confirm to a third party that a particular person has been the subject of a query; that is our customer's information, not ours to disclose; and
• point them to their own rights against the source — the site or broker that published the data, which is where the data actually lives — and to the Sirveil consumer application, which is built for a person checking their own exposure and is priced for it.

As a service provider we do not decide what our customer keeps, and we do not act on a request about a customer's processing without that customer.

A Subject can reach us at [email protected]. We read those.

What we do with a request that reaches us directly. We will (a) tell the Subject, promptly, that Sirveil processed the request on a customer's instruction and that the customer holds the record; (b) forward the request to that customer where we can identify them, rather than merely referring the Subject onward; and (c) where we genuinely hold nothing responsive, say so plainly rather than performing a deletion of something that does not exist. We will not knowingly leave a Subject with nowhere to go.

The Service is not for looking up minors. You may not submit the Identifiers of a person you know or reasonably should know is under 18.

⛔ The Service does not screen for age and performs no date-of-birth boundary check; this representation is the control, and it is yours. Nothing in this notice or in the Terms obliges Sirveil to detect, verify, or refuse an Identifier relating to a minor, and nothing here should be read as describing a control that exists. Terms Section 7 states this in the same words.

The Service is offered in the United States only, and data is processed in the United States. Model routing is pinned to a US-host allowlist by configuration, with providers hosted outside the United States excluded by policy.

We do not currently offer the API in the EU or UK and make no cross-border transfer commitments for it. If that changes, a data processing addendum with transfer terms comes first — not after.

A Marketplace listing is visible worldwide even though this offer is not. The Service is offered to, and the Terms are written for, customers established in the United States, and it is processed in the United States. If you are established outside the United States, the Service is not offered to you and you should not subscribe; where Sirveil identifies such a subscription it may decline to provision and will refund it through the Marketplace's own process.

Sirveil is not a consumer reporting agency and the Output is not a consumer report. An Answer is a point-in-time observation of an index; it is not a statement about a person and it is never a determination about anyone's character, conduct, or eligibility.

The prohibited uses in Terms Section 7 and Section 4 of the AUP are contractual, and they are enforced under the ladder in Section 8 of the AUP.

We will give at least 30 days' notice to your account email before a material change to this notice. Changes apply prospectively. The commitments in Section 6 that are marked permanent — no sale, no separate people database — are floors, not snapshots, and a later version will not weaken them retroactively for data already collected. Each version carries a version number and an effective date.

Contact. Privacy: [email protected] · Security and incidents: [email protected] · Abuse and misuse: [email protected] · Legal, including subprocessor list requests and DPA inquiries: [email protected] · Support: [email protected].

Sirveil, Inc., a Delaware corporation · San Jose, California.

Disputes follow Terms Section 22 — a written remedy petition, 60 days to resolve it between people who can settle, then arbitration.

Drafting principle applied throughout this version. Describe generously; commit narrowly. Every protection the product actually delivers — the fail-closed PII firewall, the whitelist projection, the correlation-label drop, the empty-policy row-level security, the never-recoverable key — is stated, because a security reviewer should be able to read this page and see the architecture. Each is stated as a description of how the Service operates, not as a warranty of how it will always operate. Terms Section 15 carries the warranties; Section 15.1 carries what Sirveil does not have.

Brackets closed in this version.

One decision is a business one, not a legal one. Section 7 discloses that the per-call activity row is retained indefinitely, because that is the current state. It is an unresolved decision rather than a designed choice, and a stated retention period would be better disclosure than none. That is a change to make in the product, and this notice will follow it.