security and data protection

See what AdBuyMCP enforces in code, and what it does not hold.

AdBuyMCP enforces its controls in code: each workspace is isolated, the product refuses to act when something it needs is missing, and hashed advertising ids are kept for at most 90 days. The onboarding sends one public homepage's text to Anthropic, and this site's server keeps none of it. No security certification is held, and the items a reviewer usually asks for that we do not hold are listed with the status of each.

Free, with no card. We read your homepage, draft who buys from you and show your monthly price before you join the waitlist. Nothing is bought until you've approved the plan and the ads.

services that receive data
11
hashed ad-id retention
90 days
stage
Launch phase
reviewed
1 Sept 2026
listed below as not held11 items

your questionnaire

Bring the questionnaire you have to run, and the founder can give you the current position on anything these pages leave open.

Book a 30-minute call with the founder

what is not held

A reviewer will ask for 11 things we do not hold.

Each item shows its current status, and none carries a promised date.

  1. ISO 27001

    Not held.

    No certification is held and no audit is in progress.

  2. SOC 2

    Not held.

    No Type I or Type II report exists.

  3. Cyber Essentials

    Not held.

    The most achievable of the three at this stage, and it stands where the other two do.

  4. Penetration test

    Not commissioned.

    No third-party test has been run against this platform.

  5. External MCP client acceptance

    Required for each client.

    Hosted Supabase OAuth with PKCE and consent is deployed. Account access and each external client's own identity and exact callbacks need approval; automatic registration is disabled. Protocol acceptance does not establish compatibility with every Claude, Codex or other client.

  6. Tested database migrations for each release

    Partly met.

    A generated set of PostgreSQL migrations exists, and the hosted database uses a restricted application role in a private schema. A release that changes the schema still needs its migration and a restore accepted for that exact release. The sandbox keeps SQLite as its canonical schema, so it runs with no database to set up.

  7. ICO registration and a completed DPIA

    Open items.

    Registration for the data protection fee and the exposure-ledger data protection impact assessment are both open items.

  8. Independent media-quality verification

    Not integrated.

    No fraud, viewability or brand-safety verification partner is wired in. Placement reporting, supply-path transparency and independent verification are named as unbuilt capabilities.

  9. Support SLA, escalation path or status page

    Not built.

    There is no service level agreement, no uptime commitment, no on-call rota and no status page. A shared support inbox has not been set up.

  10. Legal documents reviewed by a solicitor

    Awaiting a solicitor's review.

    The privacy notice, terms, data processing agreement and subprocessor list are drafts that a solicitor has not yet reviewed, and they are marked as drafts until one has.

  11. A completed DPIA or LIA for a live campaign

    Not yet produced.

    The lawful-basis machinery produces the evidence a DPIA would draw on. Turning current lawful-basis warnings and manifest conditions into launch gates with completed assessments has not been done yet.

If a certification is a hard requirement

Then AdBuyMCP does not meet your requirement today, and it is better to know that before a questionnaire cycle than at the end of one.

What exists instead

A documented architecture that fails closed, one module allowed to join identities, and a retention rule enforced in code. A certificate would attest to these; here a reviewer reads the mechanism itself.

what is enforced

These seven areas are enforced in code

Where a control leaves a condition to you, such as an assessment you hold for a data source, the condition is stated beside it.

01

The onboarding reads one public homepage and keeps nothing from it

When you type a company website or work email into the onboarding, this site's server fetches that company's public homepage, and Claude, Anthropic's AI model, drafts who buys from it. The draft is a starting point you edit, never a fact about your company. Each point below is a behaviour of this site's code.

