Who else touches your data

Sub-processors that receive customer content

These four see what was said in your discovery calls, or the documents you upload. They are the ones that matter in a review.

Sub-processors that receive account or operational data

No discovery content reaches these.

Destinations you choose

Account research: what is wired, what is gated, and what runs nowhere

cogz contains an account-research capability that reads public records about a company you are selling to. Re-checked against the running system on 26 August, it has three states rather than the two this page described before, and only the first of them sends anything at all. That one is now switched on. The destinations below were written down here while it was still switched off, and turning it on changed none of them: the same three, in the same words. The second and third states remain silent.

1. Reading the public record — running

An authenticated seller can start a research brief on an account they have access to. Four modules do the work: they read the company's careers and jobs pages, its investor-relations pages, its SEC filings and its proxy statement. Nothing is scanned, and nothing is sent at anything but an ordinary public web server.

As of 26 August this executes in production, and what changed is worth stating exactly. Starting a brief queues a background job. Until today the worker that drains that queue was switched off on the production host, so the route accepted the request, the brief sat recorded as queued, and nothing went out. The worker is on. Briefs now run, and the requests below are made. The change was one environment setting on one host, which is why this page named the destinations while the setting was still off: it was corrected first and flipped second. These are the destinations and this is what reaches them:

• SEC EDGAR (www.sec.gov and data.sec.gov) receives the company name and its filing identifier. Nothing about your workspace.
• The company's own website receives ordinary page requests for its careers, jobs and investor-relations pages, of the kind every browser and search crawler makes.
• Whatever host serves that company's investor-relations PDFs. Earnings and filing PDFs linked from an investor-relations page are usually hosted on an IR provider's CDN rather than the company's own domain, and cogz follows those links to whichever host they point at. This destination is therefore not a fixed list — it is whatever the company itself links to. It is named because a completeness promise that quietly excluded it would be worth nothing.

