Security

Security & data handling

We measure what answer engines say about brands. Doing that means holding your public content, your prompts and the answers that come back — and sending some of it to model providers on the way. This page says exactly what that means, what we refuse to hold, and which promises we are not yet in a position to make.

Last updated 20 July 2026.

What we store

Everything below lives in your install's own database. There is no separate telemetry pipeline and no copy sent anywhere for analysis.

Public pages we crawl

Firecrawl → audit

For an audit we fetch roughly eight pages of the domain you enter — the same HTML an anonymous visitor gets. We keep the extracted text and the evidence snippets the Brand Genome quotes, so every claim in your report can be traced back to the sentence it came from.

Answer-engine responses

visibility polls

The full text of every answer an engine returned to a tracked prompt, plus the model version, any citations, any fan-out search queries the provider exposed, and the timestamp. These are the raw evidence behind every rate we show; deleting them would make the numbers unauditable.

Brand facts (Brand Memory)

derived

Chunks of fact derived from your own site and your audit evidence, with a section breadcrumb, a review status and a content hash. Nothing here is invented by a model — the chunker splits your text, it does not rewrite it.

Measurements

derived

Per-engine, per-day counts: k mentions out of n answers, citation counts, sentiment, position, recommendation strength, scores and the cited-domain bookkeeping behind the Sources tab.

Free-scan records

/scan

The domain scanned, the scan result, a random share token — and your email address only if you asked us to send you the report. A scan link is unguessable but not secret: anyone with the token can read that scan.

AI-crawler log lines you send us

/api/crawlers/ingest/

If you pipe your own access logs in, we store the path, status code, user-agent string, resolved bot name, and the IP and referer when your payload includes them. Only lines matching an AI or search crawler are stored; everything else is discarded on ingest.

Operator settings

your install

Your notification email, your Slack webhook URL, your API-token rows, your webhook URLs and their signing secrets, and the model/provider keys you paste into Settings.

What we never store

Your customers' credentials

We never ask for, receive or store logins belonging to your users. Nothing in the product requires them.

Payment data

No card number, bank detail or billing token ever reaches our servers. There is no payment integration in the product today; paid plans are invoiced by a human over email.

Anything behind your login

The crawler is unauthenticated. It sees your public site exactly as an anonymous visitor and an AI crawler do — never a logged-in view, never a staging environment you have not pointed us at.

Third-party analytics or ad trackers

The public pages load no analytics script, no tag manager, no advertising pixel. The app keeps your session token in your browser's localStorage rather than a cookie, so there is no cross-site tracking surface to consent to.

One honest exception: the outreach module

If you choose to connect a LinkedIn account or an SMTP mailbox, those credentials are stored in your install's database so the automation can log in and send. They are your owncredentials, not your customers' — but they are credentials, and it would be dishonest to leave them out of a “what we never store” list. Neither connection is required to use the audit, visibility or SEO side of the product, and disconnecting deletes the row.

Encryption and transport

In transit. The hosted app and its API are served over HTTPS/TLS. Every outbound call we make — to model providers, to Firecrawl, to DataForSEO, to SendGrid, to your Slack webhook — is HTTPS. Outbound webhooks are the one place you choose the scheme; we accept an http:// receiver because some receivers live inside a private network, and we sign the body either way.

At rest.Data sits in the database file on your deployment's persistent volume, protected by the disk encryption your host provides. We do not implement application-level field encryption, and we are not going to imply otherwise: an operator with database access can read stored provider keys and connection credentials. Treat database access as equivalent to operator access.

Authentication and access

Dashboard session

bearer token

Logging in mints a signed, expiring token (HMAC-signed, 14-day maximum age, no server-side session table). The browser sends it as Authorization: Bearer … on every request and holds it in localStorage. Credentials are compared in constant time.

Public API tokens

read-only

Tokens for /api/v1/ are separate from the dashboard session and carry a read scope only — there is no write scope to grant, because the public API cannot write. The secret is shown exactly once at creation; the list afterwards shows a fingerprint. Revoking is instant and the row is kept so the audit trail survives. Requests are throttled to 120 per hour per token.

Outbound webhooks

