VercatusSecurity
Security, control by control.
Every control a security review asks about, in its current state. Planned is never shown as shipped, and the technical detail is published in the documentation.
Every control,
with its true status.
Stated as a contract would state them: what applies, to whom, and how. One list feeds this page, the enterprise page and the home page, so a control is never shipped on one and planned on another.
8 shipped3 planned
| Area | Status | Applies to | Detail |
|---|---|---|---|
| Domain authorisation | Shipped | Every site | Vercatus analyses a customer's domain only after its owner has verified it: by owning or fully managing the domain's Search Console property, by a DNS TXT record, or by a meta tag on the home page. Verification is per workspace, and a Search Console proof is withdrawn when that access goes. Before verification a new workspace gets an access preview of its first domain: it reads robots.txt first and requests nothing else if that disallows Vercatus, then the home page (also under the user agents of Googlebot and the AI crawlers), llms.txt and the sitemaps, in a few dozen requests, with nothing analysed or measured. The setup wizard's domain check and the public access check read robots.txt first too. The app also reads the home page and icon of the hosts it shows, such as competitors and cited domains, at most once a month per host and without consulting robots.txt, for the icon beside a name. Public pages that answer engines cite are read under the Vercatus/1.0 identity, with robots.txt and crawl delays honoured, to see which brands they name. |
| Crawler identity | Shipped | Our own requests | Our own requests name the crawler in the user agent; a run's page and file requests, the identity probes and the access watch, over plain HTTP, carry an RFC 9421 HTTP Message Signature with a published Ed25519 key (the probes send other crawlers' user agents on purpose and are signed as Vercatus on plain HTTP). Pages rendered in a headless browser, the home-page read for a meta-tag proof, the icon fetch, the checks of a commerce feed and its protocol files, the brand-logo fetch and the crawler-traffic connection test carry the user agent only, and an agent task runs under the identity its owner chose. robots.txt is honoured by runs, the first look and the setup check, not by the icon fetch. Bot management can verify the signature where there is one rather than trust the string. |
| Stored data and retention | Shipped | Every workspace | Vercatus retains fetched page bodies for 30 days and then deletes them; answers, briefs, plays, verdicts and reports are kept for the life of the site and deleted within 30 days of the workspace's closure; a cited page's text is deleted 24 months after Vercatus last read it; pooled figures identify no workspace and are kept; account data is kept until the account is deleted; server logs for at most 30 days. |
| Access isolation | Shipped | Every workspace | Workspace isolation is enforced for each request. Analysts and viewers can be limited to selected sites; clients always have selected sites and narrower permissions. Owners and admins have workspace-wide access. |
| Model providers | Shipped | Every workspace | Analysis runs under a no-training agreement with the model provider. Page content is sent for analysis and not used to train models. |
| Roles and audit | Shipped | Every workspace | Every play shipped, decision, export, invitation and setting change with who, when and from where; append-only; readable by admins in the workspace and over the API. |
| Single sign-on | Shipped | Enterprise | Per-workspace connections to Google Workspace, Microsoft Entra ID, Okta, any OpenID Connect provider or SAML 2.0; domains verified by DNS; a test sign-in before a connection is enabled; enforcement per domain and just-in-time provisioning. |
| Data processing agreement | Shipped | Every workspace | Published and part of the terms for every workspace, with the sub-processor list; Enterprise customers receive a signed copy on their own paper. |
| Choice of data region | Planned | Enterprise | The application and the database run in Amsterdam, Netherlands, so workspace data is stored in the EU today; analysis goes to US model providers under the Data Privacy Framework or standard contractual clauses. A choice of EU or US per workspace, with EU-only analysis, is on the roadmap and stated as planned in contracts. |
| SOC 2 attestation | Planned | Enterprise | On the roadmap; no attestation is held today and none is implied. |
| Per-workspace retention settings | Planned | Enterprise | Shorter retention of page bodies on request is on the roadmap. |
Shipped in the product todayWith conditions built, with a stated limitPlanned on the roadmap, and written so in contracts
What moves where,
and for how long.
From your verified site to your workspace, in five steps. Search Console, Analytics, Slack, Teams, Linear and Jira are reached only when you connect them.
- Your verified siteAnalysed only once proved by Search Console, DNS or a meta tag
- The pollYour topics' questions asked of each answer engine; the answers kept
- Signed crawlerYour pages and the pages engines cite, read under robots.txt
- Model providersNo-training terms; analysed, not learned from
- Your workspaceAnswer Share, plays and verdicts, scoped by role, logged
- What is stored
- For each site: its topics and questions, each engine's answers and cited sources, the pages engines read and how they changed, Engine Briefs, plays and verdicts. Plus the account data needed to run it.
- Where it goes
- The application and the database in the EU; page bodies in separate storage for 30 days; page text and answers to our model provider under no-training terms; questions to the answer engines. Every sub-processor is named in the privacy policy and the DPA.
- How long it is kept
- Vercatus retains fetched page bodies for 30 days and then deletes them; answers, briefs, plays, verdicts and reports are kept for the life of the site and deleted within 30 days of the workspace's closure; a cited page's text is deleted 24 months after Vercatus last read it; pooled figures identify no workspace and are kept; account data is kept until the account is deleted; server logs for at most 30 days.
Nothing private enters it.
It learns in aggregate: every final verdict, and every page change Vercatus sees across the web, sets the expected gain of the next play. It is built so that no workspace can see another's data.
- Aggregates, not records.Play priors, natural experiments and demand calibration hold counts and effects, never a workspace, a site or a question.
- Shown only above a privacy floor.Nothing is shown, and nothing sets a play's gain, until enough sites stand behind it.
Enters the repository
- Public pages engines cite, read under robots.txt, and how they changed
- Frozen verdicts, as counts and effects by kind of play, engine and market
- Demand calibration ratios, pooled across connected sites
Never enters it
- Your Analytics and Search Console figures
- Your crawler-traffic lines (only a demand ratio comes from them)
- Your plays' drafts, notes and decisions
- The name of any workspace, site or question
- Anything behind a login
The documents
a reviewer reads.
14 sub-processors, each listed with its location, its purpose and the data it receives, as the GDPR requires; you are told before one is added. The list · DPA
- Crawler identityUser agent, signature, the published key and how to verify it
- Responsible disclosureContacts and policy in security.txt
- Audit logWhat is recorded, for how long, and who can read it
- Data processing agreementPublished for every workspace; countersigned on Enterprise
- Security documentationStorage, tenancy, model providers, in detail
Do you hold a SOC 2 attestation?
Not yet. SOC 2 is planned; no attestation is held today and none is implied.
Where is our data stored?
The application and the database run on servers in Amsterdam, Netherlands, so workspace data is stored in the EU. Fetched page bodies are kept in separate object storage for 30 days and then deleted. Analysis is sent to model providers in the United States under the EU-US Data Privacy Framework or standard contractual clauses.
How long do you keep what you collect?
Vercatus retains fetched page bodies for 30 days and then deletes them; answers, briefs, plays, verdicts and reports are kept for the life of the site and deleted within 30 days of the workspace's closure; a cited page's text is deleted 24 months after Vercatus last read it; pooled figures identify no workspace and are kept; account data is kept until the account is deleted; server logs for at most 30 days.
Is our content used to train models?
No. Analysis runs under a no-training agreement with the model provider: page content and answers are sent for analysis and not used to train models.
How are workspaces kept apart?
Workspace isolation is enforced for each request. Inside a workspace, analysts and viewers can be limited to selected sites; clients always have selected sites and narrower permissions. Owners and admins can access every site. Branding alone does not restrict access.
Will you analyse a site that has not been verified?
Not for a workspace. A workspace measures and analyses only domains its owner has verified, through Search Console, a DNS TXT record or a meta tag. Before that, a new workspace gets an access preview of its first domain: robots.txt first, and nothing else if it disallows Vercatus, then the home page (also under the user agents of Googlebot and the AI crawlers), llms.txt and the sitemaps, in a few dozen requests; nothing is analysed or measured. The setup wizard's domain check reads robots.txt and one home page, and the app reads the home page and icon of the hosts it shows, at most once a month per host, for the icon beside a name; that icon fetch does not consult robots.txt. Public pages that answer engines cite are read politely under the Vercatus/1.0 identity, with robots.txt and crawl delays honoured, to see which brands they name.
How can our bot management tell the crawler is really you?
Our own requests name Vercatus in the user agent, and a run's page and file requests, the identity probes and the access watch, over plain HTTP, carry an RFC 9421 HTTP Message Signature made with a published Ed25519 key. Pages rendered in a headless browser, the home-page read for a meta-tag proof, the icon fetch, the checks of a commerce feed and its protocol files, the brand-logo fetch and the crawler-traffic connection test are identified by the user agent only, and an agent task runs under the identity its owner chose. The requests we send on purpose under other crawlers' user agents, to measure how your site treats them, are signed as Vercatus on plain HTTP. Verify the signature where there is one rather than trust the string; the crawler page shows how.
How are API keys and shared links protected?
API keys are stored as hashes, shown once, scoped, and revocable at any time. The one page that opens without a session is a read-only quarterly review an admin creates for a board: an unguessable link stored as a hash, with an expiry, revocation, an audit record and no-store and noindex headers.
Can we shorten how long page bodies are kept?
Not yet. Shorter retention of page bodies per workspace is planned. Today every workspace has the same 30 days.
How do we report a vulnerability?
Write to abuse@vercatus.com or hello@vercatus.com; both are listed in security.txt, with the policy it points to. Reports about the crawler's behaviour go to the same address.
Take it to your security review.
Every control above is stated the way a contract would state it. Create your account and look at your own domain, or bring the review to a call.
A reply within one working day