On identifying ourselves — exactly, rather than flatteringly. Two of the three request paths name cogz. The careers fetch sends cogz-recon/1.0 (+https://cogz.io), and the SEC fetches send cogz-recon mailto:no-reply@cogz.io, which is the contact address EDGAR asks automated clients to supply. The investor-relations fetch does not. It sends an ordinary Chrome user-agent string, so those requests are not attributable to cogz in that company's logs. That is an inconsistency between two halves of one feature rather than a policy, and writing it here is cheaper than having it found.

Two of the four modules drive a headless browser rather than fetching a single file, so the company's page loads its own subresources exactly as it would for any visitor, and the investor-relations path clicks a cookie-consent button when one blocks the page. That is interaction with their site, not only reading it.

A brief is shown to the seller as observations from public sources, each with a link to the record it came from. Two of the four parsers are known not to extract reliably and say so on their own results rather than reporting an empty read as a fact about the company. The brief writes nothing into your customer's record and nothing into any document your customer reads.

2. Gated by a recorded authorisation — and inert even when it is granted

The rest of the subsystem describes traffic aimed at a company's own infrastructure: port scans, TLS handshakes with certificate verification switched off, VPN-portal guessing, cloud-bucket guessing, Microsoft account enumeration, and web-fingerprinting tooling. Reaching it requires an authorisation recorded against one account, naming who authorised it, on what grounds, and until when. There is no global switch. The grounds are stored verbatim with a SHA-256 fingerprint so a later rewording cannot be backdated onto an older authorisation; it expires — thirty days unless a shorter period is set; and withdrawing it marks the record revoked rather than deleting it, so the original act stays answerable afterwards.

What this page claimed before, and what the code actually does. It said that if the authorisation were granted, a long list of destinations would receive traffic. That is not true. The eight probe-grade entries in this lane are declarative: each carries a description and no implementation. An authorised run walks each one, records it as unavailable with the reason stated, and sends nothing. Enabling the worker above did not change that, and could not: there is no code behind these eight to run. Authorisation lengthens the list of names the brief considers; it does not cause one additional packet to leave cogz. The gate is real and worth keeping. Today there is nothing behind it here.

3. Present in the code, reachable from nothing

A larger attack-surface engine exists in the repository — certificate-transparency services, DNS and network-intelligence services, URL and archive services, breach lists, code search, and a set of regulator and court sites. Nothing in the deployed product can start it. It has no HTTP route, no command-line entry point, and nothing in the web application calls it. It is described here rather than omitted, because "this exists and nothing can reach it" is a better answer than a reviewer finding the code and drawing their own conclusion.

viewdns.info gets its own line, because a name is not a domain. A reverse-WHOIS lookup that would send a company or registrant name — a named organisation — to viewdns.info is present in the code. It sits in a module that nothing imports. It cannot be reached from the research brief, from an authorised brief, or from any other deployed path, so no registrant name is sent there today, from anywhere in this product.

The same is true of the two checks that would send more than a domain. A SaaS-tenant probe would send the target company's brand name to a dozen vendors' own hostnames — Salesforce, ServiceNow, Slack, Workday, Snowflake, Databricks, Atlassian, Box, DocuSign, Dropbox, HubSpot, Zendesk — to see which respond, and a company-status check would send the company name to Wikipedia. Both sit in modules that nothing imports. They are named because they are queries about a third party made from cogz, which is the kind of thing that should be disclosed before it runs rather than after; today neither can be reached. This is also why the "no direct CRM integration" line below is not in tension with it — a probe that asks whether a vendor hosts a tenant is not an integration, and neither one runs.

The scanning gateway gets its own line, because it would scan from somewhere else. It is operator-run infrastructure that would receive a constructed shell command containing the target domain, execute it with tooling such as amass, whatweb, wafw00f and theHarvester, and send the resulting traffic to the target from that host's IP address rather than from cogz's. It is inert for two independent reasons: no address is configured in the deployed product, so no command is ever constructed; and the probes that would call it belong to the engine above, which nothing can start. Both would have to change before a single packet left.

Two further services in this subsystem, VirusTotal and Censys, additionally have no credential configured and would decline to call out even if something reached them.

All of this concerns the company you are researching — not your own workspace's content. No discovery transcript, no uploaded document and no answer recorded in a session is sent to any destination in this section, in any of the three states above.

Things reviewers ask about that cogz does not use

Checked by downloading the JavaScript and CSS that the live application actually serves — the entry bundle, both lazily-loaded chunks and the audio worklet — and reading those, rather than the source they were built from. A tag can be added to a page without ever appearing in a component, and a claim about a bundle should be checked against the bundle.

• No third-party analytics or product telemetry. No Google Analytics, PostHog, Plausible, Segment, Mixpanel, Hotjar or Intercom. cogz's web pages load no third-party script tags at all. Read off the served files, the application contacts exactly two external origins in your browser: Google's font CDN, and the speech-to-text provider's streaming endpoint during a live in-person capture. There is no third. cogz does record its own product usage — which suggested question a seller took, skipped or promoted during a live session — but that goes to cogz's own database on cogz's own host and to no one else. Saying "no telemetry of any kind" would have been the easier sentence and it would not have been true.
• No error-reporting or crash-reporting service. There is no Sentry or equivalent. Application errors go to the container log on cogz's own host and nowhere else. For a product that handles meeting transcripts this is deliberate: an error payload is exactly where transcript fragments would leak to a third party.
• No cloud object storage outside Cloudflare R2 backups. No S3, no Google Cloud Storage.
• No direct integration with Salesforce, HubSpot or any other CRM. The only path out is the webhook you configure yourself, above.

Changes

This list is maintained as part of the change that introduces a sub-processor, not audited afterwards. If you have a signed agreement with cogz that requires notice before a new sub-processor is added, that notice is sent to your workspace owner. Questions: olivier@cogz.io.