HMAC-SHA256

Every delivery is signed over the exact bytes of the request body and sent as X-AYB-Signature: sha256=…. Verify it before trusting a payload. A 4xx from your endpoint is treated as permanent and never retried; 5xx and network errors get three attempts.

Agent access (MCP)

read-only

The MCP server uses the same dashboard token and exposes read-only tools. No agent can start an audit, route an opportunity, approve anything or publish anything — those are human actions in the app, by design.

sig = "sha256=" + hmac_sha256(secret, raw_request_body).hexdigest()

assert constant_time_compare(sig, request.headers["X-AYB-Signature"])

Verifying a webhook signature — compare in constant time, on the raw body.

Third-party processors

Measuring an answer engine requires asking it, so your prompt text necessarily leaves our infrastructure. Here is every processor in the core product and precisely what it receives.

Processor	Why	What it receives
Anthropic	Primary answer engine + structured extraction	Your tracked prompt text, your brand name, aliases and domains, and the answer text we ask a model to read back for mention/position/sentiment extraction.
OpenRouter	Fusion roster (OpenAI, Google, DeepSeek, Meta, xAI)	The same prompt text, routed on to whichever model in the roster is being polled. OpenRouter is a router: the downstream provider sees the prompt too.
Perplexity	Answer engine (when a key is configured)	Your tracked prompt text.
DataForSEO	Classic SEO data + the optional geo-located AI engines	Keywords, the domains you research, and — for the optional DataForSEO answer engines — your prompt text and the country you asked us to answer as.Account not verified: every call returns 403 today and no data flows.
Firecrawl	Crawling public pages for the audit and theme extraction	The URLs we fetch on your behalf.
SendGrid	Outbound email — the weekly digest, alerts and scan reports	The recipient address and the content of the message we send.

The modules below are off unless you connect them, and they receive nothing until you do:

Slack — The digest or alert body, posted to the incoming-webhook URL you configure.
Tavily — Search queries used by company discovery.
Apollo — Company and role filters used to look up contacts.
BetterContact — A LinkedIn profile URL, to resolve a work email.
Ayrshare / Meta — The post text and media you choose to publish.
SociaVault — The social handle whose public follower count you track.

We do not sell data, we do not pool your measurements into a shared benchmark, and we do not train models on your content. Providers apply their own retention to what they receive; where a provider offers a no-training setting on the API tier we use, we use it.

Retention and deletion

We keep measurement history for as long as you have an account, because the whole point of a trend line is that it is long. We do not expire it on a schedule you have not asked for.

Deleting a brand

Removing a brand removes its audits, prompts, answers, snapshots, memory chunks and crawler rows with it — the foreign keys cascade, so there is no orphaned copy left behind.

Deleting everything

Email [email protected] from the address on the account. We confirm, delete, and reply when it is done — target is 30 days, usually the same week. Backup copies age out with the backup rotation rather than being surgically edited.

Exporting first

Everything the dashboard shows is readable over the public API with a read token, so you can take your history with you before you ask us to delete it.

Free scans

A scan you ran without an account is keyed only by its domain and share token. Send us the link and we will delete the row.

Certifications we do not hold

SOC 2 — not certifiedISO 27001 — not certifiedHIPAA — not applicable

AuditYourBrand is not SOC 2 certified. There is no Type I report, no Type II report, and no audit currently in progress that we could point you at. We are not ISO 27001 certified either. If your procurement process requires a current SOC 2 report, we will not pass it today, and we would rather you learn that on this page than three weeks into a trial.

What we can offer a security reviewer instead: this page, the methodology page for how the numbers are produced, a live status page, a written answer to any questionnaire you send, and the ability to self-host so your data never leaves infrastructure you control.

Reporting a vulnerability

Mail [email protected] with steps to reproduce. You will get a human reply within two business days and an honest status — including “we know, it is queued, here is the workaround” when that is the truth.

We do not run a paid bug bounty and we will not pretend one is coming. We will credit you by name if you want the credit, and we will not threaten anyone who reports a finding in good faith.

Questions this page did not answer?

Send the questionnaire. We answer them in writing, and we say “no” where the answer is no.

[email protected]