Acceptable Use Policy

Sirveil sells a question-answering service about information that is already public. That capability is useful to auditors, security teams, privacy operations, incident responders and counsel — and the same capability would be useful to a stalker. This Policy is the contractual half of controls that already exist in code.

The engineering controls came first. Facial-recognition domains are refused at the API boundary before a query is built. The one part of the Service that fetches third-party pages honors robots.txt and fails closed. Nothing in the product logs in anywhere, solves a captcha, or steps around an access control. This document does not create those behaviors; it makes the rules around them enforceable, and it is careful to tell you which of them we describe and which of them we promise — those are different things, and Section 6 says which is which.

Read Section 4 first. It is the whole of the fence, and it is the same fence as Section 7 of the Terms — this Policy elaborates it with examples, and it does not add to it.

Breach of Section 4 of this Policy is a breach of the Terms, and it carries three distinct consequences, each with its own mechanic:

• it permits immediate termination without a cure period (Terms Section 19);
• on written notice and a failure to cure within 15 days, it ends your license to Output delivered after that notice, whether or not we also terminate (Terms Section 12(b)); and
• where we do terminate for it, your right to reproduce, distribute and resell Output already delivered ends as well (Terms Section 19).

It is also one of the few things that lifts the liability cap (Terms Section 17(c)). None of that is a threat. It is the reason a customer who stays inside the fence gets terms this permissive.

This Policy applies to:

• every call to the Sirveil Exposure API, through every endpoint — POST /api/v1/verify, POST /api/v1/scan, GET /api/v1/jobs/{id}, GET /api/v1/whoami, and POST /api/v1/mcp;
• every call made through the agent surface. POST /api/v1/mcp is a read-only Model Context Protocol server exposing a single verification tool. A call an AI agent makes on your behalf is your call, made under your key, subject to this Policy in full. An agent is not a third party for these purposes and "the model decided to" is not a defense;
• every use of the Output, including by your personnel, your contractors, your end users reaching the Service through your application, and your own customers if you resell; and
• however access is purchased. Section 3.1 of the Terms states which channels can actually transact today; this Policy applies through any of them, and through any reseller arrangement Sirveil enters.

Where this Policy and the Terms differ, the Terms control (Terms Section 3).

Any lawful business or professional purpose, subject to Section 4 of this Policy and to your obligations under the Terms. That includes building the Output into your own products, white-labeling it, bundling it, and reselling it at any price you choose, with no revenue share — provided the restrictions in Section 4 travel downstream by contract under Section 7 below.

Inside the fence, your business is your business. We do not ask what your product does, we do not require you to justify a query, and we do not maintain an approved-use list. There is no allowlist of domains you may verify against: you name any hostname and we query it.

⛔ This Section is the fence. There is no enterprise override, no research exception, no government exception, and no price at which any of it unlocks.

The seven items below are the same seven prohibitions as Section 7 of the Terms, restated with examples so that a compliance reviewer can see what falls inside each one. The examples illustrate; they do not enlarge. Nothing in this Section prohibits conduct that Section 7 of the Terms permits, and if a reading of an example here would extend the fence beyond Section 7, Section 7 controls.

You will not, and will not permit anyone else to, use the Service or the Output:

4.1 For any purpose regulated by the Fair Credit Reporting Act

— 15 U.S.C. §1681 et seq., or a state analogue including Cal. Civ. Code §§1785 and 1786 — including as a factor in establishing a person's eligibility for credit, insurance, employment, housing or tenancy, education, a government license or benefit, or any other purpose enumerated in §1681b(a)(3).

Inside this prohibition, by example: pre-employment or contractor vetting; hiring, firing, promotion, reassignment, or retention decisions; gig-platform or marketplace onboarding decisions about a worker or seller; tenant screening or a rental application; insurance underwriting or claims eligibility; a credit or lending decision; an admissions decision; a professional-licensure or government-benefit determination; and any adverse action taken about a person in whole or in part on an Answer.