Only a homepage address leaves your browser
With JavaScript on, a work email is cut to its domain in your browser, and only the homepage address, such as https://acme.com/, is sent to this site's server. Without JavaScript, the field is posted as typed, and the server uses the domain and nothing else. Personal email providers are refused, because their homepage says nothing about your company.
The fetch reaches public addresses only
Only http and https on the standard ports, with no username or password in the address. Private, loopback, link-local, multicast and reserved network ranges are refused where the connection is made, so a name that points somewhere else between a check and a connection gets nowhere. At most three redirects are followed, each checked again, and the fetch stops after ten seconds or one megabyte of HTML. A blocked address gets the same answer as an address that does not exist.
Anthropic receives the page's text and nothing else
The server takes the page's title, description and visible words, up to 12,000 characters, and sends that text to Anthropic's API. Claude drafts what the company sells, the job titles likely to buy, the kinds and sizes of company and where they are, and is told to work only from that text, to treat it as data and never to name a person or a company. If the model declines or fails, you describe your buyers yourself.
Nothing read is kept on this site
The draft comes back to your screen for you to edit. This site's server keeps no copy of the page, its text or the draft, and logs nothing from them. To limit how many homepages one visitor can have read in ten minutes, the server counts reads against your IP address in its memory, and this site's code writes that address to no log and no database.
Your progress stays in your browser tab
What you typed, the buyers you confirmed, your market and your frequency are kept in the tab's session storage, which your browser clears when you close the tab, and none of it goes into a page address. Analytics never record what you typed, your buyers or your market size. The waitlist form at the end reads your plan's numbers from that same tab and prints them above the button before you send them; your website, your email and what you wrote about your buyers never go into a link.
02

The product holds three kinds of data, each with its own rules

Campaign configuration is yours and is held for as long as your workspace exists. Vendor credentials are encrypted at rest and are the highest-value target here. Exposure and outcome data is the category a DPO will ask about, and it is the one with a hard retention rule.

Campaign and plan data
Your plan and brief, compiled targeting specifications, creatives, delivery rows and statements, scoped to your workspace.
Vendor credentials
Encrypted at rest with AES-256-GCM over the JSON-serialised credential object, keyed on SHA-256 of a master key held in the environment. Never logged, never returned by an API read, and the connection store's health is checked at startup and on every readiness probe.
Exposure and outcome events
Ad exposures keyed on an opaque household key, a hashed mobile advertising id, a EUID or a postcode sector, plus outcomes you import or that arrive through your own analytics. Hashed advertising ids are held for at most 90 days. Today the ledger is written to only by the deterministic sandbox. There is no inbound ingest route for viewshed panels, CTV logs or IP logs, so the retention rule is in force before there is live data for it to govern.
03

One module performs every identity join

Everything about the privacy posture follows from that. The exposure ledger that every channel writes into records an exposure against a key and holds it there, and today the deterministic sandbox is the only thing writing to it. Joining a key to a person, or to another key space, happens in the key-translation service alone: it is where the retention rule is enforced, and the one place a reviewer needs to read to understand what is joined to what.

90-day maximum on hashed advertising ids
After the window, the hashed id is persistently stripped from the exposure event. The event is re-graded to a coarser key rather than deleted, so history is preserved without the identifier.
The identity spine uses several kinds of key
Household key, hashed advertising id, EUID and postcode sector. A spine that depended on advertising ids alone would degrade on a schedule set by Apple and Google; this one loses precision one step at a time and records which step it is on.
Per-key legal grading
Each key space carries its own legal grade, so a consent-chained EUID and a postcode sector permit different uses, and the code enforces the difference.
04

The lawful-basis manifest leaves some checks to you

Every compiled channel plan carries a lawful-basis manifest: the provider of each segment used, the basis it relies on (consent-chained, legitimate interest, or outside scope) and the warnings raised while compiling it. It exists so that the answer to "where did this audience come from?" is a document a DPO can read. It is evidence a compliance assessment draws on, and the assessment is still to be made. The manifest also carries the conditions that remain yours: a Legitimate Interests Assessment on file for a given source, say, or a vendor's consent-framework attestation verified on connection. Turning those conditions into enforced launch gates is work we have not finished.

Out-of-home is marked outside UK GDPR scope
Out-of-home delivery runs on screen locations, OpenOOH venue types, postcode areas and times of day. None of that is personal data, and the product records that it sits outside UK GDPR scope. Movement data is absent from that list because none reaches the product: the Adsquare contract does not exist.
Warnings travel with the plan
A low-confidence segment match, an unmapped geography or an excluded segment all raise warnings that stay attached to the compiled plan wherever it goes.
05

Every request is scoped to one workspace

Every route is scoped to an advertiser workspace, and a cross-tenant request returns a 404 rather than a 403, because a 403 confirms that the resource exists. Hosted authentication uses Supabase-signed tokens and server-owned workspace claims. User-supplied metadata cannot choose another workspace.

Actor class is verified on the server
Every request carries a verified actor class, and a header cannot change it. A human web session paired with the agent source marker is rejected outright, and agent credentials must carry a signed agent claim and a verified client id.
Consequential permissions are server-controlled
Exact-digest approval, operator reconciliation and supplier authorisation are three separate permissions issued only from server-controlled roles. An ordinary human tenant member fails closed with a 403, and agents cannot hold any of them.
Audit trail
Actor, source and client attribution are persisted on every action, and the audit log is readable through both the dashboard and the MCP surface.
06

The product refuses to act when something is missing

Each refusal below is in the code today.

Production will not start without its configuration
Production startup requires the configured Supabase verifier, a strong master key, PostgreSQL, explicit HTTPS origins and a public API asset origin. A legacy plaintext credential row, ciphertext that will not decrypt with the current key, or a missing live credential stops the deployment.
A launch without the funds to cover it is blocked
The spend check is enforced by default; only a sandbox preview may run it as a warning. Creative production has no warning-only path at all, because a provider charges when a piece is submitted.
An ambiguous supplier outcome stops the run
It raises an exception that requires explicit human resolution, and the operator is handed the vendor, the operation and the idempotency token. It is never retried and never assumed failed.
Expired supplier authority raises a spend lock
The lock takes effect before any scheduled work runs. One emergency pause tied to the incident is sent, and only a named person's reconciliation clears the stop.
The MCP boundary requires an explicit allowlist
Production must set exact allowed hosts and browser origins, with "none" where there are no browser clients. Local execution binds to loopback. Verifier time, request concurrency and JSON body size are bounded, and a request missing its protocol version header is rejected before dispatch.
07

This site and the product use Claude within fixed limits

This website uses Claude, Anthropic's AI model, to draft who buys from a company during the onboarding and to answer questions in the on-page assistant. The product uses it to extract an audience from a brief, draft plans, pre-check creative, suggest optimisations and explain scores. The points below set out what the model may do and what deterministic code does instead.

The model never sets a price
On this website, your market size is the number you give, and your monthly price is worked out from the published rate. The model's draft of who buys from you is a starting point you edit.
The model never emits a vendor identifier
It extracts semantics; deterministic registry tables emit segment ids by matching those semantics against catalogue keywords. Every segment id that reaches a buy came out of the catalogue.
The model does no arithmetic
Every number in a plan is computed by deterministic code, and the model explains the numbers.
Format limits are enforced by schema
Copy that exceeds a channel's limit is rejected at the boundary as a validation error. Nothing is truncated on its way to a provider.
Provenance is visible
AI-produced output is distinguished from deterministic fallback output wherever it appears. With no API key configured, the product runs on those fallbacks and the onboarding asks you to describe your buyers yourself.
Your data is not used to train models
The homepage text this site sends during the onboarding, and the briefs and campaign data the product sends, go to the model provider to produce your output and are not used to train models.

If your review needs one of these walked through against your own control framework, take it to a call with the founder.

who receives data

These eleven services receive data from this website or the product

Each row says which of the two it serves, what it is used for and what it receives.

The services that receive data from this website or the AdBuyMCP product, what each is used for, and what data each receives.
ServiceServesWhat it is used forWhat it receives
VercelServesThis websiteWhat it is used forHosting this website and running the onboarding's homepage reading, plus the site's page-speed timings and the private store of historical access applications.What it receivesWebsite requests, the homepage address the onboarding reads, anonymous page-speed timings and retained historical access-application records.
AnthropicServesThis websiteWhat it is used forThe onboarding's draft of who buys from you, and the on-page assistant when you send it a question.What it receivesFor the onboarding, the title, description and visible text of the public homepage it read. For the assistant, your question and the conversation context needed to answer it.
Plausible AnalyticsServesThis websiteWhat it is used forCookieless website analytics.What it receivesPage views and named events, with no cookie or cross-site identifier, and never what you type into the onboarding.
Kawl NowServesThis websiteWhat it is used forThe optional AI voice widget on this website.What it receivesThe browser request details needed to load the widget and, if you start a conversation, your questions, its answers and a transcript our team can review.
GoogleServesThis websiteWhat it is used forGoogle Analytics and Google Ads, each only after you allow it.What it receivesPage views and the buttons used, for analytics; cookies, page addresses, IP address and device details, for advertising. Neither loads until you allow it, and Google Ads never loads on the onboarding page.
Cal.comServesThis websiteWhat it is used forThe booking calendar for a call with the founder.What it receivesWhat you enter to book: your name, your email and any notes. Its code loads only when you scroll near the calendar.
SupabaseServesThis websiteWhat it is used forThe database that holds waitlist entries, in London, UK.What it receivesYour name, work email, company, role and what you said you want solved, with the time, the page you sent it from, your browser's user agent string and, if you priced one, your plan's market size, frequency and monthly price. Kept for 12 months after our last contact with you, then deleted.
ResendServesThis websiteWhat it is used forThe email that tells the founder somebody joined the waitlist, so he can reply to you himself, sent from Resend's EU region in Ireland. Resend stores email content and delivery logs in the United States.What it receivesThe five answers you gave, your plan line if you brought one, and your own address, set as the reply address on that email.
RailwayServesThe productWhat it is used forHosted API, dashboard and MCP services, in Amsterdam.What it receivesApplication requests, workspace data, service logs and stored creative files.
SupabaseServesThe productWhat it is used forAuthentication, OAuth and the product's database, with the project in London.What it receivesAccount identity, approved workspace claims, sign-in records and application data.
ResendServesThe productWhat it is used forThe configured SMTP service for customer sign-in emails.What it receivesRecipient addresses and sign-in email content. Configuration alone does not establish delivery.