Not inside it, by example: checking your own organization's exposure; checking the exposure of your own workforce as a privacy-remediation service for them, where no decision about them turns on the result; and a Subject-initiated check about that Subject's own data.

Sirveil is not a consumer reporting agency and the Output is not a consumer report. Using it as one puts you in the position of a user of consumer reports with none of the protections the FCRA requires, and it breaches this Policy.

4.2 To stalk, harass, dox, intimidate, threaten, or locate a person for the purpose of causing harm

— or to facilitate anyone else doing so.

Inside this prohibition, by example: assembling a location or movement profile of a named individual for a requester who will not say why; publishing a person's home address, phone number, or workplace to expose them; running lookups for a client you know is subject to a restraining or protective order concerning the Subject; building or selling a product marketed to find a former partner, an anonymous critic, or a person who has cut off contact; supplying Output to a person you know intends any of the above.

The qualifier is real. The words "for the purpose of causing harm" attach to locate. Lawful service of process, lawful debt collection, lawful investigative work performed under a license where one is required, and lawful journalism are not prohibited by this item. Stalking, harassment, doxxing, intimidation and threats are prohibited regardless of purpose.

4.3 For facial recognition or biometric identification

You will not submit face images, face embeddings, or other biometric identifiers or templates, and you will not use Output to build, train, operate, or enrich a facial-recognition or biometric-identification system.

The class is defined by function — a service whose primary function is identifying a person from an image or a biometric template — not by a fixed list of companies, so that it does not go stale and so that a contract does not name businesses in it. The current list of the domain classes the Service refuses is available on request, subject to the confidentiality obligations in Section 14 of the Terms. (The Registry itself — the full source map — is Sirveil's confidential property and is not disclosed.)

You will not attempt to route around that refusal, by aliasing a hostname, by using a redirector or mirror, by splitting a query across accounts, or otherwise.

4.4 With credentials or sensitive material you have no lawful right to submit

— passwords, password hashes, session tokens, full payment-card data, government-ID images, or data from a breach or dump.

Inside this prohibition, by example: pasting a credential dump into an identity field; submitting a stolen or purchased combo list; sending a scan of a driver's license or passport; supplying a full primary account number in any field.

What this does not stop. Asking whether an email address you hold lawfully appears in a known breach corpus is a lane the Service runs. That lane reports whether an identifier appears — not the credential itself. Nothing in the product uses, returns, replays, or tests a breached credential. What this item stops is you sending us the dump.

You will also not use the Service to log into a third-party site, to solve or bypass a captcha, to circumvent a technical access control, or to retrieve material in violation of the Computer Fraud and Abuse Act or a state equivalent. (That is item 7 of the fence — unlawful use, and use in violation of a third party's terms where you direct the Service there — applied to these facts. It is an example, not a further prohibition, and the Service has no capability to do any of it in any event: see Section 6.)

4.5 To attack, probe, overload, reverse engineer, or circumvent the Service

— its security, or its metering, or to test it beyond documented limits without our written agreement.

Inside this prohibition, by example: load testing, stress testing, fuzzing, or penetration testing without prior written agreement; probing or tampering with metering, quota accounting, or rate limiting; opening additional accounts, rotating keys, or splitting traffic across entities to evade a limit; crafting requests to recover an internal threshold, weighting, or rubric; attempting to reconstruct Sirveil's supplier set or unit economics from responses; and attempting to reach another tenant's job, key, or usage.

What this does not stop. You may evaluate the Service for your own purposes, run your own tests against it within published limits, publish your own honest results, and say what you found. Section 13 of the Terms says so expressly. What is out of bounds is doing that work as a competitor's proxy, and copying the thing rather than using it.

If you want to run a load test, ask at [email protected]. The answer is usually yes, with a window and a limit.

4.6 To misrepresent Output

— as a government record, a background check, a credit or consumer report, a certification, or a determination about a person.

Inside this prohibition, by example: labeling a report "background check" or "verified against government records"; presenting confidence, calibrated_probability, linkage, or a match_probability to anyone as a measured accuracy rate or as a statement about a person — Section 9.1 of the Terms is explicit that these are diagnostics and not determinations; reporting an indeterminate result to a downstream recipient as a clean negative; and representing not_indexed as proof that a person's data is not on a site, when it means only that it was absent from the search index we read.

If you resell Output, the three-state contract travels with it. The words the Service ships inside every response body — "THREE STATES ONLY. This endpoint reads a search index; it does not fetch the page. not_indexed means absent from the search index — not proven absent from the site." — are the words your customer is entitled to as well.

4.7 In violation of any applicable law

— or of a third party's terms of service, where you direct the Service at that third party.

Inside this prohibition, by example: naming, in a Verification, a domain whose terms forbid automated querying, where you are the party directing us there. The Service's own conduct toward third-party sites is described in Section 6 below; that conduct is ours and it does not make your instruction lawful.

Nothing in this Section adds a restriction the Terms do not already impose. Each item names where it comes from, and is restated here because a compliance reader looking at one document should not have to guess. Breach of an item in this Section is handled as a breach of this Policy other than Section 4 — see Section 8 below.

• Your representations about what you send (Terms Section 7). For every Identifier you submit, you represent that you hold it lawfully, that you have a lawful basis to have us process it, and that you are not knowingly submitting the Identifier 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 Policy 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.
• Key hygiene (Terms Section 5). One key, one organization. Keys may not be shared across legal entities, sold, sublicensed, or embedded in a client application where an end user can extract them. An account may hold up to ten unrevoked keys. Tell us at [email protected] immediately if a key is exposed.
• Use-case attestation (Terms Section 5). We may require any account to certify its use case in writing, at key issue or afterwards, and may condition, suspend, or refuse access on that certification or on a refusal to give one.
• Not for competing use (Terms Sections 12(a) and 13). You will not use the Service, the Documentation, or the Output to build, train, or enrich a dataset, model, or service that detects, scores, or reports personal-data exposure in competition with the Service; to replicate the Registry; or to conduct benchmarking or competitive analysis for, or on behalf of, a competitor. Sell the answers; do not assemble them into the thing that answers.
• Diagnostics are not determinations (Terms Section 9.1). The confidence, calibration and linkage values in an Answer are returned to explain an answer, not to measure its accuracy. You will not build a decision threshold on one, and you will never put one in front of the person it is about.

This Section describes controls that exist in the code today, because you are entitled to know what the machine you are buying actually does. It is a description of how the Service operates, not a warranty of how it will always operate. Section 15 of the Terms states what Sirveil warrants, and Section 15.1 states what Sirveil does not have. Nothing in this Section creates a service level, and Section 11 of the Terms states that no uptime commitment is offered.

Facial recognition is refused at the boundary. A request naming a domain in the facial-recognition and biometric-identification class is refused with 403 domain_excluded before any query is built and before any money is spent. The refusal runs on both endpoints — the Verification path and the Scan registry — and it is layered, including a build-time guard that fails the build if the exclusion is removed. It is a control in the code, not a policy applied by hand, and it is not waivable by anyone, at any price.

The crawler tells the truth about itself. The username prober — the only part of the Service that requests pages from third-party sites directly — fetches, parses and honors robots.txt, and fails closed. It treats every ambiguous outcome as Disallow: a 401, a 403, a 5xx, a timeout, and a robots.txt it cannot parse. It sends an honest identifying user agent carrying a contact URL that explains what it is and on whose behalf it runs. It performs zero retries, and it truncates a fetch at 32 KB.

That describes the Service. It is not a representation about Sirveil's other internal systems, which are not part of the Service and are not sold to you.

There is no credential use anywhere in the product. No logging in, no captcha solving, no login bypass, no circumvention of a technical access control — none of it exists anywhere in the tree. The breach and stealer-log lane reports whether an identifier appears in a corpus; nothing in the product uses a breached credential for any purpose.

A Verification reads an index; it does not fetch the page. That is why not_indexed means absent from the search index and not proven absent from the site, and it is why the Service does not need to fetch broker pages directly. It does not.

You may not ask us to disable any of the above, and we will not.

Section 7 of the Terms requires the fence to travel with the data. Concretely, you will:

1. Bind your customers by written contract to restrictions at least as protective as Section 4 of this Policy and Section 7 of the Terms;
2. Require each of them to impose the same restrictions on every further recipient, so that the fence survives more than one hop;
3. Name Sirveil as an intended third-party beneficiary of those restrictions, entitled to enforce them directly against your customer and against every further recipient. Section 24 of the Terms carries the matching provision on our side;
4. Remain responsible to Sirveil for your customers' conduct, as if it were your own; and
5. On request, identify the categories of customer you serve — categories, not names, unless a specific investigation requires more.

If a downstream customer breaches, we may require you to cut them off as a condition of your own continued access. We would rather you did that than we suspended you.

We have five rungs, and we generally climb them in this order:

We are not required to climb the ladder in order. Where the risk is immediate we may suspend or terminate first and tell you after. Skipping a rung once is not a waiver of it, and using a lower rung is not a representation that the conduct was acceptable.

What termination for a Section 4 breach costs you, stated plainly. Where we terminate for it, your license to Output ends as to further reproduction, distribution and resale; you will stop distributing Output and delete it on request; and you may keep using Output already embedded in a delivered product only so far as necessary to avoid harm to a third party, and not to make new copies (Terms Section 19). Separately, and whether or not we terminate, written notice of a Section 4 breach that you do not cure within 15 days ends your license as to Output delivered after that notice (Terms Section 12(b)). The liability cap does not protect you for that breach (Terms Section 17(c)). Fees already incurred remain payable. Where you purchased through a Marketplace, that Marketplace's published refund and cancellation policy applies to the transaction and nothing in this Policy narrows it.

We may decline to serve a use case we are not comfortable with, including a lawful one. That is not a determination that your use is unlawful, and we will say so if you ask.

⛔ We may monitor. We are not obliged to. We may monitor usage patterns for signs of prohibited use. Nothing in this Policy or in the Terms obliges Sirveil to monitor, to detect misuse, or to prevent it, and no failure to detect misuse waives any right, excuses any breach, or constitutes approval of any use. Serving a call is not a review of it. An account that has run for a year without a question has not been vetted.

If you believe the Service is being misused — including against you — write to [email protected]. Those are read by a person. Include what you saw, when, and any request or response identifiers you have; every response, including every error response, carries the version stamps that produced it, and those make an incident traceable.

A Subject — a person whose information may have been queried — can reach us at [email protected]. Section 10 of the API Privacy Notice explains what we can and cannot do for a Subject, and it is honest about the limit: a synchronous call persists nothing, so there is generally no dossier for us to produce or delete.

Reporting misuse in good faith is not itself a breach of this Policy. That is not a license to go looking: Section 4.5 requires our prior written agreement before any security, load, or penetration testing, and reporting a finding afterwards does not supply that agreement in advance. Where you come across something without testing for it and tell us promptly and privately, we will weigh that — as a matter of judgment under Section 8, not as a right you can assert.

Drafting principle applied throughout this version. Describe generously; commit narrowly. Section 6 states every protection the product actually delivers — the boundary refusal, the fail-closed robots.txt handling, the honest user agent, the absence of any credential use — because a buyer should be able to read this Policy and see that the values are in the code. Each is stated as a description of how the Service operates, not as a warranty of how it will always operate, and Section 6 says so in terms.

Brackets closed in this version.