The privacy notice sets out when each website service runs, the lawful basis for it and how long anything is kept. Read the privacy notice.

What is not on the list

Live funding is disabled in the product and no payment has been taken through Stripe, so no payment provider is listed. Model and media-generation providers receive campaign prompts in the product only when their integration is enabled. The sellers a plan would use are graded on the supply page, and no customer data has gone to any of them. Supabase appears twice because the waitlist database on this website and the product's own project are separate commitments, and Resend twice for the same reason. The processing agreements behind this list have not yet been reviewed by a solicitor.

Each seller’s connector is graded on the supply page.

data residency

The product runs in Amsterdam, with its database in London

AdBuyMCP operates a hosted service with workspace isolation. The API, dashboard and MCP services run on Railway in Amsterdam, and the Supabase authentication and database project is in London. This website, including the onboarding, is hosted on Vercel. A waitlist entry from this website is stored by Supabase in London, and the email that carries it to the founder is sent by Resend from Ireland. Resend stores email content and delivery logs in the United States. This is not UK-only residency. Prices and reports are in sterling, and reporting runs on a Europe/London calendar.

what this means for a DPIA
The question a DPIA asks, where the data sits, has a specific answer: account and workspace data with Supabase in London, the hosted services on Railway in Amsterdam, and this website on Vercel.
what it means for procurement
AdBuyMCP runs the hosted service and isolates each workspace within it, so your team has nothing to host or operate.

engineering evidence

The tests cover the product's workflow and this site's onboarding

The product has no incident history and no audit report yet, so these specific checks are the closest it has to a track record.

01

An acceptance suite provisions a disposable database at a fixed instant, starts the real API and a production build of the dashboard, and runs human-readable scenarios end to end against those real services.

02

A dependency-free browser smoke executes every dashboard page, asserts React hydrated, and fails on an error shell or a severe runtime error.

03

A coverage gate fails the build unless the line-weighted aggregate across the domain packages, the API and the MCP server reaches 90%.

04

Regression tests guard the rules a buyer relies on: targeting, tenancy, the funding check before a launch, creative readiness, delivery that survives a restart, labelling of modelled reach, and retention.

05

This site's tests check that the onboarding's fetch refuses every blocked address range, a name that changes what it points to, a redirect into a blocked range and any port other than 80 and 443.

What the evidence does not cover

The product's tests run on sample data in the sandbox. Passing tests show the software behaves as specified; whether a seller accepts a request or an invoice reconciles is graded separately on the supply page.

insurance, counterparty and review date

A vendor file also needs our insurance, the counterparty and a review date

Each is below or one link away, so you can complete the file without a round trip.

Insurance

Professional indemnity and cyber cover are held by the operating company named in our terms. Certificates are available on request, and cover levels vary by agreement, so they are confirmed when your terms are agreed.

The terms name the operating company
The counterparty

AdBuyMCP is the trading name of a company registered in England and Wales and operating from London. The terms name it, with its company number and its Companies House entry, as the counterparty to every agreement, and the privacy notice names it as the data controller.

Who the counterparty is
Currency of this page

Reviewed against the code on . The onboarding section and the list of services were written on , from the code that runs them. If you are reading a printed copy long after that, ask for the current position.

Security, privacy and questionnaire enquiries: hello@adbuymcp.com.

Send a security report to the founder's inbox

Send a suspected vulnerability in this website or in the product to hello@adbuymcp.com. The inbox is read by the person who wrote the code. Include what you found, where you found it and the steps that reproduce it. No response time is committed, because there is no support SLA or on-call rota.

You can print this page: the printed copy is black on white, with every answer open and every link address written out.

running an assessment

Run most of your vendor assessment from these pages.

The security, privacy and supply pages answer most due-diligence questions about AdBuyMCP, and the founder answers the rest, including where the answer is that something is not done yet.

Free, with no card.

A security review usually asks these questions

Nine questions, in the order they usually arrive.

Are you ISO 27001 certified?

No. AdBuyMCP holds no ISO 27001, SOC 2 or Cyber Essentials certification, and no third-party penetration test has been commissioned. ICO registration and the exposure-ledger impact assessment are open items too. If a certification is a hard procurement requirement, AdBuyMCP does not meet it today. The security page lists every item not held, with the status of each, beside the controls that are in force.

How long do you keep personal data?

This site's server keeps nothing from the onboarding: the homepage it reads, the page's text and the draft of your buyers are not stored there, and what you type stays in your browser tab until you close it. In the product, hashed mobile advertising ids are held for at most 90 days, after which they are persistently stripped from the exposure event, re-grading it to a coarser key rather than deleting the record. Campaign configuration, plans and delivery data are held for the life of your workspace and deleted on request. Vendor credentials are encrypted at rest with AES-256-GCM and are deleted when the connection is removed.

Who can see my campaign data?

Your workspace is the scope boundary for every route, and a cross-tenant request returns a 404 rather than a 403, because a 403 confirms that the resource exists. Actor, source and client attribution are persisted on every action and readable in the audit log. The audit log covers what came through the API: someone with direct database access sees more, and that is AdBuyMCP. No certification attests to how that access is controlled, because none is held.

Can an AI agent authorise spend on my account?

No. Agents cannot hold the exact-digest approval permission, cannot resolve human approvals, cannot revoke or replace authority and cannot close missions. Consequential calls fail closed unless the request matches an approval a human granted for those exact bytes, and enabling spend on a staged live line is a separately granted action that approval alone cannot perform.

Can the onboarding be made to fetch an internal address?

No. It accepts only http and https on the standard ports, refuses private, loopback, link-local, multicast and reserved ranges where the connection is made, checks every redirect again, and stops after ten seconds or one megabyte of HTML. A blocked address gets the same answer as an address that does not exist, so the reply reveals nothing about this site's network.

What is your lawful basis for the targeting data?

It varies by segment, so it is recorded per segment. Every compiled plan carries a manifest naming each segment's provider and its basis: consent-chained where the provider asserts a consent chain, legitimate interest where the segment relies on one, and outside scope for out-of-home, which involves no personal data in delivery. Where a segment match is weak or a geography is unmapped, the warning stays attached to the plan.

Is my data used to train AI models?

No. The homepage text this site sends during the onboarding, and the briefs and campaign data the product sends, go to the model provider to produce your output and are not used for training. The product's AI layer also has a complete deterministic fallback, so it runs with no model provider configured at all.

Where does the data live, and can we keep it in the UK?

The hosted API, dashboard and MCP services run on Railway in Amsterdam, and the Supabase authentication and database project is in London. A waitlist entry from this website is stored by Supabase in London too, in a separate project, and the email that carries it to the founder is sent by Resend from its EU region in Ireland. Resend stores email content and delivery logs in the United States. This is not UK-only residency. AdBuyMCP operates the service with workspace isolation. Reporting uses a Europe/London calendar and prices are in sterling; those settings do not determine where data is hosted.

Who are your subprocessors?

For this website: Vercel for hosting, including the onboarding's homepage reading, and for the historical application records, Anthropic for the onboarding's draft of your buyers and the Ask assistant, Plausible for cookieless analytics, Kawl Now for the optional voice widget, Google for Analytics and Ads only after you allow each, Cal.com for the booking calendar, Supabase for the database in London that holds waitlist entries, and Resend for the alert email sent from Ireland, with email content and delivery logs stored in the United States. For the product: Railway for the hosted services, Supabase for identity and the database, and Resend for sign-in email. Model providers receive campaign prompts in the product only when their integration is enabled. The full list, with what each receives, is at https://adbuymcp.com/security.

what happens next

Bring the control framework you have to satisfy.

On a call, the founder works through your control framework with you and tells you where a requirement is not met.

Free, with no card.

Talk your market and your plan through with James Rooney, who built AdBuyMCP and wrote its code.