# CattleGrid > CattleGrid builds privacy and data-protection tooling that helps organisations keep personal data compliant, auditable and under control. # Pages ## Features https://cattlegrid.uk/features Features Switch on what you need. Leave the rest off. The whole platform, and how much of it is up to you. CattleGrid is not a single product with a single switch. Features are enabled per account, because the right configuration for a two-partner practice is not the right configuration for a bank. What follows is everything the platform does. Nothing here runs unless you turn it on. ## The gateway Always on. The part every customer gets by default. ##### Drop-in proxy **Change the base URL.** Point your existing provider SDK at the CattleGrid endpoint. No application rewrite, no endpoint agent, no rebuild. ##### Credential swap **Your app never holds the secret.** CattleGrid substitutes the upstream provider credential, so the provider key never sits in your application. ##### Providers **Four, plus anything compatible.** OpenAI, Anthropic, Google Gemini and Mistral from the catalogue, and any provider exposing a standard OpenAI-compatible API. Bring your own keys, or use a subscription where the vendor permits it. ##### Keys and limits **Scoped tightly.** Managed keys, hashed and never stored in plain text, with per-key scopes, allowed providers, rate-limit tier, CORS allowlist and IP allowlist. ##### Streaming **No buffering.** Server-sent events pipe straight back to your application at full speed. ##### Zero retention **On this path, nothing is kept.** Prompt content is never written to disk. Usage is metered asynchronously, without blocking the response. ## The three that do the heavy lifting Anonymisation, the desktop client, and the audit chain. Each has a page of its own. ##### Anonymise / De-anonymise **Send the meaning, keep the identity.** Reversible tokenisation with no persistent key, rule packs for UK PII, financial, legal, secrets and Salesforce, and document inspection across PDF, Word, Excel, OpenDocument and RTF. [**See the Anonymise page**](undefined). ##### Desktop **A workspace, not just a proxy.** AI chat, direct messages, team chat and shared projects for Windows, macOS and Linux, with encrypted local storage and three encryption modes. Included in every tier. [**See the Desktop page**](undefined). ##### Audit, Taint & Compliance **Evidence, not assurances.** Hash-chained records with Ed25519 seals and external time anchoring, taint governance for agent tool calls, and a compliance-officer role with review and freeze. [**See the Audit page**](undefined). ## Detection What the platform recognises, and how it is kept honest. ##### Engines **Four working together.** A rule-pack engine, context-aware regex packs, and a static non-AI engine for environments that require determinism. Detection is deterministic by design: what a rule catches today, it catches tomorrow. ##### Authoring **Write your own.** Create, version, lint and publish rule packs. Test them on the rule bench and run them in preview mode before they touch live traffic. ##### Beyond plain patterns **Evasion is assumed.** Pre-encoded payload detection, side-channel inspection, cross-request fragmentation detection, response-side inspection and multimodal content inspection. ##### Fail-closed **Safe by default.** Where detection cannot complete, the request does not proceed. Capability parity across packs means a gap in one is not a gap in all. ## Beyond the gateway The parts that matter once AI stops being a single API call. ##### MCP Hub **Govern the tools.** A per-tenant namespaced tool registry with role-based access, an approval workflow that makes unapproved tools non-invocable, and a credential vault that never holds plain text. Connect Claude Desktop, Cursor, VS Code and ChatGPT. ##### Context Engine **Provider-agnostic conversations.** A canonical thread with one adapter per provider, so switching provider is a configuration change. Persistence, prompt caching, memory, compaction and context-scoped keys — encrypted and retention-policied under your controls. ##### Agent Skills **One skill, four providers.** Built on the open SKILL.md standard and running unmodified across Anthropic, OpenAI, Gemini and Mistral. Scripts execute in a CattleGrid sandbox; only inference goes to the provider. ##### Collaboration **AI as a participant, not the default.** AI chat, direct messages and team chat as three separate surfaces, with shared chats, projects and real-time delivery enforced by row-level security. ## Running it The administrative surface, for the people who have to answer for all this. ##### Access **SSO and SCIM.** Enterprise single sign-on via Azure AD, Okta, Google Workspace, SAML and OIDC, with group-to-role mappings and SCIM provisioning. MFA enforcement and ownership transfer included. ##### Fleet **Desktop at scale.** Session oversight and revocation, policy-aware update approval, bulk CSV invitations, onboarding configuration and encryption-mode selection. ##### Analytics **What is actually happening.** Usage dashboards with real-time KPIs, metric filtering, CSV export and a per-user Rules Triggered feed. ##### API management **Governed access.** Managed keys, usage dashboards, an audit log, and OpenAPI 3.0 documentation with REST and GraphQL surfaces generated from schema. TypeScript, Python and Go SDKs. ##### Integrations **Where your team already is.** Slack notifications, detection summaries and threshold alerts, SIEM forwarding on the OCSF schema, GRC platform integrations and signed alert webhooks. ##### Billing **Volume, not seats.** Usage metered against gateway throughput and A/D consumption, with a self-service billing portal. Adding people does not add cost. ### Not sure what you need? Most organisations start with the gateway, the GDPR pack and the desktop client, then add capabilities as their exposure becomes clearer. Talk to us and we will scope it against what you actually do, rather than selling you the whole list. ## Audit, Taint & Compliance https://cattlegrid.uk/audit-taint-compliance Audit, Taint & Compliance Evidence you can hand to someone who does not trust you. Hash-chained, independently verifiable, and archived where we cannot reach it. Most audit logs are a promise. Ours is arithmetic. Records are chained, signed with a key you can check without asking us, anchored to timestamps we do not control, and exported nightly to storage you own. If we wanted to alter your history, we could not do it without you being able to prove it. ## The audit chain Six chained tables, built so that tampering is detectable rather than merely discouraged. ##### Hash chaining **Each record locks the last.** A SHA-256 event hash, a prev\_hash link to the record before it, and a per-row HMAC signature. Altering one entry breaks every entry after it. ##### Gapless ordering **Nothing quietly removed.** A signed sequence number is the sole ordering key, so a deleted record leaves a hole that cannot be closed. ##### Independent verification **Ed25519.** An asymmetric seal means a third party — your auditor, your regulator, your client — can verify records without CattleGrid's secret key and without taking our word for anything. ##### External time anchoring **Not our clock.** RFC-3161 trusted timestamps and OpenTimestamps proofs anchor the chain to time sources outside our control, with an anchored high-water mark. ##### Customer-held archival **Your bucket.** A nightly canonical export to your own S3-compatible storage. The evidence lives somewhere we cannot alter it, which is the point. ##### Verification tooling **Check it yourself.** A verification API, plus a standalone external tool that runs independently of the platform. ### What gets recorded Who acted, when, from which session and device, which rules were evaluated and what action followed. Sensitive content is never stored in full — the log captures the event, not the data that triggered it. ## Taint governance AI agents call tools. Tools return content. That content reaches the model — and most governance never looks at it. ##### The problem **Tool output is untrusted input.** A model that reads a web page, a ticket or a document is reading something nobody vetted. Instructions hidden in that content are the current front line. ##### Verdicts **Four outcomes.** Every tool call and response carries a verdict — PASS, WARN, SANITISE or BLOCK — with thresholds you configure per tenant. ##### Approval workflow **Off by default.** Tools are registered per tenant with role-based access. An unapproved tool cannot be invoked at all, and a blocked tool shows a clear reason rather than failing obscurely. ##### Semantic accumulation **Compound risk.** Individually harmless tool responses can add up to something that is not. Accumulated taint across a session is caught before egress, not after. ##### Provenance graph **Show your working.** A per-session causal graph of which sources were touched, which tools were called and where taint accumulated — so an incident can be reconstructed rather than guessed at. ##### Human checkpoints **A person in the loop.** High-impact actions can be gated behind explicit approval, with a timeout that reverts to BLOCK. Silence is never taken as consent. ## For compliance officers A role with its own view, its own powers, and its own audit trail. ##### Conversation review **Tenant-wide.** A compliance-officer-only view of every conversation and direct message across the organisation, with lifecycle state. Reading content is itself an audited act. ##### Freeze **Preserve an incident.** Freeze and unfreeze conversations where something needs holding intact, fully audited in both directions. ##### Under encryption **Still accountable.** Per-message tamper-evident metadata is retained even where end-to-end encryption is in force, so privacy and accountability are not a trade-off. ##### Subject access and erasure **UK GDPR, in practice.** SAR redaction and fulfilment, plus retention-engine and admin-driven erasure under Article 17, with deletion certificates as evidence it happened. Into your SIEM, not just our dashboard. Events are normalised to the OCSF schema and forwarded to your existing SIEM, or pulled via REST and NDJSON streaming. Compliance events have their own dashboard, and integrity verification can be run on demand. Alerting reaches people where they already are — email, Slack, signed webhooks — with thresholds you set rather than ones we assume. Switched on to suit you. Compliance review, conversation history, encryption mode and taint thresholds are all configured per account. What one organisation needs, another is obliged to avoid. Assign and revoke the compliance-officer role yourself. It is a role model, not a support ticket. For how sensitive values are kept out of these records in the first place, see [**Anonymise**](undefined). ## Desktop https://cattlegrid.uk/desktop Desktop A workspace your compliance team can live with. Windows, macOS and Linux. Included in every tier. Most AI governance stops at the API. The desktop client is for the people who aren't developers — the fee earners, advisers and case handlers who just want to ask a question and get on. They get a proper AI workspace with chat, colleagues and shared projects. You get every message inspected on the same path as everything else. ## The workspace What your staff actually use, day to day. ##### AI chat **Any provider you allow.** Provider and model pickers drawn from your live catalogue, streaming replies, markdown rendering, conversation branching and search. All routed through the CattleGrid data plane, never straight to the provider. ##### Colleagues, not just models **DMs and team chat.** Direct messages, group chat and presence sit alongside AI chat as separate surfaces, so AI is something you opt into rather than the default destination for everything you type. ##### Projects **Shared context.** Group related chats and files into a named workspace. Attach a project file straight into an AI conversation and it goes through the full inspection pipeline on the way. ##### In-composer controls **Anonymise as you type.** Toggle A/D in the composer, see inline verdict badges on what you have written, and follow a badge through to the rule that produced it. ##### Context window **No silent truncation.** Token usage is shown as you work, with auto-summarisation when a conversation outgrows the window, so nothing is quietly dropped mid-thread. ##### Voice **Sovereign, not shipped abroad.** Dictation and read-aloud handled on CattleGrid infrastructure rather than a third-party speech service. ## When a rule fires Blocking is only useful if the person on the other end understands what happened. ##### Clear reasons **Not a silent failure.** A blocked request produces a notice card with a reason and a reference — the rule that triggered it, shown without exposing how your system is configured. ##### Redaction in place **Visible, not hidden.** Redacted spans are highlighted and labelled in the message, so staff learn where the line is rather than guessing at it. ##### Rules Triggered **Your own record.** Each user can see their own verdicts and acknowledge them. Compliance officers see the tenant-wide view, with conversation freeze where an incident needs preserving. ##### Offline outbox **Bad train, no problem.** Messages queue in an encrypted local store, retry when the connection returns, and gap markers backfill anything missed. Nothing is lost and nothing bypasses inspection. ## Security on the device The client holds data locally, so it is built as though the laptop will be lost. ##### Encrypted local store **SQLCipher.** The local SQLite database is encrypted at rest. Secrets live in a Stronghold vault; the keychain holds only the vault password and the outbox key. ##### Three encryption modes **Your choice.** Row-level-security delivery, full end-to-end encryption on the Signal protocol, or compliance E2EE with a customer-held key. Audit metadata is preserved in every mode, including under E2EE. ##### Sign-in **OAuth 2.1 with PKCE.** A public client done properly, with multi-account switching for people who work across more than one organisation. ##### Signed updates **Approved by you.** Code-signed for Windows, macOS and Linux with macOS notarisation. Updates are policy-aware, so administrators approve releases and can flag a critical update for immediate rollout. ##### Notifications **No Firebase.** Self-hosted ntfy and UnifiedPush. No FCM, no US-hosted push transit — the notification path stays inside the same jurisdiction as everything else. ##### Devices **Revocable.** Administrators see every desktop session and can revoke any of them. Users can manage their own devices too. ### Bring your own subscription If your team already pays for an Anthropic Pro or Max subscription, or holds provider keys of its own, those can be used through the desktop client and remain fully inspected. Passthrough tokens are held in the Stronghold vault, never in plain text. You do not have to choose between the licence you already bought and the governance you need. Admin panel, in the app. Owners and managers manage team members, roles, provisioning and rollout without leaving the client — alongside gateway settings, MCP Hub administration, encryption mode, invitations by bulk CSV, SCIM token rotation and onboarding. Every administrative action is attributed to an actor, a session and a device, and written to the same audit chain as everything else. Agent Skills run here too. Browse the skills your organisation has enabled and run them from the client, with scripts executing in a CattleGrid-controlled sandbox rather than on the provider's side. Optional, always. The desktop client is included in every tier, but nobody has to install it — the API and MCP Hub routes need only a key and a configured provider. See [**the full feature list**](undefined) or [**how anonymisation works**](undefined). ## Anonymise https://cattlegrid.uk/anonymise Anonymise Send the meaning. Keep the identity. Reversible anonymisation, in memory, per request. Blocking sensitive data protects you, but it also stops the work. Anonymise / De-anonymise takes the other route: identifiers are swapped for tokens before the request leaves CattleGrid, the AI reasons over the tokens perfectly well, and the real values are restored in the reply before it reaches you. Your provider never sees the original. Your team never notices the difference. ## How it works Four steps, all inside a single round trip. ##### Detect **Before send.** Rule packs and detection engines identify the sensitive spans in the outbound request — names, account numbers, client references, credentials. ##### Tokenise **Swap, don't strip.** Each identifier is replaced with a stable token for that request, so the model still understands that two mentions refer to the same thing. Meaning survives; identity doesn't leave. ##### Restore **On the way back.** Real values are substituted back into the reply from an in-memory map before it reaches your application. What your staff read is the answer they expected. ##### Destroy **No key, ever.** The token map is built per request and destroyed on every exit path. There is no persistent A/D key, nothing to store, and nothing to escrow. ### Why this matters This is pseudonymisation under UK GDPR Article 4(5). You remain the controller of the data throughout, and CattleGrid never holds a re-identification key you did not already have. A redacted payload also sends fewer tokens upstream, so the compliance control quietly reduces your provider bill. ## Rule packs Detection is only as good as what it recognises. Packs ship ready to run, and you can write your own. ##### UK PII **GDPR pack.** National Insurance and NHS numbers, postcodes, +44 phone numbers, email addresses, passport numbers. Included in every tier. ##### Financial **FCA-facing.** Card numbers, sort codes, bank account numbers, SWIFT/BIC. For firms whose exposure is transactional. ##### Legal **SRA-facing.** Client references and matter identifiers, for firms where confidentiality is a professional duty rather than a preference. ##### API keys and secrets **Credentials.** Common API-key patterns and AWS access keys — the material most often pasted into an AI tool by accident. ##### Salesforce **CRM records.** Object and record identifiers, for teams whose customer data lives in Salesforce. ##### Write your own **Rule generator.** Where your exposure is specific to your organisation — internal project names, customer codes — author your own packs, linted and versioned, and test them on the rule bench before they go anywhere near live traffic. ## Documents too The same controls, applied to what your staff upload rather than what they type. ##### Formats **PDF, Word, Excel, OpenDocument, RTF.** Files are extracted, inspected against your rules, and discarded. There is no document store. ##### Coverage **Every route.** Including provider file-upload paths such as OpenAI file\_data and Gemini inline\_data, so an upload cannot slip past by taking a different road. ##### Fail-closed **STRICT mode.** If A/D cannot complete safely, the request does not proceed. The safe answer is the default, not a setting you have to remember. ##### Allowance **In every tier.** A monthly A/D allowance is included at every level, and additional usage credit can be purchased at any time. You pay for how much you use it, never per seat. Context-aware, not just pattern-matching. Proximity matching means a number that looks like a sort code is treated as one when it sits beside an account number, and left alone when it doesn't. Detection runs across the rule-pack engine and context-aware regex packs, so the packs catch what plain patterns miss. Redaction is still there when you want it. Where restoring a value serves no purpose, REDACT and REMOVE do the simpler job, with a maximum-removal threshold that escalates to a block if a request turns out to be more sensitive than it first appeared. Preview before you enforce. Run a rule in preview mode and see exactly what it would have caught, on your own traffic, before it changes anything for your staff. Every A/D event is audited — what was tokenised, which rule fired, when, and by whom — without the audit log ever holding the sensitive value itself. See [**Audit & Compliance**](undefined) for how those records are sealed and verified. ## Why did CattleGrid block my prompt? https://cattlegrid.uk/why-did-cattlegrid-block-my-prompt CISO / Head of InfoSec CISO / Head of InfoSec What CattleGrid actually does when you use AI tools ### What's actually going on CattleGrid is the app your organisation uses to talk to AI providers (OpenAI, Anthropic, Google Gemini, Mistral) rather than going to each of those tools directly. You pick your model from the dropdown and type into the same kind of prompt box you'd expect from any AI chat tool. The difference is what happens to your message in the moment between you hitting send and it leaving the building. It isn't there because IT doesn't trust you specifically. It's there because AI tools can't tell the difference between the text you meant to include and the text that was just sitting in the same paste. You copy in a paragraph of client correspondence for a quick summary, and the National Insurance number or account number in that paragraph goes with it. The tool processes all of it, because none of it was flagged as off-limits. This is common, not because people are careless, but because nobody had drawn a line before AI made it this easy to cross one without noticing. ### What happens when you hit a rule Every message is checked, what you typed, not the AI's reply, against rules your organisation has configured. You'll see the result directly in the app: ##### Block. A notice card appears telling you the request didn't go anywhere, with a reason and a reference number. Nothing was forwarded to the AI provider. ##### Redact. The sensitive part of your message is highlighted and replaced with a label, for example \`[REDACTED: UK National Insurance Number]\`, with the rule name shown if you hover over it. The rest of your message goes through as normal. The AI provider sees that something was removed, not what it was. ##### Warn. An amber banner appears. Your message goes through unchanged, but the near-miss is logged. ##### **Log.** Nothing visibly changes. The event is recorded quietly for your organisation's records. (Separately, if your organisation's usage cap is close, you may also see a countdown notice while the app retries automatically. That's a usage limit, not a data-governance rule, and isn't about anything you typed.) Whichever fires, nobody sits and reads your prompts afterwards. The content itself is never written to disk. That's the zero-retention architecture the whole system runs on. What gets kept is a record that an event happened: rule name, time, data type, not the data itself. You can see your own history of these under Rules Triggered in the app. That same record forms an audit trail your organisation can point to if a regulator asks how AI use is governed. It is not a transcript of what you typed. ### What this means for you day to day Once you know the shape of what gets caught, blocks and redactions stop being a surprise. The pattern is almost always the same: real names, real numbers, real client detail pasted in raw. Paraphrase it, or drop the specific numbers, and most requests go through without incident. The upside is genuine. You can use CattleGrid for real work, drafting, summarising, researching, with Claude, GPT, Gemini or whichever model your organisation has enabled, without personally calculating the compliance risk of every prompt before you send it. That calculation is made for you, automatically, in under a millisecond, before the request leaves the building. CattleGrid also includes secure team chat and direct messages, and AI-assisted team chat, for internal collaboration, encrypted according to your organisation's settings. Those work differently under the hood, since they're internal communication rather than outbound calls to an AI provider. This page is specifically about what happens in AI Chat, where the block/redact/warn behaviour above applies. ### What this doesn't do This is worth being direct about, because vague reassurance is worse than none. - It does not read or store your prompts for review. There is nothing to review: the content is never written to disk. - It does not build a profile of what you personally ask AI tools. - It does not inspect or filter what the AI tool sends back to you. Only what leaves your organisation on the way there. - It is not a substitute for judgement. It catches identifiable sensitive data against configured rules, not every conceivable way information could be handled carelessly. If something feels off about a block, that's a conversation with your organisation's IT or compliance team, not a sign the system has flagged you personally. ### Where to go from here If a block doesn't make sense, or a rule seems to be catching things it shouldn't, your fastest route is your organisation's IT or compliance lead. They can see which rule fired and adjust it. If your organisation isn't running CattleGrid yet and you think it should be, forwarding this page is usually the fastest way to start that conversation. - For the technical detail on how inspection works: [Technical Resources ](undefined) - For pricing: [Pricing ](undefined) - If you're the one who makes this decision as well as using the tools day to day (a fair number of people in smaller organisations are both), the free tier is a way to see it running before committing to anything: ## Departmental Lead (IFA / Practice Manager / Head of Legal) https://cattlegrid.uk/ifa-practice-manager-head-of-legal CISO / Head of InfoSec CISO / Head of InfoSec The stake The SRA Standards and Regulations 2019 engage the moment AI tools touch client work. The Code of Conduct for Solicitors sets out Principle 2 (integrity), Principle 7 (client best interests), the duty of competence, client confidentiality, and proper supervision — all of them live obligations, not aspirational ones. The Code of Conduct for Firms adds firm-level governance duties and places COLP accountability squarely on the shoulders of one named individual when third-party technology arrangements go wrong. The SRA has issued its own guidance on generative AI use in practice, and has published warning notices specifically on AI and data governance — this is not a regulator waiting to legislate before it acts. The underlying exposure is not abstract. 71% of UK employees are using AI tools their employer hasn't sanctioned, and 51% do so weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025). In a legal practice, that behaviour has a specific and more serious shape: a fee earner uploading a client contract, a case file, or correspondence to a consumer AI tool to summarise or draft from — at which point client confidentiality and legal professional privilege, protections that exist to protect the client, have been extended to a third party the firm never assessed and the client never consented to. ### What CattleGrid actually does **It applies your privilege and confidentiality boundary through configurable rules, checked before anything goes live.** CattleGrid's inspection engine runs UK-specific pattern templates — National Insurance numbers, addresses, dates of birth, financial identifiers — alongside a custom rule builder your firm can use to flag client names, matter references, or content marked privileged or confidential. Test Bench lets you paste representative case content and see exactly what a rule would catch, and what it would redact, before it's switched on for live traffic. **Document uploads are inspected, not just prompts.** Contracts, case bundles, and correspondence are exactly what fee earners upload to AI tools to summarise — and it is now a governed data path, not a blind spot. CattleGrid extracts and inspects text from PDF, Word (.doc/.docx), Excel spreadsheets, OpenDocument Text, and RTF files against the same policy engine as pasted prompts, then discards the file. Nothing is retained. **The audit trail is the governance evidence a COLP needs.** Every inspection decision — what was sent, what was blocked, what was redacted, when, and under which rule — is written to a cryptographically verifiable record, tamper-evident by design. That is precisely the kind of controlled, audited AI use the SRA's own guidance points firms towards being able to demonstrate, and it exists automatically, without depending on a fee earner remembering to log anything. **Deployment does not disrupt fee-earner workflows.** CattleGrid sits inline between your applications and the AI providers they call — OpenAI, Anthropic, Google Gemini, and Mistral, plus any provider reachable through a standard OpenAI-compatible API. The only change is the web address requests are sent to. Nothing about how a fee earner works day to day needs to change for the governance layer to be in place underneath it. ### What this looks like once it's running A firm running CattleGrid can show, rather than assert, that AI use is supervised: a rule configuration a COLP can point to, an audit trail that stands as governance evidence if the SRA or a client ever asks, and a document-handling boundary that keeps privileged material inside the firm's control rather than inside a consumer AI provider's. That is a materially stronger position heading into a regulatory enquiry, a client's own due-diligence request, or a professional indemnity conversation than "we trust our staff to use good judgement." ### What CattleGrid does not do CattleGrid does not conduct client care letter reviews or provide SRA compliance sign-off, and it does not assess the suitability of AI-generated legal outputs — that judgement remains the fee earner's and the firm's. It does not draft AI governance policies for law firms beyond an Acceptable Use Policy template, which is a starting point, not a substitute for your own policy work. It does not provide advice on professional indemnity implications of AI use. What it provides is the technical control and the evidence trail that make your own governance decisions defensible — not the decisions themselves. ## CISO / Head of InfoSec https://cattlegrid.uk/ciso-head-of-infosec CISO / Head of InfoSec CISO / Head of InfoSec The stake DLP and AI governance tooling was built for a single pattern: a prompt goes out, a completion comes back. That pattern still accounts for most AI traffic, and 71% of UK employees are already using AI tools their employer hasn't sanctioned, with 51% doing so weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025, n=2,003) — so even the pattern the market already governs is under-governed in most organisations. But the pattern itself has changed. Model Context Protocol and tool-calling mean an agent can now invoke a tool, and that tool's output flows straight back into the model's context — a second data path that most AI governance products, built to inspect prompts and completions, were never architected to see. Every vendor in this category can tell you they govern the model. Almost none can tell you what happens to the data flowing between a tool call and the model that receives its output. That gap is not a minor omission. It is the part of the architecture where ungoverned data re-enters the loop. ### What's built, and what isn't yet CattleGrid's position on this is deliberately precise, because overstating it would be worse than saying nothing. **What's live: taint verdicts on MCP tool-call output, in the Desktop app.** When a tool is invoked from CattleGrid Desktop's AI Chat, the result is evaluated and returned with a taint verdict — Pass, Warn, Sanitise, or Block — before it reaches the model. This applies CattleGrid's governance engine to a data path that, everywhere else in the market, currently has none. It is scoped: Desktop app, MCP tool-call output, today. It is not yet coverage of every agent-to-agent hop across every client and provider. **What's live: scoped API-key permissions around MCP and taint data.** Management API keys carry fine-grained scopes — \`mcp\_read\`, \`mcp\_write\`, \`mcp\_admin\`, \`taint\_read\`, \`taint\_write\` — so which applications and automations can read or act on MCP connections and taint verdicts is a configuration decision, not an all-or-nothing grant. Combined with OAuth token issuance and revocation for every connected MCP client (Claude Desktop, Cursor, VS Code, and others), you get an auditable record of what's connected, what scope it holds, and when it last authenticated. **What's live: the underlying inspection engine.** Layer 1 pattern matching — regex and keyword rules, evaluated in-process in under a millisecond — is what actually runs in production today, across 28 pre-built templates for UK PII, financial data, and credentials, plus any custom rules you configure. Domain-specific detection agents for PII, healthcare, legal, and financial content are specified and interface-ready, but not yet live — treat that as roadmap, not current capability. **What's live: the audit chain underneath all of it.** Every inspection decision is written to a record protected by four layers: database triggers that make committed rows immutable, a SHA-256 hash chain linking each row to its predecessor, HMAC-SHA256 signatures using a key held separately from the data, and two automated verification jobs — hash chain checked every 15 minutes, signatures sampled and re-verified hourly. An attacker with database access alone cannot forge a valid signature. This maps directly to ISO 27001 Annex A evidence requirements for access control, audit trail, and incident alerting, and exports to Splunk, Wazuh, and Elastic in CEF, Syslog, NDJSON, or webhook format, with GRC platform connectors for ServiceNow, Archer, MetricStream, and others. ### **What this looks like once it's in place** You can tell your board, and any client's security due-diligence team, that you're the organisation that identified and started closing the tool-calling governance gap before it became a named vulnerability class — with a specific, verifiable answer for how MCP tool output is evaluated today, and an honest account of what's still in build. That is a materially stronger position than either ignoring the gap or claiming it's already solved. ### **What CattleGrid does not do** CattleGrid does not currently govern every agent-to-agent hop across all clients and providers — the live taint verdict coverage is scoped to MCP tool-call output inside the Desktop app, not a comprehensive agentic governance layer. Domain-specific detection for PII, healthcare, legal, and financial content is pending deployment; what actually runs today is Layer 1 pattern matching. CattleGrid does not inspect or govern AI response content outside that scope, does not conduct penetration testing or vulnerability assessment, and does not produce ISO 27001 ISMS documentation itself — it generates evidence that supports your own ISMS, not a substitute for it. ## CIO / IT Manager https://cattlegrid.uk/cio-it-manager CIO / IT Manager CIO / IT Manager The stake Shadow AI is not a future risk your organisation is planning against. It is a current condition. 71% of UK employees are using AI tools their employer has not approved, and 51% do so at least weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025, n=2,003). Separate research puts the proportion of UK organisations with no controls over what data leaves through those tools at 83% (BlackFog/Sapio Research, November 2025, n=1,000 UK organisations). For most organisations this gap is invisible until an incident, an audit, or a client due-diligence questionnaire forces the question. When it does, the IBM Cost of Data Breach Report 2025 puts the additional cost of a breach where shadow AI was involved at £498,000 over the baseline, against an average UK breach cost of £3.29 million. The report the board asks for at that point is usually the one nobody built in advance — and the person asked to produce it, after the fact, is usually IT. The practical problem is not that this is hard to explain in principle. It is that "we need an AI governance layer" tends to arrive at board level as an abstraction, and abstractions are difficult to budget, staff, or schedule against. What boards actually want to know is what it costs, what it touches, and how long it takes. ### What CattleGrid actually does **Deployment is a URL change.** CattleGrid sits as a transparent proxy between your applications and the AI providers they call. The only change your engineering team makes is the base URL each request is sent to — headers, request bodies, authentication, and response handling all pass through unchanged. It works across OpenAI, Anthropic, Google Gemini, and Mistral, plus any provider that exposes a standard OpenAI-compatible API, so you are not locked into governing a single vendor's traffic. **Rules run in under a millisecond, in-process, with no external calls.** Content inspection happens inline, using regex and keyword pattern matching evaluated against every request before it leaves your environment. Twenty-eight pre-built templates cover UK-specific PII (National Insurance numbers, NHS numbers, postcodes, passport numbers), financial data (sort codes, account numbers, card numbers with checksum validation), and credentials (API keys, AWS keys, private key headers). Each template ships in a standard and a context-aware variant, the latter using keyword proximity and pattern exclusion to cut false positives. Rules can block, redact, warn, or log, in that order of severity, and every rule can be scoped to specific providers. **Test Bench lets you see the outcome before it's live.** Paste sample content — a realistic prompt, a test NI number, an edge case that shouldn't match — select the rules you want to check, and see exactly what would trigger and what the redacted output would look like, without a single request touching real traffic. It is the step that turns "trust us" into something you can verify yourself before enabling a rule for your organisation. **Rate limiting and visibility sit in one place.** Five pre-configured tiers — Free, Starter, Professional, Enterprise, and Unlimited — enforce per-minute, per-hour, per-day, and per-month ceilings per API key, and changes to rules, providers, or limits take effect across live traffic within one to two seconds — no redeploy required. The dashboard shows request volume, block rate, top triggered rules, and active alerts in real time, so visibility does not depend on someone remembering to pull a report. **Team management matches how IT actually delegates.** Four roles — Owner, Admin, Manager, Viewer — govern who can change what, with email or bulk CSV invites and ownership transfer built in. Every configuration change is written to an immutable audit log, cryptographically hash-chained so a record cannot be altered without the tampering being detectable — useful when the question is not just "what happened" but "who changed the rule, and when." ### What this looks like once it's running An organisation running CattleGrid can answer the "what does this involve" question with a deployment timeline measured in a URL change, not a project plan. It can show, rather than assert, what a given rule would have caught, because Test Bench makes that checkable before anything goes live. And it has an answer ready the next time a client, an auditor, or a board member asks who has visibility over what staff are sending to AI tools — because the audit log already has that answer, timestamped and tamper-evident, before the question is asked. ### What CattleGrid does not do CattleGrid inspects outbound AI API traffic — the input layer. It does not inspect, analyse, or govern AI responses, and it is not a substitute for a broader SIEM or DLP deployment. It governs AI traffic sent through API calls; it does not extend to AI tools accessed directly through a browser, so a member of staff visiting a consumer AI tool's website directly sits outside what API-layer interception can see. It does not conduct penetration testing, vulnerability assessment, or security audits, and it does not produce ISO 27001 ISMS documentation — those remain separate workstreams CattleGrid's evidence can support but not replace. ## DPO / Compliance Officer https://cattlegrid.uk/dpo-compliance-officer DPO / Compliance Officer DPO / Compliance Officer The stake A processor relationship does not require a signed contract to exist. It requires personal data to be sent to a third party for processing. Every time a member of staff pastes a client name, a case reference, or an employee record into a public AI tool, that data has left your organisation and reached a processor you almost certainly have not documented, assessed, or put a DPA in front of. This is not a hypothetical gap. 71% of UK employees are using AI tools their employer has not sanctioned, and 51% do so at least weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025, n=2,003). 83% of UK organisations have no controls over what data leaves through those tools (BlackFog/Sapio Research, November 2025, n=1,000 UK organisations). The IBM Cost of Data Breach Report 2025 puts the additional cost of a breach where shadow AI was involved at £498,000 over the baseline, against an average UK breach cost of £3.29 million. None of that is a technology problem you can solve with a memo. It is a visibility problem, and visibility is what an audit trail is for. ### What CattleGrid actually does **It enforces the policy you already wrote, on every request, not just the ones people remember.** CattleGrid sits inline between your applications and the AI providers they call, inspecting the content of every outbound prompt against your configured rules before it leaves. Twenty-eight pre-built templates cover UK-specific personal data — National Insurance numbers, NHS numbers, postcodes, passport numbers, phone numbers, dates of birth — alongside financial data and credentials, with block, redact, warn, or log actions assignable per rule. **The audit trail is cryptographically verifiable — tamper-evident by design.** Every inspection decision is written to an immutable record, chained using SHA-256 hashing and signed with HMAC-SHA256 keys held separately in encrypted storage. Two automated jobs run continuously: one verifies the hash chain every fifteen minutes, the other samples and re-verifies signatures hourly. A record cannot be altered after the fact without that tampering being detected automatically — this is what "audit trail" means as an evidentiary standard, not as a phrase. **Right to erasure comes with proof, not just an action.** When an account is deleted under UK GDPR Article 17, CattleGrid generates a deletion certificate: a timestamped, itemised record of exactly what was erased, table by table, retained permanently as evidence. The certificate itself contains no personal data — only counts and identifiers — so it can be produced for a data subject or the ICO without creating a fresh disclosure risk. **Document uploads get the same governance as prompts.** File uploads to AI tools are extracted, inspected against the same policy engine, and discarded — never stored. Coverage runs across PDF, Word (.doc/.docx), Excel spreadsheets, OpenDocument Text, and RTF. This closes a gap most DPOs haven't yet had to think about: a contract or a spreadsheet uploaded to summarise is exactly as exposed as a pasted paragraph, and now gets inspected the same way. **Reversible tokenisation, precisely scoped.** Where a workflow genuinely needs the AI's output to reference a real client name or account number, CattleGrid can swap identifiers for tokens on the way out and restore the real values on the way back — the AI provider never sees the underlying value. There is no persistent key: the token map exists only in memory for that single request and is destroyed on every exit path. This is pseudonymisation under UK GDPR Article 4(5), not anonymisation — the data remains personal data throughout, and your organisation remains the controller of it. That distinction matters for your RoPA, and CattleGrid's own documentation states it plainly rather than blurring it. **Everything exports to where your governance work already happens.** Compliance events stream to SIEM platforms (Splunk, Wazuh, Elastic) and GRC platforms (ServiceNow, Archer, MetricStream, and others), in CEF, Syslog, NDJSON, or webhook format, so the evidence CattleGrid generates lands inside the systems your team already uses to manage it. ### What this looks like once it's running You can answer "does our AI usage create an undocumented processor relationship" with a governance record, not a guess — what left, what was blocked, what was redacted, and when, for every AI interaction across the organisation. When a client's due-diligence questionnaire or an ICO enquiry asks you to demonstrate technical measures under Article 32, you have a timestamped answer rather than a policy document nobody can prove was followed. ### What CattleGrid does not do CattleGrid does not conduct or produce Data Protection Impact Assessments, maintain your Record of Processing Activities, or draft privacy notices — those remain judgement calls only you can make, informed by evidence CattleGrid provides. It does not advise on lawful basis, determine whether an incident meets the ICO notification threshold, or negotiate DPAs with AI providers on your behalf. It does not designate or substitute for a DPO function. And reversible tokenisation does not achieve anonymisation under Article 4(9): CattleGrid does not retain a re-identification key at any point — the token map is ephemeral and self-erasing, so there is nothing to escrow or rotate — but the data your organisation controls remains personal data throughout, and that responsibility stays yours. ## MD / Senior Partner / CEO https://cattlegrid.uk/md-senior-partner-ceo MD / Senior Partner / CEO MD / Senior Partner / CEO The stake Your organisation is already using AI, whether or not that decision has been made formally. 71% of UK employees are using AI tools their employer has not approved, and 51% do so at least weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025, n=2,003). 83% of UK organisations have no controls over what data leaves through those tools (BlackFog/Sapio Research, November 2025, n=1,000 UK organisations). This is not a question of whether your people will adopt AI. They already have. The financial exposure this creates is specific and quantified, not speculative. The IBM Cost of Data Breach Report 2025 puts the additional cost of a breach involving shadow AI at £498,000 over the baseline — against an average UK breach cost of £3.29 million, rising to £5.74 million in financial services. Regulatory exposure compounds it: the ICO can fine up to £17.5 million or 4% of global turnover for UK GDPR failures, and where the EU AI Act applies, penalties for the most serious violations reach €35 million or 7% of global annual turnover. None of these figures require a catastrophic incident to become relevant. A single unmanaged data flow, surfaced during a client's due-diligence review or a regulatory enquiry, is enough to put the question in front of the board. ### What a board-level control actually looks like A governance layer does not need to be complicated to be effective, and at board level it should not be described as if it were. CattleGrid sits between your organisation's applications and the AI providers they call, inspecting what leaves before it leaves. It blocks or redacts content that matches your configured rules, keeps an unalterable record of what happened, and does this on every request, not on a sample. Deployment is a change to a web address in your application configuration — not a project, not a procurement cycle, not months of integration work. The governance record itself is the asset a board can point to. Every decision — what was sent, what was blocked, what was redacted — is written to a cryptographically verifiable audit trail, tamper-evident by design rather than by policy. If a regulator, an enterprise client's due-diligence team, or your own auditors ask what control exists, the answer is a timestamped record, not an assurance. On sovereignty, the precise position is this: what CattleGrid knows about your organisation never touches US jurisdiction. What reaches the AI provider has already been cleaned. CattleGrid is a UK-registered company running on UK infrastructure, with no US parent entity, so the governance layer itself — your policy configuration, your audit logs, your enforcement records — sits outside CLOUD Act jurisdiction. This is not a claim that AI processing as a whole becomes sovereign: the AI providers your organisation calls remain US-domiciled companies, and inference still reaches them. What changes is that what reaches them has been governed first, and what CattleGrid holds about you never leaves UK jurisdiction. Set against the numbers above, the cost of putting this control in place is not the board's real question. The real question is what an unmanaged AI data flow costs when it surfaces on someone else's timetable rather than yours — and that figure is already quantified, above. ### What this looks like once it's in place A board that has deployed this can answer the exposure question before it is asked, with a governance record rather than a promise. It is in a materially stronger competitive position with enterprise and public sector clients who now ask AI governance questions as standard due diligence. And it has drawn a clear, defensible line between "we govern AI use" and "we hope nothing goes wrong" — a distinction regulators and clients are increasingly testing for directly. ### What CattleGrid does not do CattleGrid is a technical control, not a substitute for governance decisions your organisation still has to make. It does not provide FCA-regulated advice of any kind, does not produce SMCR Statements of Responsibilities, and does not conduct Data Protection Impact Assessments. It does not assess the suitability of AI-generated outputs — legal, financial, or otherwise — and it does not replace the judgement of the people accountable for those outputs. What it provides is the evidence base that makes those judgements defensible. ## CattleGrid https://cattlegrid.uk/ Security checkpoint that reviews everything your team sends to an AI API preventing data leaks CattleGrid is a British technology company that provides a security system to protect organisations using AI API services like Anthropic’s Claude, OpenAI, Google's Gemini and more. Think of it as an invisible security checkpoint that reviews everything your team sends to an AI Provider before it ever leaves your control. When employees use AI tools to assist with their work, they might accidentally include sensitive information such as customer National Insurance Numbers, Credit Card details, Medical Records, or confidential company secrets. CattleGrid detects this data and prevents it from being sent, keeping your organisation safe and compliant with data regulations. What changes when CattleGrid is in front of your AI traffic ### Without CattleGrid - An employee pastes customer data into an AI chat without thinking - Sensitive information leaves your network and goes to external servers - Your organisation may breach UK GDPR, the DPA 2018, or your sector's own rules - You have no record of what was sent or when - You only find out about the problem after damage is done ### With CattleGrid - Every AI request is automatically scanned before it is sent to the AI platform - Sensitive information is detected and blocked instantly - The employee sees a clear message explaining what was blocked and why - Administrators receive immediate alerts about policy violations - Complete records are kept for compliance audits - The result isn't less AI — it's more of it, used with confidence, because the guardrail is doing the worrying for you At its core, from first principles, CattleGrid serves as a critical control layer for organisations seeking to align with UK GDPR and the Data Protection Act 2018, providing the oversight and risk mitigation that enterprise AI adoption requires. By implementing a Zero Trust, Zero Retention model on the gateway path — memory-only processing, with inspection applied before anything leaves your control — the platform ensures sensitive data cannot exit the organisation unseen, and supports the data minimisation and storage limitation principles championed by the ICO. AI is the biggest productivity shift most organisations will see this decade. The point of governing it is to be able to say yes to it. Compatible with the providers your team already uses — plus any OpenAI-compatible API ## Contact https://cattlegrid.uk/contact ## Technical https://cattlegrid.uk/technical Technical A gateway, not an agent. Connect how it suits you. Everything you decide to inspect, is inspected. CattleGrid operates as a governance layer at the network boundary — between your organisation's applications and the AI services your staff are using. No endpoint agent is required and your application behaviour is unchanged. Point your own systems at the gateway with an API key, connect through the MCP Hub, or install the desktop client — whatever you decide to inspect is inspected on the same path, whichever route it arrives by. Our target overhead on Layer 1 inspection is under 8 ms, subject to your upstream provider. Everything else goes through untouched, at full speed: your teams get the tools they want, and you get to know what left the building. ## How it works The architecture is deliberately straightforward. Applications — internal tools, third-party software, or direct browser interactions — route AI API traffic through CattleGrid before it reaches the provider. No changes are required to those applications, and no software has to be installed on user machines: the API and MCP Hub routes need only a key and a provider configured on the CattleGrid platform. Where a team wants a client, the desktop app is available and runs through the same inspection path. The intervention happens at the network layer either way. ##### **Intercept** **Request received** - Every outbound AI API call is routed through the CattleGrid gateway before reaching any external provider. ##### Inspect **Policy applied** - Content is scanned in memory against your data classification rules — PII, financial data, trade secrets, custom-defined terms. ##### **Pass** **Clean request proceeds** - No policy match. The request continues to the AI provider unmodified, in the same round trip. ##### Block, Redact, or Flag **Policy match found** - Depending on the rule: the request is stopped before it leaves CattleGrid, the matched content is redacted and the request continues, or the request proceeds with an alert logged for review — whichever your policy specifies. ## Document Inspection and Anonymise / De-anonymise The core gateway is always on and covers every customer by default. These two capabilities extend it to a wider surface. Both are included in every tier with a monthly allowance, and additional usage credit can be purchased at any time. ### File Upload & Document Inspection. The same block/redact/flag policy engine applied to file uploads, not just typed prompts. Covers PDF, Word (.doc/.docx), Excel (.xlsx), OpenDocument Text (.odt), and RTF. The file is extracted, inspected, and discarded — never stored, never written to disk. Same zero-retention posture as prompt inspection, just applied to a wider surface. ### Reversible Tokenisation. Identifiers are swapped for tokens before the request leaves CattleGrid, so the AI provider only ever sees the token. On the way back, real values are restored from an in-memory map that exists for that single round trip only, then destroyed — no persistent key, nothing to store or escrow. This is pseudonymisation under UK GDPR Article 4(5): you remain controller of the data throughout, and CattleGrid never holds a re-identification key you didn't already have. Included in every tier with a monthly allowance — [**full detail on the Anonymise page**](undefined). ### ## Technical Specification ##### Gateway latency **Sub-8 ms target.** Inspection overhead per request, subject to your upstream AI provider's own response time. ##### Architecture type **API proxy gateway.** Network-level interception. No endpoint agents. No application modification required. ##### Data retention **Zero on the gateway path.** Inspected content exists in memory only, is never written to disc, and sensitive fragments from blocked requests are never stored. Conversation history, persistent memory and compliance review are separate features — off unless you switch them on, and retention is under your control when you do. ##### Deployment model **SaaS.** On-premises deployment is possible on the Custom tier, following a conversation with us to assess what you actually need. It is not an off-the-shelf option. ##### Jurisdiction **European by design.** CattleGrid is UK-registered and UK-owned, with no overseas parent. Production runs on Civo UK, with Civo Frankfurt providing resilience — and available as a primary EU location for organisations that need their data resident inside the EU. Wherever it sits, it stays under UK and EU law, and no extraterritorial regime reaches the governance layer. One legal framework, and nobody outside it able to move the goalposts or demand access to your data. ##### Tenant isolation **Enforced at the database level.** Each organisation's configuration, rules and audit data are isolated by row-level security and per-tenant namespacing. ##### Data residency **Choose where it lives.** UK by default, on Civo UK in London. Where an organisation needs its data resident in the EU, we can run it from our Frankfurt site instead — scoped with you, in the same way as an on-premises deployment. Either way it stays inside European law. #### Audit trail Every request is logged: who sent it, when, which rules were evaluated, and what action was taken. Sensitive content is never stored in full — the log captures the event, not the data. Tamper-evident by design: records are hash-chained, sealed with an Ed25519 signature that a third party can verify without our key, and anchored to external RFC-3161 timestamps. Exportable as evidence for your own audits and UK GDPR governance obligations, via REST, NDJSON streaming or OCSF-normalised SIEM forwarding. Real-time dashboards and alerting by email, Slack and your existing SIEM. ## Deployment The integration touchpoints are intentionally limited. CattleGrid connects to your existing AI provider API credentials and becomes the routing endpoint for your applications. Nothing changes downstream. No existing applications need to be rebuilt or reconfigured beyond pointing their API calls to the gateway.. ##### Getting started ### Hosted on European infrastructure 1. Connect your AI provider API credentials to CattleGrid. 2. Enable pre-built detection rules or define your own. 3. Point your applications to the CattleGrid gateway endpoint. 4. Verify via the test interface. Go live. ##### On-premises - custom engagement ### Within your own infrastructure For organisations with data residency obligations, air-gap requirements, or a security architecture that requires internal deployment. Available on the Custom tier, scoped with us against what you actually need — not an off-the-shelf option. 1. Deploy within your existing network boundary. 2. Configure against your internal security policies. 3. Integrate with existing SIEM and alerting infrastructure. 4. No outbound data. Audit logs remain on-premises. ## Provider Compatibility CattleGrid is not tied to a single AI provider. It operates across the platforms UK enterprise AI workloads actually run on today. ##### OpenAI (direct) Direct API access. Consumer and enterprise tiers. ##### Anthropic (direct) Claude API. Direct integration. ##### Google Gemini (direct) Direct API access to Google's model family. ##### Mistral AI (direct) European-domiciled provider, of particular relevance for EU data sovereignty requirements. ##### Plus any OpenAI-compatible API. If your provider exposes a standard OpenAI-compatible endpoint, CattleGrid covers it without custom integration work. ## Data Handling Inspected content exists in memory only, processed in milliseconds, then gone. Nothing is written to disc. Sensitive fragments from blocked requests are never stored in full. The audit log records the event — who, when, which rule, what action — without preserving the data that triggered it. ##### Credentials, encrypted at rest API credentials connecting to AI providers are encrypted at rest using AES-256-GCM. They are never exposed in logs or audit exports. ##### Tenant isolation, complete Each organisation's configuration, rules and audit data are isolated by row-level security and per-tenant namespacing, enforced at the database level rather than by application logic. ##### UK and EU law only CattleGrid is UK-registered, UK-owned and running on European infrastructure. For regulated firms the question 'who else could compel access to this?' has one short answer, and it is a European one. No overseas parent company, no foreign disclosure regime reaching through the governance layer. For UK firms that means UK law. For firms in the EU it means data that never leaves the legal framework you already report under — and, where residency is a requirement rather than a preference, a European home for it. ##### Audit exports, compliance-ready Logs are exportable as evidence for your own audits and UK GDPR governance obligations. Nightly canonical export to your own S3-compatible bucket is available, so the evidence lives somewhere we cannot reach. ## Access Model CattleGrid is role-based. The people who need visibility get it; the people who need to act can act; and the people who just need to use AI tools encounter nothing different at all. ##### End users Nothing, ordinarily. AI tools continue to function as normal. When a request is blocked, the user receives a clear notification explaining why. Nothing to install unless your organisation chooses to roll out the desktop client. No training required beyond awareness of the policy. ##### Administrators Configure detection rules via the visual dashboard. Define what categories of data are governed and how. Manage team access and permissions. All administrative actions are logged. ##### Security teams Real-time dashboard visibility across the organisation's AI usage. Immediate alerts on policy violations — via dashboard notification, email, or Slack. Integration with existing SIEM infrastructure. Full audit trail for incident investigation. ##### Compliance officers Exportable reports for regulatory audits. Demonstration of data protection controls in operation. Pre-built templates for UK GDPR governance evidence. Configurable data retention policies. ## Pricing https://cattlegrid.uk/pricing Pricing We don't believe our customers should pay a security tax. Managing a business and keeping pace with regulation is burden enough — so we price on what you use, not on how many people you employ. ### There is no per-seat licence. You pay for what you use — the requests and data you put through the gateway, the redaction and anonymisation you consume, and the rule packs you run. Every tier includes an allowance, and additional usage credit can be purchased at any time. ### **Get started free... [hello@cattlegrid.uk](mailto:hello@cattlegrid.uk) Tier 1 — Launch — covers inspection, blocking and redaction with the GDPR (PII) rule pack, plus a limited Anonymise / De-anonymise allowance. It is free while we launch, and if you sign up during the launch period you keep it. Regulated firms can add packs built for their sector — FCA, Legal, Salesforce, and API keys and secrets. Where your exposure is specific to your organisation, the rule generator lets you write and version your own. **Get started free... [hello@cattlegrid.uk](mailto:hello@cattlegrid.uk) Anonymise / De-anonymise extends the same block, redact and tokenise controls to the files your staff upload — Word, PDF, Excel, OpenDocument and RTF. Files are extracted, inspected and discarded; nothing is stored. Usage is measured by document volume and size against your plan's allowance, and additional credit can be purchased at any time. **If that's what you need then talk to us so we can get you set up [hello@cattlegrid.uk](mailto:hello@cattlegrid.uk) Pricing ### Launch £FREE Monthly Get protected on the desktop, free while we launch. - Desktop app - GDPR (PII) rule pack - API access for testing - Limited A/D allowance Launch offer. Sign up during launch and you keep it — if we withdraw the offer it applies to new sign-ups only, never to you. ### API £50.00 From, monthly Point your own systems at the gateway. Full API access with room to run. - Everything in Launch - Full API access - Increased rate limits - Increased A/D allowance ### Custom Packs £250.00 From, monthly For regulated firms that need detection written against their own obligations. - Everything in API - One additional rule pack — FCA, Legal, Salesforce or API keys and secrets - Higher rate limits - Increased A/D allowance ### Custom £POA Custom Built around your environment and scoped with us. - Everything in Custom Packs - Custom rule packs and rule generator - Highest limits and A/D allowance - On-premises deployment available ## Terms & Conditions https://cattlegrid.uk/terms-and-conditions ## Terms & Conditions CattleGrid Ltd — Company Number 17020793 (England and Wales) — 32 Salisbury Avenue, Cheltenham, England, GL51 3BS — Version 1.0 — Last Updated: 26 February 2026 ## 1. Introduction These terms govern access to the CattleGrid website and the enterprise API security gateway service. By using the Site or Service, you agree to be bound by these Terms. Users representing organisations must confirm authority to bind that entity. ## 2. Definitions - Account: Registered account on the CattleGrid platform - Customer / you / your: Individual or organisation using Site or Service - Service: CattleGrid enterprise API security gateway including features, tools, dashboards, and integrations - AI Provider: Third-party artificial intelligence service providers (examples: Anthropic, Mistral AI, OpenAI) - Subscription: Selected paid plan for Service access ## 3. The Service ### 3.1 Description CattleGrid operates as a transparent proxy between applications and third-party AI Provider APIs. It inspects outbound requests for sensitive data, applies configurable protection rules, and prevents unauthorised transmission of sensitive information. ### 3.2 Independence CattleGrid is independent and not affiliated with, endorsed by, or sponsored by any AI Provider. Users maintain responsibility for their own valid API keys and subscriptions. Third-party service use remains subject to those providers' terms of service. ### 3.3 Service Availability The Service is provided on an 'as available' basis, and we do not guarantee uninterrupted operation. The company reserves rights to suspend access for maintenance with reasonable notice. ## 4. Account Registration Users must create an Account with accurate, current, complete information kept up to date. Users are responsible for credential confidentiality and all Account activities. Unauthorised use must be reported immediately to [support@cattlegrid.uk](mailto:support@cattlegrid.uk). CattleGrid reserves suspension or termination rights for suspected breaches. ## 5. Subscriptions and Payment ### 5.1 Pricing Service access requires a paid Subscription. Pricing appears on the Site in GBP, exclusive of VAT unless stated otherwise. ### 5.2 Payment Payment is due in advance per billing period via methods specified on the Site. Third-party payment providers process payments under their terms. ### 5.3 Renewal and Cancellation Subscriptions renew automatically unless cancelled before renewal. Cancellation through the Account dashboard takes effect at the period end with no partial refunds. ### 5.4 Changes to Pricing We will give you at least 30 days' written notice of any price increase. You may cancel before new pricing takes effect. ## 6. Acceptable Use Users must use the Site and Service lawfully per these Terms. Prohibited activities include: - Unlawful or prohibited purposes - Unauthorised access attempts - Transmission of defamatory, offensive, or objectionable material - Service operation interference or disruption - Reverse engineering, decompiling, or disassembling - Reselling, sublicensing, or third-party availability without consent - Circumventing AI Provider security measures or data protection controls ## 7. Data Protection Personal data processing is governed by the Privacy Policy. The company acts as data processor; customers act as data controllers. CattleGrid processes all data ephemerally in memory only. Only metadata about security events is recorded, never the sensitive data itself. ## 8. Intellectual Property All intellectual property rights in the Site and Service are owned by or licenced to CattleGrid. Users retain data ownership but grant a limited, non-exclusive processing licence for Service provision. ## 9. Limitation of Liability ### 9.1 Exclusions Liability for death, personal injury, negligence, fraud, or non-excludable English law liabilities cannot be limited. ### 9.2 Limitations Our total aggregate liability to you shall not exceed the total fees paid by you in the 12 months immediately preceding the event giving rise to the claim. ### 9.3 Indirect Losses We shall not be liable for any indirect, incidental, special, consequential, or punitive damages, or business losses. ### 9.4 No Guarantee of Detection We do not guarantee that the Service will detect all sensitive data in all circumstances. Users remain responsible for implementing appropriate organisational data protection measures. ## 10. Indemnification Users indemnify CattleGrid, its directors, officers, employees, and agents against claims, losses, damages, liabilities, and expenses arising from Service use, Term breaches, or legal violations. ## 11. Suspension and Termination CattleGrid may immediately suspend or terminate access for breaches, legal requirements, or Service discontinuation (with reasonable notice). Termination ends usage rights immediately. Surviving clauses include limitation of liability, indemnification, and governing law provisions. ## 12. Changes to These Terms Updates occur periodically with email notification or Site notice at least 30 days before effectiveness. Continued use after effective dates indicates acceptance. Non-agreement requires stopping Service use and Subscription cancellation. ## 13. General Provisions ### 13.1 Entire Agreement These Terms, Privacy Policy, and Data Processing Agreement constitute the complete agreement regarding the Site and Service. ### 13.2 Severability Invalid or unenforceable provisions are enforced to the maximum extent possible; remaining provisions stay fully effective. ### 13.3 Waiver Non-exercise of any right or remedy does not constitute a waiver. ### 13.4 Assignment Users cannot assign rights or obligations without written consent. CattleGrid may assign to business successors. ### 13.5 Third-Party Rights No third parties gain rights under these Terms per the Contracts (Rights of Third Parties) Act 1999. ## 14. Governing Law and Jurisdiction These Terms are governed by the law of England and Wales. Disputes are subject to the exclusive jurisdiction of the courts of England and Wales. ICO Registration: ZC098407 — © 2026 CattleGrid. All Rights Reserved. ## Privacy Policy https://cattlegrid.uk/privacy-policy ## Cattle Grid Ltd - Privacy Policy Version 1.0 – March 2026 – cattlegrid.uk ## Who This Applies To This policy covers anyone whose personal data CattleGrid Ltd processes: website visitors, prospective and current customers, and authorised service users. The content of AI prompts inspected by the gateway is subject to our zero-retention architecture and is never stored — it falls outside this policy's scope. ## 1. Who We Are CattleGrid Ltd is the data controller for the personal data described in this policy. - Registered name: CattleGrid Ltd - Company number: 17020793 (England and Wales) - Address: 32 Salisbury Avenue, Cheltenham, GL51 3BS - General enquiries: [support@cattlegrid.uk](mailto:support@cattlegrid.uk) - Data protection contact: [compliance@cattlegrid.uk](mailto:compliance@cattlegrid.uk) - Website: cattlegrid.uk No Data Protection Officer has been appointed. Direct data protection questions to [compliance@cattlegrid.uk](mailto:compliance@cattlegrid.uk). ## 2. Personal Data We Collect ### 2.1 Website Visitors - Contact form submissions (name, business email, company name, message content) - Technical data (IP address, browser type, device type, pages visited, timestamps via cookies and server logs) **Legal basis:** Legitimate interests (UK GDPR Article 6(1)(f)) in operating our website securely and responding to enquiries. ### 2.2 Customers and Account Holders - Account data (name, job title, business email, company name) - Billing data (billing address, VAT number; payment cards processed by external provider) - Subscription data (plan type, dates, usage tier) - Correspondence (support requests, emails, communications) **Legal bases:** Contract performance, legal obligation for tax/billing records, and legitimate interests for security and fraud prevention. ### 2.3 Authorised Users of the CattleGrid Service - Identity data (name, business email) - Audit log metadata (user identifier, interaction timestamp, triggered policy rules, action taken) We do not log the content of AI prompts. Legal bases include contract performance and legal obligation under ISO 42001 and EU AI Act compliance. ### 2.4 Marketing Communications Where opted-in, CattleGrid sends product information and regulatory updates using consent as the legal basis. Withdrawal is available via unsubscribe links or [compliance@cattlegrid.uk](mailto:compliance@cattlegrid.uk). ## 3. Zero-Retention Architecture Customer Data — the substantive content of what your employees send to AI services — exists only in memory for the milliseconds required to inspect it against your policy rules. It is never written to disk, database, or log. We log only metadata (who, when, which rules, outcome), never content. If a data subject asks what we hold about them, the honest answer is: account and audit metadata, not the substance of their AI interactions. ## 4. How We Use Personal Data ## Meet the Team https://cattlegrid.uk/meet-the-team Meet the Team Who is behind CattleGrid? CattleGrid is a British technology company built by three people who have spent careers inside enterprise technology, healthcare data, and design. One co-founder came to technology through Microsoft Healthcare and fifteen years in enterprise sales. One built the product. One shapes how it looks and how it communicates. Between them, they have watched organisations make expensive, avoidable mistakes with technology for over two decades. ### Rob Harrison — Co-Founder Rob Harrison brings over 25 years of experience in the internet industry spanning infrastructure, security, SaaS, and software development. He founded and ran a business ISP, giving him first-hand understanding of the operational demands of delivering reliable, secure services at scale. That experience sharpened a career-long focus on bridging business requirements with technical delivery — ensuring architecture serves commercial reality, not the other way around. His technical depth covers distributed and geolocation computing, container orchestration with Kubernetes and k3s, infrastructure-as-code with OpenTofu, and API-driven automation across multiple sectors. A hands-on engineer who still writes code and reviews architecture daily, Rob brings a rare combination of commercial instinct and deep technical fluency to everything CattleGrid builds. Rob is a committed advocate for open-source tooling and holistic security — the principle that security is not a layer bolted on after delivery but a design constraint present from the first line of architecture. He firmly believes that every company, irrespective of size, deserves enterprise-grade protection. CattleGrid exists because Rob saw the same problem everywhere: organisations locked out of AI’s potential by legitimate fears about data exposure, or worse, racing ahead without understanding the risks. His position is simple — every business should harness what AI can deliver, but none should have to gamble their data to do it. CattleGrid is a sovereign AI compliance gateway available as SaaS with on-premises and edge deployment options, built entirely on open-source foundations, making that belief a reality. ### Brian Painting — Co-Founder Brian is an experienced sales leader with over 25 years in software. He has brought award winning software solutions to market, across the UK healthcare and pharmaceutical markets. He has an extensive background in the regulation and governance space and worked with data protection teams, Information governance leaders, NOCs/SOCs as well as some of the UKS largest software suppliers. He has worked in the Technology industry shaping and refining industry alignment and go to market strategies for start ups, scale ups, as well as dedicated UK sovereign providers and global platforms like Microsoft. He is passionate about data privacy and the ongoing commoditisation of citizen and consumer data by corporate interests. His long experience in the industry helps shape a view that recognises the largely benign benefits of working with commodity software providers needs to be remodelled as today’s ever shifting geopolitical boundaries fundamentally realign our data requirements. He believes open standards afford innovators and software providers alike the ability to develop new solutions to the advantages of business and the public sector alike at scale. He is excited to see UK plc harness all the innovation that AI can bring, safely, economically, securely and sustainably. ### Jack Stafford — Co-Founder Over three decades working across design, digital communications, and technology, Jack has had a closer view than most of how UK businesses actually adopt new tools. Not in boardrooms, but in the everyday decisions made by people trying to do their jobs faster and more effectively. Working alongside clients including SAP, QinetiQ, Vodafone, and Canon, he watched organisations embrace the potential of emerging technology with genuine enthusiasm and, frequently, without anything resembling a safety harness. AI has accelerated that pattern considerably. That observation sits at the centre of what Jack brings to CattleGrid. Communicating complex technology clearly, to people who are sceptical, time-poor, and making decisions with real consequences, is a discipline that takes years to develop. Jack has spent his career developing it. His background spans internal and external communications, brand, and digital services, with a particular focus on helping organisations articulate what they do to audiences who need to understand it rather than be impressed by it. He founded ST Webhosting Ltd, which provides managed web hosting and digital services, and runs Jack Stafford Creative, working with SMEs on consultancy, design, and brand development. CattleGrid’s audience does not respond to vendor theatre. Jack’s role is to ensure they never have to. ## CattleGrid AI Penalty Exposure Calculator https://cattlegrid.uk/cattlegrid-ai-penalty-exposure-calculator AI Penalty Exposure Calculator — CattleGrid Regulatory exposure tool AI Penalty Exposure Calculator Your staff are using AI tools. Some of that usage creates regulatory exposure you have not yet quantified. This tool shows the statutory maximum penalties at stake under UK GDPR and the EU AI Act — based on your turnover band and sector. Step 1 of 3 What is your organisation's approximate annual turnover? Under £2 million typically under 50 employees £2 million – £10 million typically 50–100 employees £10 million – £50 million typically 100–250 employees £50 million – £250 million typically 250–500 employees Step 2 of 3 What sector best describes your organisation? Legal services Financial services Healthcare-adjacent Other regulated sector Step 3 of 3 Do you serve customers in the EU, or process EU personal data? Yes No / Unsure Your estimated maximum regulatory exposure These figures represent statutory maximum penalties under UK GDPR (Article 83) and EU AI Act (Article 99). Actual enforcement decisions reflect the nature of the breach, evidence of governance measures in place, and regulatory discretion. Regulators have consistently cited the absence of documented technical controls as an aggravating factor. This tool does not constitute legal advice. CattleGrid Ltd · Company No. 17020793 · 32 Salisbury Avenue, Cheltenham GL51 3BS · cattlegrid.uk · hello@cattlegrid.uk Penalty figures based on UK GDPR as amended by the Data Protection Act 2018 and EU AI Act (Regulation (EU) 2024/1689). EU figures converted at approximately £0.85 / €1.00. Correct as at April 2026. ## Resources https://cattlegrid.uk/resources Resources Free governance tools for UK regulated organisations. Your staff are already using AI. The question is whether your governance framework has kept pace. These templates exist because, until now, nothing like them did. We built them ourselves and made them free to download. No registration. No form to complete. No sales call triggered. Whitepaper: AI Is Already in Your Business A practical briefing for CISOs, compliance officers, and senior leaders at UK regulated businesses Seventy-one percent of UK employees are using unapproved AI tools at work. More than half do so weekly. The question most organisations are now facing is not whether AI is present in their operations — it is whether they can see it, govern it, and stand behind it when a regulator or client asks. This whitepaper sets out the problem clearly, without vendor theatre. It covers what shadow AI actually looks like in legal, financial services, and healthcare-adjacent organisations; what the regulatory environment — UK GDPR, FCA Consumer Duty, SRA obligations, EU AI Act — actually requires; what the financial exposure looks like in pounds; and what a structured path from current exposure to a defensible position involves. It is written for the CISO or IT director who needs to understand the risk, the compliance officer who needs to map it to a regulatory framework, and the senior leader who needs to explain it to a board. The executive summary is available below. The full report — including sector-specific considerations for legal, financial services, and healthcare-adjacent organisations, the ISO certification pathway, and six questions worth putting to your leadership team — is included in the same download. DOWNLOAD AI Penalty Exposure Calculator Most organisations know AI governance penalties can be significant. Fewer know what that figure actually looks like against their own revenue. This tool takes your turnover band, sector, and EU exposure, and returns the statutory maximum penalties under UK GDPR and the EU AI Act — with a plain-English interpretation of what the figures mean for a firm like yours. Three questions. No registration required. Launch Calculator AI Risk and Regulatory Exposure in FCA-Regulated Firms For senior partners, managing directors, and compliance leads at FCA-regulated firms of 50–500 employees The FCA’s 2024 Multi-Firm AI Review did not identify a theoretical problem. It identified three specific failure patterns at regulated firms it had already reviewed: staff using unapproved AI tools without the firm’s knowledge, firms unable to produce audit evidence of AI interactions, and firms that had not assessed AI providers as technology dependencies. These are supervisory findings, not forward guidance. Firms that cannot demonstrate they have addressed them face follow-up action — including Section 166 skilled person reviews. This briefing maps the ten primary regulatory risks created by uncontrolled AI tool usage at FCA-regulated firms: client data leakage under UK GDPR, shadow AI exposure, absent audit trails, SMCR individual accountability, Consumer Duty data obligations, operational resilience gaps under PS21/3, SYSC 8 third-party due diligence, US CLOUD Act data sovereignty, DORA for EU-facing firms, and the financial promotions boundary under FSMA 2000. For each risk it sets out what CattleGrid mitigates at the AI API input layer and what the firm must address independently. A dedicated section maps the three FCA Multi-Firm Review findings directly to the documentary evidence CattleGrid generates. The point is a simple one: the FCA has told regulated firms what it expects to see. Deploying CattleGrid before a supervisory visit means you can produce that evidence. Deploying it after means you cannot. The briefing also includes a plain does/does not table. CattleGrid does not inspect AI outputs, draft governance policies, conduct DPIAs, assess the suitability of AI-generated financial advice, or determine what constitutes a serious incident under the EU AI Act. Those obligations remain with the firm. This document is designed to be read by a senior partner or MD alongside their compliance officer, and to support a decision about whether and how to deploy CattleGrid. DOWNLOAD Information Governance and AI: What CattleGrid Does — and Doesn't For information governance professionals at UK regulated organisations of 50–500 employees Every time a member of staff pastes client data into an AI tool, something happens at the data layer that your governance framework almost certainly hasn’t caught up with. The AI provider becomes a data processor under UK GDPR. The prompt may contain personal data with no lawful basis for transfer. The interaction leaves no audit trail. And if your organisation is FCA-regulated, SRA-regulated, or subject to ISO 27001, there are specific obligations attached to each of those facts. CattleGrid operates at the AI API layer — between your staff and the AI provider — intercepting outbound prompts in real time, applying your configured data governance rules, and generating an immutable audit record of every interaction. This reference document maps what that means in practice across the compliance frameworks most relevant to information governance professionals: UK GDPR, FCA requirements, SRA obligations, ISO 27001:2022, the EU AI Act, and the US CLOUD Act. The mapping uses a three-level classification: Direct (CattleGrid addresses the obligation), Partial (CattleGrid addresses part of it, and names what remains), and Supporting (CattleGrid provides the evidence infrastructure the obligation requires). The document also lists, plainly, the obligations CattleGrid does not address — DPIAs, RoPA, privacy notices, AI governance policy drafting, and others. Knowing the scope of any technical control is as important as knowing its capabilities. This document is designed to be read before an onboarding conversation, shared with a DPO or compliance officer reviewing a CattleGrid deployment, or used as a reference when mapping AI governance obligations across your organisation. DOWNLOAD Shadow AI Risk Assessment For FCA-regulated UK firms of 50–500 employees Shadow AI is already in your firm. The IBM data suggests 71% of UK employees are using unapproved AI tools, more than half of them weekly. The question for an FCA-regulated firm is not whether this is happening but what the regulatory consequences are and what you are doing about them. This template provides a structured eight-section assessment covering discovery methodology, a tool inventory, per-tool risk ratings across data leakage, regulatory breach and operational resilience dimensions, and a regulatory exposure map that works through Consumer Duty outcomes, SMCR individual accountability, PS21/3 operational resilience obligations, SYSC 8 outsourcing implications, financial promotions risk, and UK GDPR simultaneously. It includes a prioritised remediation table and a governance gap analysis referencing the FCA’s own multi-firm AI review findings. The FCA has confirmed it will rely on existing frameworks — Consumer Duty, SMCR, SYSC — to govern AI use in financial services rather than introducing AI-specific regulation. That makes understanding how those frameworks apply to shadow AI usage a compliance obligation, not a forward-looking aspiration. This template maps the exposure and gives you the evidence trail. DOWNLOAD DPIA Template for AI Tools For UK organisations of 50–500 employees in regulated sectors Every time an employee submits client data to ChatGPT, Claude, or any other public AI service, that AI provider becomes a data processor under UK GDPR. Your organisation remains the data controller. The legal obligation to conduct a Data Protection Impact Assessment before high-risk processing begins does not disappear because the tool is consumer-facing and the employee used it without thinking. This template is structured around UK GDPR Article 35 and ICO DPIA guidance. It covers necessity and proportionality assessment, data flows and international transfer mechanisms, a pre-populated risk register with likelihood and severity ratings, risk mitigation measures, consultation and sign-off, and a review schedule. Warning boxes flag the specific errors we see most frequently in practice: incorrect Article 9 conditions, IDTA being applied to EEA transfers that do not require it, the Microsoft Copilot controller-status question, and the DPO mandatory appointment threshold. It is designed to be completed once per AI tool or major use case and attached to your Records of Processing Activities. DOWNLOAD ### How to use these resources The whitepaper is written to be read. The two templates are starting points, not finished compliance products. They are designed to be adapted to your organisation’s specific circumstances, tools, regulatory permissions, and data processing activities. Generic entries should be replaced with accurate descriptions of your actual position. The guidance notes throughout each section explain what the assessor should consider; they are not themselves the answer. Where a template flags that legal advice should be sought — on Article 9 special category conditions, on SYSC 8 outsourcing conclusions, on the appropriate SMCR accountability allocation for your firm — that flag is genuine. These are questions with answers that depend on your specific facts and should not be resolved by reference to an example entry in a template. All three documents reference the ICO’s AI and data protection guidance, FCA policy statements, SRA guidance, and relevant UK GDPR provisions with hyperlinks to primary sources. Those links are current as of the date of publication. Regulatory guidance evolves; check the linked sources for the most recent versions before relying on any specific reference. ### Terms of Use These resources are provided by CattleGrid Ltd free of charge for UK regulated organisations. The whitepaper is provided for information only. The templates do not constitute legal, regulatory, or compliance advice. CattleGrid Ltd makes no warranty, express or implied, as to the accuracy, completeness, or fitness for purpose of these documents for any particular organisation’s circumstances. Use of these resources does not create a client relationship with CattleGrid Ltd and does not discharge any legal or regulatory obligation. Organisations should seek independent legal and regulatory advice on their specific compliance position before relying on any assessment or document produced using these templates. CattleGrid Ltd accepts no liability for any loss or damage arising from reliance on these documents. CattleGrid Ltd. Company No. 17020793. 32 Salisbury Avenue, Cheltenham GL51 3BS. ## FAQ's https://cattlegrid.uk/frequently-asked-questions Frequently Asked Questions ### What is CattleGrid? An AI security gateway. It sits between your systems and your AI providers, inspecting every outbound request in real time and blocking sensitive data before it leaves your organisation. ### What problem does CattleGrid solve that traditional DLP or firewalls don't? Traditional controls handle email and file transfers but weren't designed for AI API calls. CattleGrid addresses this specific vulnerability where existing safeguards have blind spots. ### Does CattleGrid learn from my prompts? No. Prompts are inspected in memory, your rules are applied, and the content is discarded. Nothing is used for model training. Nothing is written to disc. Conversation history is a separate feature your organisation chooses to switch on — and where it is on, that content is never used for training either. ### What information does CattleGrid store? Audit metadata always: who made a request, when, which rules fired, and what action was taken — not the prompt content itself. Conversation content is stored only where your organisation has switched on conversation history or compliance review, under a retention policy you set. ### Where is data held? CattleGrid's own infrastructure runs on Civo UK, in London — our always-live production environment — with a Frankfurt site for resilience. Frankfurt does double duty: it keeps us resilient, and for organisations that need their data resident in the EU rather than the UK, it can be the primary home instead. Tell us which you need and we'll scope it with you. But the more important answer is what CattleGrid does: it stops your PII and sensitive data leaving the UK/EU in the first place. When a request routes through OpenAI or another provider, CattleGrid inspects it before it leaves your organisation and blocks or redacts anything your policies flag, so that data doesn't reach a non-UK/EU jurisdiction unless you've decided it should. ### Do you inspect files and documents I upload to AI tools, not just text prompts? Yes. File uploads to AI tools — PDF, Word, Excel, OpenDocument Text, and RTF — are extracted, inspected against your rules, and discarded, using the same block, redact and audit approach as prompt inspection. It's included in every tier with a monthly allowance, and additional usage credit can be purchased at any time. ### Does CattleGrid mask or tokenise sensitive data instead of just blocking it? Yes. Matched identifiers can be reversibly tokenised rather than blocked outright: the AI provider only ever sees a token, and CattleGrid restores the real value in the reply before it reaches you. This happens in memory, per request, with no persistent key and nothing retained afterwards. Anonymise / De-anonymise packs cover UK PII, Financial, API Keys & Secrets and Salesforce, and A/D is available in every tier with a monthly allowance. ### Can I deploy CattleGrid within my own infrastructure? Yes, on the Custom tier. On-premises deployment sits inside your own network and is scoped with us first, against what you actually need — it isn't an off-the-shelf option. Contact us to discuss your requirements. ### Can I create custom detection rules for my organisation? Yes. Built-in detectors cover standard PII and financial data. Custom rules let you define your own: client identifiers, deal codes, sector-specific data patterns. ### Will CattleGrid affect performance? Barely. We target under 8 ms of added overhead on inspection, subject to your AI provider's own response time. Staff carry on working normally. The only difference is that requests containing sensitive data are stopped before they leave. ### What happens when a request is blocked? The employee receives a clear explanation of what was detected and why. Administrators see the event in real time. A full audit log is maintained. ### What does CattleGrid cost? Four tiers: Launch is free, API starts from £50 a month, Custom Packs from £250 a month, and Custom is priced on application. There is no per-seat licence — pricing is based on volume: the requests and data you put through the gateway, your A/D usage, and the rule packs you run. Every tier includes an allowance and additional usage credit can be purchased at any time. See the pricing page for detail, or contact us to discuss your organisation. ### Where can I get support? Support and guidance are built into the product: the in-app compliance chat gives real-time answers as you configure rules and policies. Beyond that, you have direct access to the team who built CattleGrid — no ticketing system between you and us. Early Access Programme participants also get priority onboarding support. ### How do I stop using CattleGrid? Revert your API configuration to point directly at your AI provider. CattleGrid holds no data on your behalf. There is no lock-in. ### Is CattleGrid designed for business use? Yes. It is built for organisations that need governance controls, policy enforcement, and audit trails. Individual personal subscriptions are outside its scope. ### I use AI tools on my phone. Does CattleGrid cover that? CattleGrid protects traffic routed through your organisation's API setup. Personal mobile apps connecting directly to public AI services fall outside the managed perimeter. ### Does CattleGrid work with Microsoft Copilot? Not currently, since Copilot operates through Microsoft's own administrative controls rather than external API endpoints that CattleGrid can intercept. ### How do I know CattleGrid is a serious product? The founding team has backgrounds in enterprise technology and healthcare data governance. Architecture is designed against ISO 27001, ISO 42001, and EU AI Act requirements. ### Your infrastructure is all European. Does that mean you are anti-American? Not at all. It isn't about hostility to anyone — it's that European organisations carry obligations that are simply easier to meet when data stays inside European law. Running on UK and EU infrastructure means one legal framework, and no extraterritorial regime reaching through the governance layer. We connect happily to American AI providers; we just make sure you control what reaches them. ### Is CattleGrid only for large enterprises? No. It is built for regulated UK and EU organisations in the 50 to 500 employee range — where serious AI governance is required but enterprise platforms are neither affordable nor appropriate. ### Which AI services does CattleGrid work with? OpenAI, Anthropic, Google Gemini, and Mistral — plus any provider reachable through a standard, OpenAI-compatible API. If your organisation uses an API-routed AI service, CattleGrid can protect that traffic. ### Will CattleGrid stop my staff from using AI? No — the opposite. Most organisations that ban AI outright find staff use it anyway, on personal accounts, where nobody can see it. CattleGrid lets you say yes, with the sensitive material handled before it ever leaves. Staff keep the tools and the productivity; you keep the visibility. ### How does CattleGrid support GDPR and EU AI Act compliance? It blocks, redacts, or tokenises sensitive data before it reaches external AI services, and generates the audit trails required by UK GDPR, ISO 42001, and EU AI Act documentation standards. ### Is CattleGrid a replacement for full AI governance or ISO certification? No. ISO 27001 and ISO 42001 certification requires executive commitment and time. CattleGrid is the tactical control that limits your exposure whilst that strategic work proceeds. ### Is there a desktop app? Yes, and it's included in every tier. It gives you AI chat with your organisation's rules applied, team chat and direct messages, shared projects, and voice dictation — all routed through the same inspection path. It's optional: the API and MCP Hub routes need no install at all, just a key and a provider configured on the CattleGrid platform. ### Can we switch features on and off? Yes. Features are enabled per account to suit how you work. Anything you haven't switched on isn't running — which matters for things like conversation history, compliance review and encryption mode, where the right answer differs from one organisation to the next. ### Do you support MCP tools and AI agents? Yes, through the MCP Hub. Tools are registered per tenant with role-based access, and unapproved tools can't be invoked at all. Tool calls and responses are inspected, and each carries a verdict — pass, warn, sanitise or block — before anything reaches the model. Where a tool chain accumulates risk across several steps, that's caught too. ### Do you charge per user? No. Pricing is volume-based: requests, throughput, A/D usage and the rule packs you run. SSO, audit, rule management and the rest of the controls that secure your environment don't cost more as you add people, so protecting your whole organisation never means using AI less. ### Do you redact people's names? Not by guessing — and that is a deliberate design decision rather than a gap. Structured identifiers work because they have a shape. A National Insurance number, a sort code, an NHS number or a card number follows a defined format, so detection is deterministic and close to exhaustive. Names have no shape. They are unbounded across languages and transliterations, there is no closed list to check against, and an enormous number of them collide with ordinary English words — Mark, Bill, Rose, Frank, Grace, May, Brown, Baker, Hunt, Church. Whether "Chase" is a bank, a surname or a verb depends entirely on the sentence around it. That leaves two failure modes, and both are worse than the problem. Redact every capitalised word and the prompt becomes meaningless — the model cannot answer a question you have scrubbed of its subject, so staff stop using the tool or start working around it. Redact selectively and you produce false assurance, which is more dangerous than no redaction at all, because people then trust a control that does not hold. There is also a substantive point about what actually identifies someone. A name on its own is rarely the exposure. The risk lies in linkage — a name beside an account number, a medical condition, a matter reference or a salary. CattleGrid breaks the linkage: the identifiers that make a record traceable to a real person are tokenised or removed, and what reaches the provider is a fragment that cannot be tied back. That is the control that changes your risk position. Where names genuinely matter to you, they are handled by definition rather than inference. Client lists, employee names, matter references, internal project names and customer identifiers can be added as keyword rules or authored into your own rule pack, where detection is exact because you supplied the list. We would rather you relied on a list you control than on a model's inference for something this consequential. This is also what the law expects. UK GDPR Article 32(1) requires the controller and processor to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk — taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons. Appropriate to the risk, and taking into account the state of the art. The standard is proportionate and achievable, not absolute, and pseudonymisation is named in that same Article as an example of such a measure. A vendor promising perfect name redaction is promising something the state of the art does not currently deliver. ## Our Voice https://cattlegrid.uk/our-voice ## Why CattleGrid? https://cattlegrid.uk/why-cattlegrid Why CattleGrid? Prevent sensitive data leakage and stay compliant. Why choose CattleGrid Your people want to use these tools, and they should — the gains are real. CattleGrid exists so that adopting AI properly doesn't have to mean adopting the risk that usually comes with it. It inspects the content of every outbound request against your configured inspection rules, matching regex patterns (UK National Insurance numbers, credit card numbers, postcodes) or keyword blocklists (internal project names, customer identifiers). See [**everything the platform does**](undefined), or how [**Anonymise**](undefined) keeps data usable without exposing it. ### What CattleGrid Does CattleGrid sits between your applications and AI providers. Every AI API request passes through it. Before anything reaches Anthropic, OpenAI, Mistral, or Google, CattleGrid inspects the content, enforces your rules, and either blocks the request, redacts the sensitive data, or lets it through – logged and audited. It retains none of your data. Inspect, redact, block, discard. That is the complete sequence. See [**how it works technically**](undefined). ### What it never does Streaming responses are piped straight back to your application with zero buffering and zero modification — the gateway does not sit in the way of what the AI generates. Request content is never stored on that path: it exists only during processing and is discarded when the request completes. There is no database of your prompts and no log of what your staff typed. Where you switch on conversation history, persistent memory or compliance review, that is your decision, your retention policy, and visible to you as such. The only records retained are: usage metadata ( counts, latencies, status codes), violation summaries (rule triggered and action taken – not the content that triggered it), and configuration audit events. On the gateway path this is not a policy position. It is an architectural constraint enforced at every layer. What CattleGrid does for the person responsible for AI governance in a regulated SME. MD / Senior Partner / CEO What's the financial exposure if something goes wrong, and what does the board need to know? Your people are already using AI. The only open question is whether anyone is governing it. 71% of UK employees are using AI tools their employer hasn't approved, and 51% do so weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025). That is not a future risk on a roadmap. It is a present condition inside your organisation, uncosted on any risk register you've likely seen. £498,000. That is what the IBM Cost of Data Breach Report 2025 says a breach costs on top of the baseline when shadow AI is involved — on top of an average UK breach cost already at £3.29 million. Governing this doesn't mean banning it. It means being able to back your people using the best tools available, and still sleep well — putting a control in place before the exposure crystallises rather than after. DPO / Compliance Officer Does your current AI usage create a data processor relationship you haven't documented? Every time someone in your organisation pastes client or employee data into a public AI tool, that data reaches a third-party processor — whether or not anyone wrote that relationship down. 71% of UK employees are already using AI tools their employer hasn't approved, and 51% do so weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025). 83% of UK organisations have no controls in place over what leaves through them (BlackFog/Sapio Research, November 2025). If your RoPA and DPIAs were written before that usage started, they don't describe what's actually happening today — and an ICO enquiry or a client's own due-diligence questionnaire will ask you to reconcile the two. CattleGrid's audit trail is cryptographically verifiable — tamper-evident by design, not by policy. It records what left, what was blocked or redacted, and when, automatically and continuously. You wrote the policy. This is what makes it enforceable everywhere, not just where people remember to follow it. CIO / IT Manager What does this actually involve to set up, and how do you explain it upstairs? Every AI governance project reaches an IT manager who has to answer both questions credibly, on the same afternoon. 71% of UK employees are already using AI tools their employer hasn't sanctioned, and 51% do so weekly, according to a Microsoft-commissioned survey of over 2,000 UK employees (Censuswide, October 2025). Separately, 83% of UK organisations have no controls in place over what leaves through those tools (BlackFog/Sapio Research, November 2025). None of that shows up in a board pack until something goes wrong — and when it does, the question of who was supposed to have visibility lands on IT. CattleGrid's rule layer runs in-process with no external calls, targeting under 8 ms of added overhead. Governance doesn't become the reason things get slower, which is usually the first objection you'll need an answer for. Deployment is a URL change. Nothing else in your application stack moves. CISO / Head of InfoSec Does your current AI usage create a data processor relationship you haven't documented? Every time someone in your organisation pastes client or employee data into a public AI tool, that data reaches a third-party processor — whether or not anyone wrote that relationship down. 71% of UK employees are already using AI tools their employer hasn't approved, and 51% do so weekly (Microsoft/Censuswide UK Shadow AI Survey, October 2025). 83% of UK organisations have no controls in place over what leaves through them (BlackFog/Sapio Research, November 2025). If your RoPA and DPIAs were written before that usage started, they don't describe what's actually happening today — and an ICO enquiry or a client's own due-diligence questionnaire will ask you to reconcile the two. CattleGrid's audit trail is cryptographically verifiable — tamper-evident by design, not by policy. It records what left, what was blocked or redacted, and when, automatically and continuously. You wrote the policy. This is what makes it enforceable everywhere, not just where people remember to follow it. Departmental Lead (IFA / Practice Manager / Head of Legal) Your regulator already has a view on this. Do you have the specific control that answers to it? This isn't a generic AI governance question. It's the question your regulator has already started asking, in language specific to your sector. If you're in legal services, the SRA's Codes of Conduct engage duty of competence, client confidentiality, and — for COLPs — firm-level supervision the moment AI tools touch client work, and the SRA has issued its own guidance and warning notices on generative AI use. If you're in financial services, the FCA's position is explicit: AI governance sits within existing obligations under Consumer Duty, SMCR, and SYSC 8, not a future framework still to be written (FCA AI Update, April 2024). 75% of FCA-regulated firms are already using AI (Bank of England/FCA AI Survey, 2024). Neither regulator is waiting for a formal AI-specific rulebook before asking the question. Both are asking it now, inside the rules they already enforce. CattleGrid maps its controls to the specific obligation your sector's regulator names — not a generic compliance checklist. Why did CattleGrid block my prompt? You typed something into CattleGrid, picked a model from the dropdown (Claude, GPT, Gemini, whichever your organisation has enabled), and instead of the answer you expected, part of your message came back highlighted, replaced with a label like \`[REDACTED: UK National Insurance Number]\`. Or the whole thing didn't go through: a notice card told you the request was blocked, with a reference number. Your first thought was probably not "how interesting, a data governance control." It was probably "am I in trouble" or "is someone watching what I type." Neither. Here's the short version. Every message you send in CattleGrid is checked against your organisation's rules before it's forwarded to the AI provider you selected: OpenAI, Anthropic, Google Gemini, or Mistral. If it finds something sensitive, such as client data, National Insurance numbers, bank details, or credentials, it blocks the request, redacts the sensitive part, or lets it through with a warning. This happens in the same second you hit send. The check itself is automatic — no person sits between you and the answer. What your organisation keeps afterwards is its own decision: some enable conversation history or compliance review, some don't, and your admin can tell you which applies here. This isn't about not trusting you. It's the opposite — it's what lets your organisation hand you these tools in the first place, rather than blocking them outright like a lot of firms have. It's about not trusting the moment: the one where everyone is moving fast and a client's details end up somewhere they shouldn't. It happens to careful people constantly. What actually happens behind that badge or notice card, and what it means for you day to day, is on the next page. # Posts ## EU AI Act Omnibus Agreement https://cattlegrid.uk/posts/eu-ai-act-omnibus-agreement ### What happened on 7 May 2026 The European Council and European Parliament reached provisional political agreement on the Digital Omnibus on AI — a legislative package designed to simplify and streamline how the EU AI Act is implemented. This is a real and material change to the timeline. It is not a rewrite of the Act’s core architecture. The risk-based framework — prohibited practices, high-risk systems, transparency obligations, governance requirements — remains entirely intact. The Omnibus requires formal adoption and publication in the Official Journal before it becomes binding law. On the basis of political agreement between both co-legislators, it represents the operative planning baseline for compliance teams from today. ### The key changes The table below summarises what changed, what did not, and what each change means in practice for UK regulated organisations. ## You Don’t Have a Compliance Team. Here’s What That Means When Your Staff Use AI. https://cattlegrid.uk/posts/you-dont-have-a-compliance-team-heres-what-that-means-when-your-staff-use-ai In enterprise technology there was a challenge with what was called “skunk works”. There’s the software companies use and buy, and then there’s the stuff people make and create to do their work Bits of orphan code that glue workflows together. Workaround installed years ago. Some with a corporate memory. Most without documentation . My First customer services team at Microsoft used a CRM the team built on Access and Crystal Reports. Ran the whole department for a couple of years. I came across a consultant once in a large teaching hospital, who proudly showed me the macro-ridden spreadsheet that ran his small department and the server he ran it on under his desk. Oblivious to IT. He was the designer, developer, primary user and support agent. The pattern is the same here . Staff using AI tools ChatGPT, Claude, Gemini, whatever had arrived in their feed that week to get work done faster. Drafting client emails. Summarising documents. Writing reports.. Nothing unusual about any of it. Entirely reasonable use of tools that genuinely save time. ### What actually happens when someone pastes client data into ChatGPT The moment your employee submits a prompt containing a client name, a financial figure, a medical detail, or any other personal information to a public AI service, that AI provider becomes a data processor under UK GDPR. Your business remains the data controller. The legal obligations that follow from that apply whether you knew it happened or not. You’ll be needing an audit record of the interaction and a lawful basis for the transfer onfile as well as that Data processing agreement for when , inevitably someone challenges you. The AI providers certainly don’t flag it on the way in, or if they do its in the really small print we never read. The ICO has been clear that UK GDPR applies to AI tool usage. It does not make an exception for consumer-facing tools, for accidental usage, or for businesses below a certain size. If personal data was processed, the rules applied. You can as I’ve seen, see people roll their eyes and mutter darkly about red tape or stifling innovation, and perhaps they’ve got a point. However until someone changes the playing field, lets focus on what we can actually do about it today. ### Three things you almost certainly aren’t doing Firstly – what aren’t you doing? One. You probably don’t have a data processing agreement with OpenAI, Google, or Anthropic. Not a properly executed one that covers the specific use case of your employees submitting client data. The terms of service are not that agreement. Two. You almost certainly have no audit trail. You cannot say, with evidence, which employees used which AI tools, when, and what data was submitted. If the ICO or a client ever asked, you would be answering from memory. Three, and in my mind the most important: You have no policy that employees have read, understood, and acknowledged. An AI acceptable use policy that lives in a shared drive nobody opens is not a policy. It is a document. None of these things require a compliance team to fix,they just require a decision to take them seriously. ### What’s the risk for me, Brian ? UK GDPR penalties can reach £17.5 million or 4% of annual global turnover, whichever is higher. For a small business, the more realistic exposure is an ICO investigation, a requirement to demonstrate what happened, and a finding that you had inadequate technical and organisational measures in place. That finding has consequences beyond the fine. Clients in regulated sectors will ask about it. That has a knock on effect. Liability profiles change, and premiums go up The less visible risk is the client whose data ended up in a prompt. You may never know. They almost certainly won’t either. “They’ll never know” is a terrible look . That’s not how we would want to treat our valued customers. It’s certainly not how we would want to be treated. ### What good looks like for a business your size You do not need a compliance exercise. No Consultancies need be engaged. No fees for advice here. ### You need three things. A written policy that employees are required to read and acknowledge. One page is fine. It should say which AI tools are permitted, what categories of data must not be submitted, and what the consequences of non-compliance are. You can pull that together right now. A processor agreement with the AI providers your staff use. OpenAI and Google both offer these. They take twenty minutes to execute. Most businesses haven’t done it. A technical control that gives you visibility. This is where CattleGrid comes in We built a gateway that sits between your staff and the AI provider, inspects prompts in real time against your configured rules, and generates an audit record of every interaction. Nothing is stored. Nothing leaves the UK and EU infrastructure. Nobody stops you using your AI provider, You don’t get to feel you’re playing catch up, and it does not require a compliance team to operate. The point is not that you must use CattleGrid. The point is that a technical measure of some kind is what turns a policy document into a defensible position. ### The question worth asking this week Do you know which AI tools your staff are using right now? Not which ones you’ve sanctioned. Which ones they’re actually using. If the answer is no, that is where to start. CattleGrid is an AI API security gateway built for UK and EU organisations. The Early Access Programme is open now at cattlegrid.uk. ## WHOSE FLAG PROTECTS YOU? https://cattlegrid.uk/posts/whose-flag-protects-you ### **A Series of 9 Posts** Prepared 05-03-2026 **Contents** 1. Two Flags, One Problem — Why Neither Superpower Is Safe for European Data 2. The Warrant vs The Obligation — How Each Government Reaches Your Data 3. FISA Section 702 — The Surveillance Programme That Europe Cannot Ignore 4. China’s Seven Laws — The Cage That No Contract Can Open 5. The Adequacy Illusion — Why the Data Privacy Framework Doesn’t Solve the Problem 6. The Uncomfortable Similarities — What the US and China Actually Have in Common 7. Encryption — The One Technical Measure That Might Change the Equation 8. Then Canada Blew It All Up — The OVH Case and the Death of Data Residency 9. Whose Flag Protects You? — None of Them ### Post 1: Two Flags, One Problem — Why Neither Superpower Is Safe for European Data When European businesses evaluate AI providers, the conversation usually goes like this: “We can’t use Chinese providers, too risky. Let’s go with an American one.” That instinct is understandable. But it skips a critical question: is the American alternative actually safe for European data? Or is it just less obviously dangerous? Over the next 8 posts, I’m going to compare US and Chinese data access laws side by side. I’ll be honest about the differences, they are real and they matter. China’s system is more opaque, more coercive, and more sweeping than the American equivalent. They are not the same. But here’s the uncomfortable conclusion this series will reach: neither system is compatible with genuine European data sovereignty. The CLOUD Act gives the US government the legal authority to compel any US company to hand over European data, regardless of where that data is stored. No amount of contractual language, no Standard Contractual Clause, and no adequacy framework changes that underlying legal reality. The EU–US Data Privacy Framework is a political compromise, not a technical guarantee. It has already survived one predecessor’s invalidation by the CJEU. Privacy advocates expect it to face a third challenge. And even while it stands, it does not prevent CLOUD Act warrants from being served. The question for European businesses is not “US or China?” It’s “How do we protect our data regardless of whose flag flies over the provider?” This is post 1 of 9 in a series on why no foreign legal framework is compatible with genuine European data protection. #datasecurity #compliance #GDPR #dataprivacy #CLOUDACT #datasovereignty #riskmanagement **References:** European Commission, EU–US Data Privacy Framework Adequacy Decision (10 July 2023) [https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers\_en](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en) CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) US Department of Justice, CLOUD Act Resources [https://www.justice.gov/criminal/cloud-act](https://www.justice.gov/criminal/cloud-act) **Verified References** 1. European Commission, EU–US Data Privacy Framework Adequacy Decision (10 July 2023) [https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers\_en](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en) 2. CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) 3. US Department of Justice, CLOUD Act Resources [https://www.justice.gov/criminal/cloud-act](https://www.justice.gov/criminal/cloud-act) ### Post 2: The Warrant vs The Obligation — How Each Government Reaches Your Data The mechanics of government data access differ significantly between the US and China. Understanding the difference matters — not because one is acceptable, but because the risks require different mitigation strategies. In the United States, the CLOUD Act requires a warrant issued by an independent federal judge, based on probable cause that a specific crime has occurred and that the data contains evidence of it. The warrant must describe with particularity what is to be searched. The target company can challenge it by filing a motion to quash. Companies including Microsoft have done exactly this. In China, there is no equivalent process. Article 7 of the National Intelligence Law requires “all organisations and citizens” to cooperate with intelligence work. No warrant. No judge. No probable cause. No mechanism to challenge. And the Supreme People’s Court has explicitly rejected judicial independence as a Western concept. So the US system is better? In process, yes. Meaningfully. But here is the part that matters for European businesses: the CLOUD Act warrant can compel a US company to produce data stored in London, Frankfurt, or Dublin. The warrant is served on the company, not on a European court. No European judge reviews it. No European regulator is notified. Your data leaves European jurisdiction through a legal mechanism you have no visibility into and no power to contest. Better process does not mean safe process. It means the risk is more structured, more predictable, and more amenable to mitigation — but it is still there. This is post 2 of 9. #datasecurity #CLOUDACT #compliance #GDPR #china #dataprivacy #datasovereignty **References:** BSA, “What Is the CLOUD Act?” (August 2025) [https://www.bsa.org/files/policy-filings/08192025bsacloudact.pdf](https://www.bsa.org/files/policy-filings/08192025bsacloudact.pdf) Cross-Border Data Forum, “Frequently Asked Questions about the US CLOUD Act” Congressional Research Service, “Cross-Border Data Sharing Under the CLOUD Act” [https://www.congress.gov/crs-product/R45173](https://www.congress.gov/crs-product/R45173) Mannheimer Swartling, “Applicability of Chinese National Intelligence Law” (2019) [Applicability of Chinese National Intelligence Law to Chinese and non-Chinese Entities](https://www.mannheimerswartling.se/en/insights/applicability-of-chinese-national-intelligence-law-to-chinese-and-non-chinese-entities/) **Verified References** 1. BSA, “What Is the CLOUD Act?” (August 2025) [https://www.bsa.org/files/policy-filings/08192025bsacloudact.pdf](https://www.bsa.org/files/policy-filings/08192025bsacloudact.pdf) 2. Cross-Border Data Forum, “Frequently Asked Questions about the US CLOUD Act” 3. Congressional Research Service, “Cross-Border Data Sharing Under the CLOUD Act” [https://www.congress.gov/crs-product/R45173](https://www.congress.gov/crs-product/R45173) 4. Mannheimer Swartling, “Applicability of Chinese National Intelligence Law” (2019) [Applicability of Chinese National Intelligence Law to Chinese and non-Chinese Entities](https://www.mannheimerswartling.se/en/insights/applicability-of-chinese-national-intelligence-law-to-chinese-and-non-chinese-entities/) ### Post 3: FISA Section 702 — The Surveillance Programme That Europe Cannot Ignore The CLOUD Act is not the only US law that should concern European businesses. FISA Section 702 is arguably the bigger problem. Section 702 of the Foreign Intelligence Surveillance Act authorises US intelligence agencies to conduct warrantless surveillance of non-US persons located outside the United States. Read that again: non-US persons. That means European citizens. Their communications can be collected, stored, and queried without any individual warrant. The programme operates under annual certification by the Foreign Intelligence Surveillance Court, but individual targets do not require judicial approval. When the NSA collects under Section 702, communications involving US persons are incidentally captured too. Until the 2024 reforms, agencies could query this database using US person identifiers without a warrant. An amendment to require warrants failed in the House by a tied 212–212 vote. Section 702 was reauthorised in April 2024 for just two years. It sunsets again in April 2026. The debate is ongoing and public, which is more than can be said for China’s equivalent capabilities. But the programme’s existence is precisely why the CJEU struck down two successive EU–US data transfer frameworks: Safe Harbor in 2015 and Privacy Shield in 2020. Executive Order 14086 was designed to patch the gap. It introduced proportionality requirements and a redress mechanism. But it is an executive order — not legislation. A future president can revoke it. And European data collected under Section 702 is still collected under Section 702, regardless of what any executive order says about safeguards. This is post 3 of 9. #FISA #datasecurity #surveillance #privacy #GDPR #dataprivacy #datasovereignty **References:** Congressional Research Service, “FISA Section 702 and the 2024 Reforming Intelligence and Securing America Act” [https://www.congress.gov/crs-product/R48592](https://www.congress.gov/crs-product/R48592) EPIC, “FISA Section 702: Reform or Sunset” [https://epic.org/campaigns/fisa-section-702-reform-or-sunset](https://epic.org/campaigns/fisa-section-702-reform-or-sunset) European Parliament, “First reactions to Executive Order 14086” [https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS\_BRI(2022)739261\_EN.pdf](https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS_BRI(2022)739261_EN.pdf) US Department of Justice, Office of Privacy and Civil Liberties — Executive Order 14086 [https://www.justice.gov/opcl/executive-order-14086](https://www.justice.gov/opcl/executive-order-14086) **Verified References** 1. Congressional Research Service, “FISA Section 702 and the 2024 Reforming Intelligence and Securing America Act” [https://www.congress.gov/crs-product/R48592](https://www.congress.gov/crs-product/R48592) 2. EPIC, “FISA Section 702: Reform or Sunset” [https://epic.org/campaigns/fisa-section-702-reform-or-sunset](https://epic.org/campaigns/fisa-section-702-reform-or-sunset) 3. European Parliament, “First reactions to Executive Order 14086” [https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS\_BRI(2022)739261\_EN.pdf](https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS_BRI(2022)739261_EN.pdf) 4. US Department of Justice, Office of Privacy and Civil Liberties — Executive Order 14086 [https://www.justice.gov/opcl/executive-order-14086](https://www.justice.gov/opcl/executive-order-14086) ### Post 4: China’s Seven Laws — The Cage That No Contract Can Open If the US system is a structured risk, China’s is an unmanageable one. Since 2014, China has enacted at least seven major laws that collectively give the government sweeping authority to access any data held by any Chinese company. The National Intelligence Law (2017) creates a blanket cooperation obligation. The Cybersecurity Law (2017) mandates data localisation and technical assistance. The Cryptography Law (2020) gives the state access to commercial encryption keys. The Data Security Law (2021) imposes government security reviews. The Counter-Espionage Law (2014) compels cooperation with investigations. The Personal Information Protection Law (2021) regulates companies — but exempts the government. Three features make this system categorically different from anything in Western law. First: personal obligations. Article 7 binds individual citizens, not just companies. Every Chinese engineer working at any Chinese company is personally bound by this law, wherever they are. Second: mandatory secrecy. A Chinese company served with a request under the NIL cannot tell you. Cannot tell its board. Cannot tell its European customers. The DHS Data Security Business Advisory confirmed that Chinese firms are “required to secretly share data.” Third: undefined scope. China’s NIL covers “intelligence work” — deliberately undefined. It can encompass economic intelligence, trade secrets, and strategic competitive information. There is no limiting principle. The US system has genuine problems. China’s system is those problems without any of the constraints. This is post 4 of 9. #datasecurity #china #compliance #dataprivacy #encryption #cybersecurity #riskmanagement **References:** US Department of Homeland Security, “Data Security Business Advisory” (22 December 2020) [https://www.dhs.gov/sites/default/files/publications/20\_1222\_data-security-business-advisory.pdf](https://www.dhs.gov/sites/default/files/publications/20_1222_data-security-business-advisory.pdf) Lawfare, Tanner, “Beijing’s New National Intelligence Law: From Defense to Offense” (2017) [https://www.lawfaremedia.org/article/beijings-new-national-intelligence-law-defense-offense](https://www.lawfaremedia.org/article/beijings-new-national-intelligence-law-defense-offense) Skadden, “China’s New Data Security and Personal Information Protection Laws” (November 2021) [https://www.skadden.com/insights/publications/2021/11/chinas-new-data-security-and-personal-information-protection-laws](https://www.skadden.com/insights/publications/2021/11/chinas-new-data-security-and-personal-information-protection-laws) China Law Translate, National Intelligence Law full text [https://www.chinalawtranslate.com/en/national-intelligence-law-of-the-p-r-c-2017](https://www.chinalawtranslate.com/en/national-intelligence-law-of-the-p-r-c-2017) **Verified References** 1. US Department of Homeland Security, “Data Security Business Advisory” (22 December 2020) [https://www.dhs.gov/sites/default/files/publications/20\_1222\_data-security-business-advisory.pdf](https://www.dhs.gov/sites/default/files/publications/20_1222_data-security-business-advisory.pdf) 2. Lawfare, Tanner, “Beijing’s New National Intelligence Law: From Defense to Offense” (2017) [https://www.lawfaremedia.org/article/beijings-new-national-intelligence-law-defense-offense](https://www.lawfaremedia.org/article/beijings-new-national-intelligence-law-defense-offense) 3. Skadden, “China’s New Data Security and Personal Information Protection Laws” (November 2021) [https://www.skadden.com/insights/publications/2021/11/chinas-new-data-security-and-personal-information-protection-laws](https://www.skadden.com/insights/publications/2021/11/chinas-new-data-security-and-personal-information-protection-laws) 4. China Law Translate, National Intelligence Law full text [https://www.chinalawtranslate.com/en/national-intelligence-law-of-the-p-r-c-2017](https://www.chinalawtranslate.com/en/national-intelligence-law-of-the-p-r-c-2017) ### Post 5: The Adequacy Illusion — Why the Data Privacy Framework Doesn’t Solve the Problem In July 2023, the European Commission granted the US an adequacy decision under the EU–US Data Privacy Framework. The UK followed with a data bridge. Many businesses treated this as the green light: problem solved, transfers to US companies are fine now. It is not that simple. The DPF is the third attempt at an EU–US data transfer framework. Safe Harbor was struck down by the CJEU in 2015. Privacy Shield was struck down in 2020. Both were invalidated because the Court found that US surveillance law, specifically FISA Section 702, did not provide protections “essentially equivalent” to EU law. The DPF rests on Executive Order 14086, which introduced proportionality requirements and a Data Protection Review Court. But EO 14086 is an executive order, not an Act of Congress. It can be revoked or amended by any sitting president without congressional approval. Privacy campaigner Max Schrems has already indicated he intends to challenge the framework, and the European Parliament passed a resolution expressing concern that it may not survive judicial scrutiny. And here is the fundamental issue the DPF does not resolve: the CLOUD Act. Even under the DPF, a US company served with a CLOUD Act warrant must comply. The warrant overrides any contractual arrangement with a European customer. CMS Law’s February 2026 analysis confirmed that European data residency is “not a silver bullet when it comes to avoiding the reach of the US CLOUD Act.” The DPF makes transfers lawful under GDPR. It does not make your data unreachable by US authorities. Those are very different things. This is post 5 of 9. #GDPR #dataprivacy #CLOUDACT #compliance #datasovereignty #dataprotection #datasecurity **References:** CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) European Parliament, “First reactions to Executive Order 14086” [https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS\_BRI(2022)739261\_EN.pdf](https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS_BRI(2022)739261_EN.pdf) Fieldfisher, “EO 14086 and the EU–US Data Privacy Framework” (November 2022) [https://www.fieldfisher.com/en/insights/eo-14086-and-the-eu-us-data-privacy-framework](https://www.fieldfisher.com/en/insights/eo-14086-and-the-eu-us-data-privacy-framework) European Commission, EU–US Data Privacy Framework [https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers\_en](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en) **Verified References** 1. CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) 2. European Parliament, “First reactions to Executive Order 14086” [https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS\_BRI(2022)739261\_EN.pdf](https://www.europarl.europa.eu/RegData/etudes/BRIE/2022/739261/EPRS_BRI(2022)739261_EN.pdf) 3. Fieldfisher, “EO 14086 and the EU–US Data Privacy Framework” (November 2022) [https://www.fieldfisher.com/en/insights/eo-14086-and-the-eu-us-data-privacy-framework](https://www.fieldfisher.com/en/insights/eo-14086-and-the-eu-us-data-privacy-framework) 4. European Commission, EU–US Data Privacy Framework [https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers\_en](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en) ### Post 6: The Uncomfortable Similarities — What the US and China Actually Have in Common It is easier to focus on the differences. But intellectual honesty requires acknowledging the structural similarities between US and Chinese data access law. There are more than the American technology industry would like to admit. Both claim extraterritorial jurisdiction. The CLOUD Act compels US companies to produce data regardless of where it is stored, including in the EU and UK. China’s National Intelligence Law applies to Chinese citizens and organisations wherever they operate. Both override the data sovereignty preferences of the countries where data physically resides. Both override contractual obligations. If your contract with a US provider says data will only be processed in the EU, a CLOUD Act warrant overrides that clause. If your contract with a Chinese provider is governed by English law, Chinese intelligence legislation overrides those obligations too. Both have been found wanting by European courts. The CJEU struck down two successive EU–US frameworks. Italy banned a Chinese AI provider. Ireland fined another €530 million for transfers to China. European institutions have expressed concern about both systems. Both create an irreconcilable conflict for European companies. UK GDPR requires that you ensure data is protected to an equivalent standard when transferred internationally. Neither US nor Chinese law can provide that guarantee, because both reserve the right to access that data unilaterally, overriding any protection you’ve put in place. The scale of oversight differs enormously. But the fundamental conflict is the same: a foreign government claims authority over data that European law says is yours. This is post 6 of 9. #datasecurity #CLOUDACT #GDPR #dataprivacy #compliance #datasovereignty #china **References:** eucrim, “Unpacking the CLOUD Act” [https://eucrim.eu/articles/unpacking-cloud-act](https://eucrim.eu/articles/unpacking-cloud-act) Irish DPC, TikTok Decision (2 May 2025) [https://www.dataprotection.ie/en/news-media/latest-news/irish-data-protection-commission-fines-tiktok-eu530-million-and-orders-corrective-measures-following](https://www.dataprotection.ie/en/news-media/latest-news/irish-data-protection-commission-fines-tiktok-eu530-million-and-orders-corrective-measures-following) CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) **Verified References** 1. eucrim, “Unpacking the CLOUD Act” [https://eucrim.eu/articles/unpacking-cloud-act](https://eucrim.eu/articles/unpacking-cloud-act) 2. Irish DPC, TikTok Decision (2 May 2025) [https://www.dataprotection.ie/en/news-media/latest-news/irish-data-protection-commission-fines-tiktok-eu530-million-and-orders-corrective-measures-following](https://www.dataprotection.ie/en/news-media/latest-news/irish-data-protection-commission-fines-tiktok-eu530-million-and-orders-corrective-measures-following) 3. CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) ### Post 7: Encryption — The One Technical Measure That Might Change the Equation If neither legal framework is safe, is there a technical answer? Partially. And it comes down to who holds the encryption keys. The CLOUD Act is explicitly “encryption neutral.” It does not create any authority for US law enforcement to compel service providers to decrypt data or build backdoors. If data is end-to-end encrypted and only you hold the keys, a CLOUD Act warrant cannot force the provider to produce it in readable form. This is confirmed by the Wiley Rein analysis of the US–UK Data Access Agreement. China’s Cryptography Law takes the opposite approach. The State Cryptography Administration can demand complete access to commercial encryption systems, including keys and passwords. The DHS confirmed the SCA has “full access to decryption keys, passwords, and any other information needed to access data on a commercially encrypted server.” This is the one area where the difference between US and Chinese law creates a genuinely different risk mitigation strategy. With US providers, customer-managed encryption keys are a meaningful technical safeguard. With Chinese providers, they are not, because the Chinese state may already hold the keys. But encryption is not a complete solution for US providers either. Many cloud services require access to unencrypted data to function. AI APIs by definition process the content you send them. You cannot encrypt a prompt sent to an AI model and still get a useful response. The model must see your data in plaintext. This is why data sanitisation, removing sensitive information before it leaves your infrastructure, is the only approach that works regardless of which superpower’s legal system you’re dealing with. This is post 7 of 9. #encryption #datasecurity #cybersecurity #compliance #CLOUDACT #datasovereignty #dataprivacy **References:** Wiley Rein LLP, “The CLOUD Act Data Access Agreement — 10 Things Companies Need to Know” [https://www.wiley.law/alert-The-CLOUD-Act-Data-Access-Agreement-10-Things-That-US-Telecommunications-Companies-Need-to-Know-Now](https://www.wiley.law/alert-The-CLOUD-Act-Data-Access-Agreement-10-Things-That-US-Telecommunications-Companies-Need-to-Know-Now) US Department of Homeland Security, “Data Security Business Advisory” (2020) [https://www.dhs.gov/sites/default/files/publications/20\_1222\_data-security-business-advisory.pdf](https://www.dhs.gov/sites/default/files/publications/20_1222_data-security-business-advisory.pdf) Lawfare, “The U.K.–U.S. Data Access Agreement” (June 2025) [https://www.lawfaremedia.org/article/the-u.k.-u.s.-data-access-agreement](https://www.lawfaremedia.org/article/the-u.k.-u.s.-data-access-agreement) **Verified References** 1. Wiley Rein LLP, “The CLOUD Act Data Access Agreement — 10 Things Companies Need to Know” [https://www.wiley.law/alert-The-CLOUD-Act-Data-Access-Agreement-10-Things-That-US-Telecommunications-Companies-Need-to-Know-Now](https://www.wiley.law/alert-The-CLOUD-Act-Data-Access-Agreement-10-Things-That-US-Telecommunications-Companies-Need-to-Know-Now) 2. US Department of Homeland Security, “Data Security Business Advisory” (2020) [https://www.dhs.gov/sites/default/files/publications/20\_1222\_data-security-business-advisory.pdf](https://www.dhs.gov/sites/default/files/publications/20_1222_data-security-business-advisory.pdf) 3. Lawfare, “The U.K.–U.S. Data Access Agreement” (June 2025) [https://www.lawfaremedia.org/article/the-u.k.-u.s.-data-access-agreement](https://www.lawfaremedia.org/article/the-u.k.-u.s.-data-access-agreement) ### Post 8: Then Canada Blew It All Up — The OVH Case and the Death of Data Residency For seven posts, this series has focused on the US and China. That’s where everyone’s attention is. That’s where it’s wrong. On 25 September 2025, a judge in Ontario ordered OVHcloud, a French company, headquartered in Roubaix, storing data on servers in France, the UK, and Australia, to hand over customer data to the Royal Canadian Mounted Police. Not through a mutual legal assistance treaty. Not through diplomatic channels. Directly. OVHcloud’s Canadian subsidiary argued it had no technical access to the parent company’s data. France’s intelligence and economic security service, the SISSE, wrote to the court twice warning that disclosure would violate French law. The French Ministry of Justice offered to expedite the request through official channels. OVH demonstrated the data was held by a separate legal entity in a separate jurisdiction. The judge ordered production anyway. Her reasoning: OVH has a “virtual presence” in Canada because it offers services there. That was sufficient to establish Canadian jurisdiction over data stored in France. OVHcloud now faces criminal liability in both countries. Comply with Canada, break French law. Comply with France, face contempt in Canada. The company filed for judicial review in October 2025. Then in June 2025, Microsoft France’s legal director testified under oath before the French Senate. Asked whether he could guarantee that French citizen data in EU data centres would not be handed to US authorities, Anton Carniaux replied: “No, I cannot guarantee that.” This is not about the US. It is not about China. It is about any company, with any presence, in any foreign jurisdiction. The fixation on US versus China is taking everyone’s eye off the real issue: no foreign legal framework can protect European data. None. This is post 8 of 9. #datasovereignty #datasecurity #compliance #GDPR #dataprivacy #dataprotection #OVH **References:** The Register, “Canadian data order risks blowing a hole in EU sovereignty” (27 November 2025) [https://www.theregister.com/2025/11/27/canada\_court\_ovh](https://www.theregister.com/2025/11/27/canada_court_ovh) heise online, “Canadian Court: OVHcloud from France must hand over user data” (26 November 2025) [https://www.heise.de/en/news/Canadian-Court-OVHcloud-from-France-must-hand-over-user-data-11092029.html](https://www.heise.de/en/news/Canadian-Court-OVHcloud-from-France-must-hand-over-user-data-11092029.html) Canadian Privacy Law Blog, “What digital sovereignty? How a Canadian Court is forcing a French company to break French law” (December 2025) [https://blog.privacylawyer.ca/2025/12/what-digital-sovereignty-how-canadian.html](https://blog.privacylawyer.ca/2025/12/what-digital-sovereignty-how-canadian.html) CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) The Register, “Microsoft exec admits it cannot guarantee data sovereignty” (25 July 2025) [https://www.theregister.com/2025/07/25/microsoft\_admits\_it\_cannot\_guarantee](https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee) heise online, “Not sovereign: Microsoft cannot guarantee the security of EU data” (21 July 2025) [https://www.heise.de/en/news/Not-sovereign-Microsoft-cannot-guarantee-the-security-of-EU-data-10494789.html](https://www.heise.de/en/news/Not-sovereign-Microsoft-cannot-guarantee-the-security-of-EU-data-10494789.html) **Verified References** 1. The Register, “Canadian data order risks blowing a hole in EU sovereignty” (27 November 2025) [https://www.theregister.com/2025/11/27/canada\_court\_ovh](https://www.theregister.com/2025/11/27/canada_court_ovh) 2. heise online, “Canadian Court: OVHcloud from France must hand over user data” (26 November 2025) [https://www.heise.de/en/news/Canadian-Court-OVHcloud-from-France-must-hand-over-user-data-11092029.html](https://www.heise.de/en/news/Canadian-Court-OVHcloud-from-France-must-hand-over-user-data-11092029.html) 3. Canadian Privacy Law Blog, “What digital sovereignty? How a Canadian Court is forcing a French company to break French law” (December 2025) [https://blog.privacylawyer.ca/2025/12/what-digital-sovereignty-how-canadian.html](https://blog.privacylawyer.ca/2025/12/what-digital-sovereignty-how-canadian.html) 4. CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) 5. The Register, “Microsoft exec admits it cannot guarantee data sovereignty” (25 July 2025) [https://www.theregister.com/2025/07/25/microsoft\_admits\_it\_cannot\_guarantee](https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee) 6. heise online, “Not sovereign: Microsoft cannot guarantee the security of EU data” (21 July 2025) [https://www.heise.de/en/news/Not-sovereign-Microsoft-cannot-guarantee-the-security-of-EU-data-10494789.html](https://www.heise.de/en/news/Not-sovereign-Microsoft-cannot-guarantee-the-security-of-EU-data-10494789.html) ### Post 9: Whose Flag Protects You? — None of Them This series began with the US and China. It ends somewhere more uncomfortable. A Canadian court ordered a French company to hand over European data, bypassing international treaties entirely. Microsoft’s own legal director admitted under oath that no US company can guarantee European data stays beyond the reach of US authorities. The CLOUD Act, FISA Section 702, China’s National Intelligence Law, and now a Canadian “virtual presence” doctrine, every one of them claims authority over data that European law says belongs to European data subjects. The differences between these systems are real. China’s is the most dangerous: no oversight, no transparency, no reform mechanism. The US system has genuine constitutional constraints and a functioning, if fragile, adequacy framework. Canada’s assertion is the most alarming precisely because nobody saw it coming. But the conclusion is the same for all of them. No flag protects you. No adequacy decision prevents a warrant from being served. No Standard Contractual Clause overrides a foreign intelligence law. No data residency guarantee survives a “virtual presence” ruling. The entire debate about which country is safer is a distraction from the only question that matters: does sensitive data leave your control? If it does, you are relying on a foreign legal system to protect it. And as we have seen — from Washington, from Beijing, and now from Ottawa, foreign legal systems protect their own interests, not yours. The only protection that works regardless of jurisdiction is ensuring sensitive data never reaches a provider subject to foreign government access in the first place. That means data sanitisation before information leaves your infrastructure. That means controlling what is sent, not where it is stored. Whose flag protects you? Your own. If you take the right steps to make that mean something. Thank you for following this series. #datasecurity #compliance #GDPR #dataprivacy #datasovereignty #riskmanagement #cybersecurity #dataprotection **References:** ICO, Transfer Risk Assessment Guidance (updated January 2026) [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/transfer-risk-assessments](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/transfer-risk-assessments) CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) The Register, “Canadian data order risks blowing a hole in EU sovereignty” (27 November 2025) [https://www.theregister.com/2025/11/27/canada\_court\_ovh](https://www.theregister.com/2025/11/27/canada_court_ovh) The Register, “Microsoft exec admits it cannot guarantee data sovereignty” (25 July 2025) [https://www.theregister.com/2025/07/25/microsoft\_admits\_it\_cannot\_guarantee](https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee) **Verified References** 1. ICO, Transfer Risk Assessment Guidance (updated January 2026) [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/transfer-risk-assessments](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/transfer-risk-assessments) 2. CMS Law, “Demystifying the debate on the US CLOUD Act vs European/UK Data Sovereignty” (February 2026) [https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services](https://cms-lawnow.com/en/ealerts/2026/02/white-paper-demystifying-the-debate-on-the-us-cloud-act-vs-european-uk-data-sovereignty-in-the-context-of-cloud-services) 3. The Register, “Canadian data order risks blowing a hole in EU sovereignty” (27 November 2025) [https://www.theregister.com/2025/11/27/canada\_court\_ovh](https://www.theregister.com/2025/11/27/canada_court_ovh) 4. The Register, “Microsoft exec admits it cannot guarantee data sovereignty” (25 July 2025) [https://www.theregister.com/2025/07/25/microsoft\_admits\_it\_cannot\_guarantee](https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee) ## THE WISDOM OF FOOLISHNESS https://cattlegrid.uk/posts/the-wisdom-of-foolishness ### Contents 1. Public-Key Cryptography — The “Fool’s Errand” That Secured the Internet 2. The Crypto Wars — When Encryption Was a Crime 3. Zero Trust — From “Neat But Impractical” to Presidential Executive Order 4. Full Disclosure — “Information Anarchy” That Saved Us All 5. Penetration Testing — “You Want to Pay Someone to Hack Us?” 6. Bug Bounties — Paying Strangers to Break Your Software 7. Multi-Factor Authentication — “Too Inconvenient” to Bother With 8. Open Source Security — “You’re Giving Attackers the Blueprint!” 9. The Pattern — Why the Establishment Always Gets It Wrong First Post 1: Public-Key Cryptography — The “Fool’s Errand” That Secured the Internet ### They told him he was wasting his time. When Martin Hellman began his research into public-key cryptography in the 1970s, every single one of his colleagues told him it was a fool’s errand. The NSA actively tried to suppress the work. An NSA employee warned the IEEE that a Stanford conference presentation by Hellman could violate export control laws. When MIT’s Ron Rivest published his RSA paper, elements within the NSA urged that it be seized and classified. ### But here’s the part that really stings for the establishment: GCHQ in the UK actually discovered it first. James Ellis theorised public-key cryptography in 1970. Clifford Cocks implemented RSA in 1973. Malcolm Williamson developed Diffie-Hellman key exchange. But GCHQ’s senior managers weren’t farsighted enough to see the digital revolution. They dismissed it as impractical. It was classified for 27 years. By the early 1980s, they were regretting that decision. The NSA’s initial reaction to civilian PKC? Amazement that it was created outside government, and recognition of its power as “a weapon of war.” Hellman later coined the phrase “the wisdom of foolishness.” He’s since asked six Nobel laureates whether their prize-winning work was initially encouraged or discouraged. Five of six were firmly in the “foolish, crazy, never go anywhere” camp. Today, public-key cryptography underpins every secure transaction on the internet. SSL/TLS, digital signatures, banking, e-commerce, all of it. The next time someone tells you an idea is stupid, remember: the entire digital economy runs on something that every expert said would never work. ### References: Hellman, M. (2025) “Federal Funding of Public Key Cryptography” — Communications of the ACM [https://cacm.acm.org/federal-funding-of-academic-research/federal-funding-of-public-key-cryptography](https://cacm.acm.org/federal-funding-of-academic-research/federal-funding-of-public-key-cryptography) Singh, S. “The Alternative History of Public-Key Cryptography” — Cryptome [https://cryptome.org/ukpk-alt.htm](https://cryptome.org/ukpk-alt.htm) National Academies Press — “A Brief History of Cryptography Policy” [https://nap.nationalacademies.org/read/5131/chapter/19](https://nap.nationalacademies.org/read/5131/chapter/19) FindLaw — “30 Years of Public Key Cryptography” [https://www.findlaw.com/legal/technology/legal-software/30-years-of-public-key-cryptography.html](https://www.findlaw.com/legal/technology/legal-software/30-years-of-public-key-cryptography.html) Verified References 1. Hellman, M. (2025) “Federal Funding of Public Key Cryptography” — Communications of the ACM [https://cacm.acm.org/federal-funding-of-academic-research/federal-funding-of-public-key-cryptography](https://cacm.acm.org/federal-funding-of-academic-research/federal-funding-of-public-key-cryptography) ### 2. Singh, S. “The Alternative History of Public-Key Cryptography” — Cryptome [https://cryptome.org/ukpk-alt.htm](https://cryptome.org/ukpk-alt.htm) 3. National Academies Press — “A Brief History of Cryptography Policy” [https://nap.nationalacademies.org/read/5131/chapter/19](https://nap.nationalacademies.org/read/5131/chapter/19) 4. FindLaw — “30 Years of Public Key Cryptography” [https://www.findlaw.com/legal/technology/legal-software/30-years-of-public-key-cryptography.html](https://www.findlaw.com/legal/technology/legal-software/30-years-of-public-key-cryptography.html) Post 2: The Crypto Wars — When Encryption Was a Crime In the 1990s, the US government classified encryption as a weapon of war. Not metaphorically. Literally. Cryptographic software was listed alongside missiles and tanks on the US Munitions List. Exporting strong encryption was a federal offence. When Phil Zimmermann released PGP (Pretty Good Privacy) in 1991, giving ordinary people access to strong encryption for the first time, the US Justice Department launched a three-year criminal investigation. His alleged crime? Exporting munitions. The NSA publicly argued his software would be used by criminals and child abusers. The establishment’s grand plan was the Clipper Chip: NSA-designed encryption hardware with a built-in government backdoor. Every encryption key would be held in escrow by the government. The Clinton administration pushed it hard. It was a disaster. Cryptographer Matt Blaze defeated the chip’s encryption entirely. The tech industry, privacy advocates, and academics united against it. The Association for Computing Machinery urged the government to withdraw the proposal outright. Meanwhile, the NSA had deliberately weakened the Data Encryption Standard. IBM originally designed DES with 128-bit keys. The NSA lobbied it down to 56 bits, known to be insecure as early as 1977. By September 1999, the government reversed course completely, removing virtually all restrictions on encryption exports. As journalist Steven Levy wrote: “It was official: public crypto was our friend.” Today, strong encryption is the foundation of the entire digital economy. Every online banking session, every e-commerce transaction, every private message, all protected by the very technology the establishment tried to criminalise. ### References: Wikipedia — “Crypto Wars” [https://en.wikipedia.org/wiki/Crypto\_Wars](https://en.wikipedia.org/wiki/Crypto_Wars) New America — “Doomed to Repeat History? Lessons from the Crypto Wars of the 1990s” [https://www.newamerica.org/cybersecurity-initiative/policy-papers/doomed-to-repeat-history-lessons-from-the-crypto-wars-of-the-1990s](https://www.newamerica.org/cybersecurity-initiative/policy-papers/doomed-to-repeat-history-lessons-from-the-crypto-wars-of-the-1990s) Reason — “When Encryption Was a Crime” (2020) [https://reason.com/video/2020/10/21/cryptowars-gilmore-zimmermann-cryptography](https://reason.com/video/2020/10/21/cryptowars-gilmore-zimmermann-cryptography) Verified References 1. Wikipedia — “Crypto Wars” [https://en.wikipedia.org/wiki/Crypto\_Wars](https://en.wikipedia.org/wiki/Crypto_Wars) 2. New America — “Doomed to Repeat History? Lessons from the Crypto Wars of the 1990s” [https://www.newamerica.org/cybersecurity-initiative/policy-papers/doomed-to-repeat-history-lessons-from-the-crypto-wars-of-the-1990s](https://www.newamerica.org/cybersecurity-initiative/policy-papers/doomed-to-repeat-history-lessons-from-the-crypto-wars-of-the-1990s) 3. Reason — “When Encryption Was a Crime” (2020) [https://reason.com/video/2020/10/21/cryptowars-gilmore-zimmermann-cryptography](https://reason.com/video/2020/10/21/cryptowars-gilmore-zimmermann-cryptography) Post 3: Zero Trust — From “Neat But Impractical” to Presidential Executive Order For decades, cybersecurity worked like a castle with a moat. Build a big wall (firewall). Put everything valuable inside. Trust everyone who gets through the gate. This was gospel. Anyone who questioned it was dismissed. In 1994, Stephen Paul Marsh first proposed the concept of “zero trust” in his doctoral thesis at the University of Stirling. The idea? Stop trusting things just because they’re inside your network. The response from the industry? Silence, then dismissal. In 2004, the Jericho Forum’s Paul Simmonds coined “deperimeterisation” and argued the castle-and-moat model was fundamentally broken. Most exploits would bypass perimeter security easily, he said. Building a harder wall was a losing battle. John Kindervag at Forrester formalised the term “Zero Trust” in 2010, writing: “Information security professionals must eliminate the soft chewy centre by making security ubiquitous throughout the network, not just at the perimeter.” The industry’s reaction? A niche academic concept. Too complex. Too disruptive. Users would revolt. Then Google published BeyondCorp in 2014, widely credited with transforming Zero Trust from “a neat but impractical idea” to “an urgent mandate.” Google had built it in response to a Chinese military cyber attack (Operation Aurora) that proved the perimeter model was fatally flawed. Users did initially resist. They complained about extra authentication prompts. They wanted more access than they needed. Then reality hit. Breach after breach showed that once attackers got inside the perimeter, they had the run of the place. By 2021, President Biden made Zero Trust a federal mandate by executive order. Okta reported in 2023 that 61% of organisations globally now have a defined Zero Trust initiative — up from just 16% in 2018. From laughable to law in under a decade. References: 1Password — “The History, Evolution, and Controversies of Zero Trust” [https://blog.1password.com/history-of-zero-trust](https://blog.1password.com/history-of-zero-trust) Censys — “The Evolution of the Zero Trust Framework: The Origins” [https://censys.com/blog/the-evolution-of-the-zero-trust-framework-the-origins](https://censys.com/blog/the-evolution-of-the-zero-trust-framework-the-origins) ISC2 — “15 Years of Zero Trust” (2025) [https://www.isc2.org/Insights/2025/10/15-Years-of-Zero-Trust](https://www.isc2.org/Insights/2025/10/15-Years-of-Zero-Trust) SecurityWeek — “Zero Trust Is 15 Years Old” (2025) [https://www.securityweek.com/zero-trust-is-15-years-old-why-full-adoption-is-worth-the-struggle](https://www.securityweek.com/zero-trust-is-15-years-old-why-full-adoption-is-worth-the-struggle) Verified References 1. Password — “The History, Evolution, and Controversies of Zero Trust” [https://blog.1password.com/history-of-zero-trust](https://blog.1password.com/history-of-zero-trust) 2. Censys — “The Evolution of the Zero Trust Framework: The Origins” [https://censys.com/blog/the-evolution-of-the-zero-trust-framework-the-origins](https://censys.com/blog/the-evolution-of-the-zero-trust-framework-the-origins) 3. ISC2 — “15 Years of Zero Trust” (2025) [https://www.isc2.org/Insights/2025/10/15-Years-of-Zero-Trust](https://www.isc2.org/Insights/2025/10/15-Years-of-Zero-Trust) 4. SecurityWeek — “Zero Trust Is 15 Years Old” (2025) [https://www.securityweek.com/zero-trust-is-15-years-old-why-full-adoption-is-worth-the-struggle](https://www.securityweek.com/zero-trust-is-15-years-old-why-full-adoption-is-worth-the-struggle) Post 4: Full Disclosure — “Information Anarchy” That Saved Us All Microsoft’s security manager called it “information anarchy.” The idea was simple: when you find a security vulnerability, tell the world. Don’t quietly whisper to the vendor and hope they fix it. Publish the details. Let everyone, defenders and attackers alike, know. The establishment went apoplectic. This debate is actually older than computers. In the 1850s, locksmith Alfred Hobbs demonstrated he could pick the most advanced locks in the world. Lock manufacturers argued that publishing such knowledge would help criminals. Hobbs argued the opposite: secrecy only helped the criminals who already knew, while leaving everyone else defenceless. In the software world, the same battle played out for decades. Before full disclosure became the norm, researchers would privately report vulnerabilities to software companies, who would ignore them. Some vendors threatened researchers with legal action if they went public. Why spend money fixing a bug nobody knows about? Bruce Schneier put it bluntly: “Full disclosure, the practice of making the details of security vulnerabilities public, is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure.” The vendors eventually proposed “responsible disclosure”, a private grace period before going public. But as Schneier noted, this only works because full disclosure remains the threat. Without that pressure, vendors go back to ignoring problems. Today, coordinated vulnerability disclosure is industry standard. Google’s Project Zero enforces 90-day deadlines. CISA actively supports disclosure programmes. Bug bounty platforms formalise the entire process. Nearly all responsible major software companies on earth now have a vulnerability disclosure programme. All because a few “irresponsible” researchers refused to keep quiet. References: Wikipedia — “Full Disclosure (Computer Security)” https://en.wikipedia.org/wiki/Full\_disclosure\_(computer\_security) Schneier, B. (2007) “Full Disclosure of Security Vulnerabilities a ‘Damned Good Idea'” Markkula Center for Applied Ethics — “The Vulnerability Disclosure Debate” [https://www.scu.edu/ethics/focus-areas/business-ethics/resources/the-vulnerability-disclosure-debate](https://www.scu.edu/ethics/focus-areas/business-ethics/resources/the-vulnerability-disclosure-debate) Verified References 1. Wikipedia — “Full Disclosure (Computer Security)” https://en.wikipedia.org/wiki/Full\_disclosure\_(computer\_security) 2. Schneier, B. (2007) “Full Disclosure of Security Vulnerabilities a ‘Damned Good Idea'” Schneier: Full Disclosure of Security Vulnerabilities a ‘Damned Good Idea’ 3. Markkula Center for Applied Ethics — “The Vulnerability Disclosure Debate” [https://www.scu.edu/ethics/focus-areas/business-ethics/resources/the-vulnerability-disclosure-debate](https://www.scu.edu/ethics/focus-areas/business-ethics/resources/the-vulnerability-disclosure-debate) Post 5: Penetration Testing — “You Want to Pay Someone to Hack Us?” Imagine walking into a 1980s boardroom and saying: “I’d like to hire someone to break into our computer systems.” You’d have been shown the door. Yet the concept dates back to 1967, when Willis Ware of the RAND Corporation warned that private companies wouldn’t invest enough to keep determined outsiders from accessing their data. His paper “Security and Privacy in Computer Systems” became a manifesto for the cybersecurity industry. The military got it first. In 1971, the US Air Force ordered security testing for time-shared computer systems. By the mid-1970s, “Tiger Teams”, specialised groups tasked with stress-testing security, were running formal penetration tests. In 1974, the Air Force ran one of the first known “white hat” attacks against its own MULTICS system, revealing critical security flaws. But for the private sector? The very idea was absurd. Why would you deliberately attack your own systems? Why would you trust an outsider with that access? The prevailing wisdom was simple: build stronger defences, don’t invite people to test them. The term “ethical hacker” was considered an oxymoron. Hackers were criminals, full stop. The 1986 Computer Fraud and Abuse Act in the US didn’t distinguish between malicious and authorised testing, making pen testing a legal grey area for years. It took decades of catastrophic breaches to change minds. The private sector eventually realised that if you don’t test your own defences, someone else will and they won’t ask permission first. Today, the global penetration testing market is projected to exceed $5 billion annually by 2031. Certifications like CEH and OSCP are mainstream career paths. Red teams, purple teams, and continuous testing are standard practice. From boardroom joke to billion-dollar industry. References: Cybersecurity Ventures — “The History of Ethical Hacking and Penetration Testing” (2025) Cyphere — “The History of Penetration Testing” (2025) [https://thecyphere.com/blog/history-of-penetration-testing](https://thecyphere.com/blog/history-of-penetration-testing) Infosec Institute — “The History of Penetration Testing” [https://www.infosecinstitute.com/resources/penetration-testing/the-history-of-penetration-testing](https://www.infosecinstitute.com/resources/penetration-testing/the-history-of-penetration-testing) Verified References 1. Cybersecurity Ventures — “The History of Ethical Hacking and Penetration Testing” (2025) 2. Cyphere — “The History of Penetration Testing” (2025) [https://thecyphere.com/blog/history-of-penetration-testing](https://thecyphere.com/blog/history-of-penetration-testing) 3. Infosec Institute — “The History of Penetration Testing” [https://www.infosecinstitute.com/resources/penetration-testing/the-history-of-penetration-testing](https://www.infosecinstitute.com/resources/penetration-testing/the-history-of-penetration-testing) Post 6: Bug Bounties — Paying Strangers to Break Your Software “You want to pay random people on the internet to hack us?” That was the reaction most companies had to the idea of bug bounty programmes for over a decade. Netscape launched the very first one on 10th October 1995, offering cash rewards for bugs found in Navigator 2.0 Beta. It was considered a novelty, an experiment by a scrappy browser company. Nobody followed suit. For nearly ten years, the idea sat dormant. Mozilla picked it up in 2004, offering $500 for critical vulnerabilities in Firefox. A few “middleman” programmes like iDefense and TippingPoint’s Zero Day Initiative bridged the gap by buying vulnerabilities from researchers and passing them to vendors. But the mainstream tech industry? They were horrified by the concept. Companies feared that inviting external researchers would expose them to more vulnerabilities, not fewer. The idea that outsiders could find things your own security team couldn’t was an insult to internal capabilities. Google changed everything in 2010 with its Vulnerability Reward Programme. Facebook followed in 2011 with its Whitehat programme — no upper limit on payouts. Suddenly, the world’s biggest tech companies were openly paying strangers to break their software. The US Department of Defense launched “Hack the Pentagon” in 2016, the first federal bug bounty programme. The same government that once classified encryption as weapons was now inviting hackers to attack its own infrastructure. Today, platforms like HackerOne and Bugcrowd are mainstream. Thousands of organisations run continuous programmes. The US DoD has run over 40 bug bounty programmes, engaging 1,400+ researchers who’ve found 2,100+ vulnerabilities. From absurd to essential in 20 years. References: Wikipedia — “Bug Bounty Program” [https://en.wikipedia.org/wiki/Bug\_bounty\_program](https://en.wikipedia.org/wiki/Bug_bounty_program) Cobalt — “The History of Bug Bounty Programs” [https://www.cobalt.io/blog/the-history-of-bug-bounty-programs](https://www.cobalt.io/blog/the-history-of-bug-bounty-programs) Intigriti — “A History of Bug Bounty Programs & Incentivised Vulnerability Disclosure” [https://blog.intigriti.com/cybersecurity-news/history-bug-bounty-programs](https://blog.intigriti.com/cybersecurity-news/history-bug-bounty-programs) Verified References 1. Wikipedia — “Bug Bounty Program” [https://en.wikipedia.org/wiki/Bug\_bounty\_program](https://en.wikipedia.org/wiki/Bug_bounty_program) 2. Cobalt — “The History of Bug Bounty Programs” [https://www.cobalt.io/blog/the-history-of-bug-bounty-programs](https://www.cobalt.io/blog/the-history-of-bug-bounty-programs) 3. Intigriti — “A History of Bug Bounty Programs & Incentivised Vulnerability Disclosure” [https://blog.intigriti.com/cybersecurity-news/history-bug-bounty-programs](https://blog.intigriti.com/cybersecurity-news/history-bug-bounty-programs) Post 7: Multi-Factor Authentication — “Too Inconvenient” to Bother With For years, the cybersecurity establishment said passwords were enough. When multi-factor authentication was first proposed for mainstream use, the pushback was immediate and fierce, not from hackers, but from the very organisations it was designed to protect. “Too inconvenient.” “Users will revolt.” “It’ll kill productivity.” “The cost isn’t justified.” Even when the US Federal Financial Institutions Examination Council recommended MFA for online banking in 2005, the response from vendors was to game the system, promoting security questions and “secret images” as “multi-factor” authentication. The FFIEC had to issue supplemental guidelines in 2006 to clarify that these weren’t actual MFA at all. The resistance was so deep that when companies implemented MFA but made it optional, adoption rates were abysmal. People took the path of least resistance every time. It took an extraordinary parade of breaches, each one exposing millions of credentials, to shift the conversation. Stolen passwords became the single most common attack vector, causing 10% of all data breaches according to IBM. By 2016, President Obama published an editorial calling for a national campaign to move Americans beyond passwords. CISA now states that MFA makes accounts 99% less likely to be compromised. Today, MFA is effectively mandatory for any serious security posture. Major platforms enforce it. Regulators require it. Cyber insurance demands it. The technology that was “too inconvenient” is now the bare minimum. The most common password in use today is still 123456. The establishment was wrong to wait this long. References: CISA — “Multifactor Authentication” [https://www.cisa.gov/topics/cybersecurity-best-practices/multifactor-authentication](https://www.cisa.gov/topics/cybersecurity-best-practices/multifactor-authentication) IBM — “What is MFA (Multifactor Authentication)?” [https://www.ibm.com/think/topics/multi-factor-authentication](https://www.ibm.com/think/topics/multi-factor-authentication) Wikipedia — “Multi-factor Authentication” [https://en.wikipedia.org/wiki/Multi-factor\_authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) SailPoint — “What is Multi-Factor Authentication (MFA)?” [https://www.sailpoint.com/identity-library/what-is-multi-factor-authentication](https://www.sailpoint.com/identity-library/what-is-multi-factor-authentication) Verified References 1. CISA — “Multifactor Authentication” [https://www.cisa.gov/topics/cybersecurity-best-practices/multifactor-authentication](https://www.cisa.gov/topics/cybersecurity-best-practices/multifactor-authentication) 2. IBM — “What is MFA (Multifactor Authentication)?” [https://www.ibm.com/think/topics/multi-factor-authentication](https://www.ibm.com/think/topics/multi-factor-authentication) 3. Wikipedia — “Multi-factor Authentication” [https://en.wikipedia.org/wiki/Multi-factor\_authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) 4. SailPoint — “What is Multi-Factor Authentication (MFA)?” [https://www.sailpoint.com/identity-library/what-is-multi-factor-authentication](https://www.sailpoint.com/identity-library/what-is-multi-factor-authentication) Post 8: Open Source Security — “You’re Giving Attackers the Blueprint!” “If attackers can read the source code, they’ll find all the vulnerabilities!” This was the dominant argument against open-source security software for decades. The establishment believed fervently in “security through obscurity”, if nobody can see how your system works, nobody can break it. ### This debate is far older than computing. In 1883, Dutch cryptographer Auguste Kerckhoffs published a principle that became foundational to all modern cryptography: “A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.” He was roundly ignored by most practitioners for over a century. In the 1850s, locksmith Alfred Hobbs picked every “unpickable” lock at the Great Exhibition, locks whose manufacturers insisted that secrecy of design was their primary defence. The manufacturers were furious. The public was enlightened. When open-source software began gaining traction in the 1990s, the establishment’s reaction was predictable: publishing source code gives attackers a blueprint. Microsoft, in particular, championed the closed-source model as inherently more secure. The US Department of Defense eventually dismantled this argument directly: “Hiding source code does inhibit the ability of third parties to respond to vulnerabilities, but this is obviously not a security advantage.” Decades of evidence now support the transparency advocates. Linux, despite fully public source code, demonstrates security competitive with or superior to closed-source alternatives. The world’s most trusted encryption algorithms, AES, RSA, ChaCha20, are all public. Their security depends on mathematical robustness, not secrecy. Today, open-source tools form the backbone of cybersecurity: Snort, Nmap, Metasploit, Wireshark, the entire Linux ecosystem. GitHub estimates open source is the foundation of 99% of the world’s software. Kerckhoffs was right in 1883. It took the industry over a century to catch up. References: Okta — “Security Through Obscurity: History, Criticism & Risks” [https://www.okta.com/identity-101/security-through-obscurity](https://www.okta.com/identity-101/security-through-obscurity) ACM — “Increased Security Through Open Source” [https://cacm.acm.org/research/increased-security-through-open-source](https://cacm.acm.org/research/increased-security-through-open-source) The New Stack — “Open Source Propels the Fall of Security by Obscurity” [https://thenewstack.io/open-source-propels-the-fall-of-security-by-obscurity](https://thenewstack.io/open-source-propels-the-fall-of-security-by-obscurity) Schneier, B. — “Open-Source Software Feels Insecure” Open-Source Software Feels Insecure Verified References 1. Okta — “Security Through Obscurity: History, Criticism & Risks” [https://www.okta.com/identity-101/security-through-obscurity](https://www.okta.com/identity-101/security-through-obscurity) 2. ACM — “Increased Security Through Open Source” [https://cacm.acm.org/research/increased-security-through-open-source](https://cacm.acm.org/research/increased-security-through-open-source) 3. The New Stack — “Open Source Propels the Fall of Security by Obscurity” [https://thenewstack.io/open-source-propels-the-fall-of-security-by-obscurity](https://thenewstack.io/open-source-propels-the-fall-of-security-by-obscurity) 4. Schneier, B. — “Open-Source Software Feels Insecure” Open-Source Software Feels Insecure Post 9: The Pattern — Why the Establishment Always Gets It Wrong First Over the past 8 posts, I’ve told the stories of cybersecurity ideas that were dismissed, ridiculed, suppressed, or criminalised by the establishment, and which are now the standard tools we all rely on. Public-key cryptography — colleagues called it a fool’s errand Strong civilian encryption — classified as a weapon of war Zero Trust — dismissed as neat but impractical Full disclosure — branded “information anarchy” Penetration testing — a boardroom joke Bug bounties — paying strangers to hack you? Multi-factor authentication — too inconvenient Open-source security — giving attackers the blueprint The pattern is remarkably consistent: 1. An outsider proposes something contrarian 2. The establishment dismisses it: through ridicule, legal threats, classification, or silence 3. Reality forces the issue: breaches, economic pressure, or technological change 4. The “stupid” idea becomes standard practice: often mandated by the very people who fought it Martin Hellman coined it “the wisdom of foolishness.” He asked six Nobel laureates whether their prize-winning work was initially encouraged. Five of six said it was dismissed as foolish. So what’s the lesson for today? Right now, there are ideas being dismissed that will be standard practice in ten years. AI data loss prevention. Data sovereignty enforcement. Outbound API inspection. Ephemeral processing architectures. The next time you hear “that’s not how we do things” or “that’s not practical” or “nobody needs that” — remember that every critical security tool we use today was once called exactly the same thing. There’s another thread running through every one of these stories: the concepts were simple, but making them work was brutally hard. Public-key cryptography is elegant mathematics — but implementing it securely at scale took decades. Zero Trust is two words — but re-architecting enterprise networks around it is an enormous engineering challenge. Full disclosure sounds obvious — but building the coordinated processes around it took years of painful iteration. Simple to explain. Ferociously difficult to build. That’s exactly where CattleGrid sits today. The concept is straightforward: inspect what your organisation sends to AI providers and stop sensitive data from leaking. Simple. But under the bonnet? Compliance detection accuracy. Sub-millisecond latency. Complete invisibility to end users. European data sovereignty. Ephemeral processing that never writes your data to disk. That’s the hard part — and CattleGrid has done that work for you. The question isn’t whether the establishment is wrong about something right now. It’s what they’re wrong about. ## The Current Security Landscape https://cattlegrid.uk/posts/the-current-security-landscape • Average UK breach cost: **£3.29 million** (financial services: £5.74 million) • Shadow AI breaches cost an additional **£498,000** • Internal threats (malicious/negligent/compromised) account for **30% of breaches** • **63% of breached organisations** lacked AI governance policies • Only **31% of UK organisations** have governance policies for AI usage The attacks that succeed—phishing campaigns exploiting human behaviour, insider threats, shadow AI data leakage, supply chain compromise—occur in the 90% of the attack surface that basic technical controls cannot address. For organisations serious about security, the question is not whether to obtain Cyber Essentials (government procurement may require it), but whether to treat it as sufficient security posture or as the bare minimum procurement hygiene it actually represents. ###  **EU AI Act: Penalties That Exceed GDPR** The EU AI Act, which began enforcement from August 2025, establishes penalty structures from inception that create existential risk for non-compliant organisations: **Tier 1 Violations** (Prohibited AI Practices): Up to **€35 million or 7% of global annual turnover**, whichever is higher **Tier 2 Violations** (Compliance Failures): Up to **€15 million or 3% of global annual turnover** **Tier 3 Violations** (Information Violations): Up to **€7.5 million or 1% of global annual turnover** For a UK mid-market firm with £100 million revenue, a Tier 1 violation could trigger €35 million (£30 million). For a growth company with £500 million revenue, that becomes €40.6 million (£35 million). For enterprises, the percentage-based calculation creates exposure that dwarfs fixed-penalty schemes. The Act requires demonstrable AI governance systems, risk assessments, transparency mechanisms, and continuous monitoring—precisely what ISO 42001 provides (and Cyber Essentials does not.) Organisations demonstrating mature governance frameworks through ISO 27001 and ISO 42001 certification position themselves to evidence good-faith compliance efforts—a significant factor in enforcement discretion and penalty mitigation. Aligning with ISO 42001 provides a “Presumption of Conformity” for many AI Act requirements. This certification is the most effective way to demonstrate “Lifecycle Monitoring” and build trust with international stakeholders, effectively turning regulatory compliance into a competitive advantage. ### **UK Data Protection Act and UK GDPR** Existing UK regulatory frameworks remain in force with cumulative exposure: • UK ICO fines up to £17.5 million or 4% of global turnover for UK GDPR violations • Data Protection Act 2018 parallel enforcement powers • Organisations operating in EU face both UK and EU regulatory regimes simultaneously • Regulatory actions become public, creating reputational damage beyond financial penalties Organisations can face operational disruption through requirements to withdraw non-compliant AI systems from the market, potentially halting business operations and disrupting customer relationships. For growth companies, regulatory censure can terminate funding rounds and partnership opportunities. ### **The Enterprise Security Imperative** Enterprise-class organisations—and SMEs aspiring to compete at that level—require security frameworks that address: • Strategic governance and board accountability for information security • Systematic risk assessment and management across all business processes • AI-specific controls for an environment where 85% of workflows integrate AI agents • Supply chain security in a landscape where 15% of UK breaches originate from third parties • Insider threat mitigation for the 30% of incidents involving internal actors • Continuous monitoring and improvement rather than annual self-assessment • Demonstrable due diligence for customers, partners, and insurers who understand security maturity This is why ISO 27001 has become the de facto enterprise security baseline, with ISO 42001 emerging as the standard for AI management systems. These frameworks provide demonstrable maturity that reduces breach costs by an average of £1.10 million through faster detection and containment. ### **Why ISO 27001 is the De Facto Enterprise Baseline** ISO 27001 provides what basic technical checklists cannot: a comprehensive Information Security Management System (ISMS) that addresses security as a strategic governance challenge, not merely a technical configuration exercise. ### **Core Capabilities** • Risk assessment methodologies that identify vulnerabilities across all business processes • Access control frameworks preventing unauthorised data exposure • Incident response protocols for rapid breach detection and containment • Third-party security requirements protecting against supply chain compromise • Continuous monitoring standards ensuring ongoing security assurance • Board-level accountability mechanisms embedding security into strategic governance ### **ISO 42001: AI Management Systems** Published December 2023, ISO 42001 represents the world’s first AI management system standard, addressing the governance gap that for those 63% of businesses exposed ### **AI-Specific Requirements** **1. AI Management System (AIMS)** • Documented policies for AI development, deployment, and usage • Clear objectives aligned with business strategy and risk appetite • Risk management processes tailored to AI-specific threats • Governance structures for AI decision-making and oversight **2. Risk Assessment and Management** • Systematic identification of AI-related risks (shadow AI, data leakage, model manipulation) • Impact assessments covering economic, societal, and regulatory dimensions • Mitigation controls for identified risks • Continuous evaluation and updating of risk profiles as AI usage evolves **3. Transparency and Accountability** • Explainability requirements for AI decision-making processes • Documentation of AI system capabilities and limitations • Audit trails for AI-driven actions and decisions • Stakeholder communication protocols for AI usage disclosure **4. Continuous Monitoring and Improvement** • Regular performance evaluations of AI systems and controls • Scheduled reviews at planned intervals • Course-correction mechanisms for identified issues • Adaptation to evolving threats and technologies ISO 42001 provides the AI governance framework that EU AI Act compliance requires and that Cyber Essentials does not address. For organisations serious about AI adoption, it represents the systematic approach to managing AI-specific risks whilst capturing AI’s productivity benefits. ### **Cattlegrid Recommendations and Fit** **1 Establish Strategic Security Posture** • Define board-level commitment to enterprise-class security, not procurement compliance and document risk appetite for AI adoption and data protection • Assign executive accountability for information security governance • Establish AI governance committee with cross-functional representation and  executive accountability and budget for ISO 27001 implementation **2. Conduct Comprehensive Risk Assessment** • Inventory all AI systems currently in use (sanctioned and shadow) and assess data exposure through AI services • Identify regulatory compliance gaps (EU AI Act, UK GDPR, DPA 2018) and quantify potential financial exposure • Evaluate current security posture against ISO 27001 requirements **3. Initiate ISO 27001 Certification Process** • Engage accredited certification body and develop implementation roadmap • Begin documentation of policies, procedures, and controls **4. Implement Technical Controls** • Deploy AI-specific data loss prevention (evaluate Cattlegrid or equivalent) • Extend monitoring to cover all AI API interactions • Establish real-time alerting for policy violations • Create audit trails for regulatory compliance • Target £498,000 shadow AI cost avoidance through technical controls **5. Build Organisational Capability** • Foster security-first culture through continuous education Conduct enterprise security awareness training for all employees Develop specialised training for AI system owners and developers    Establish AI ethics and responsible use guidelines **6. Complete ISO 27001 Certification** • Undergo Stage 1 audit (documentation review) • Undergo Stage 2 audit (implementation verification) • Address any non-conformities identified • Achieve certification and communicate to customers, partners, investors **7. Develop AI Management System (ISO 42001) and Pursue ISO 42001 Certification** • Evaluate certification as strategic differentiator for AI-intensive operations • Leverage certification for EU AI Act compliance demonstration • Position as AI governance maturity signal to enterprise customers and investors • Integrate with existing ISO 27001 ISMS for unified governance **8. Establish Continuous Evolution** • Conduct regular board-level reviews of AI risk landscape • Monitor regulatory developments across UK and EU jurisdictions • Update policies and controls as AI capabilities and threats evolve • Benchmark against enterprise peers and best practices • Maintain annual surveillance audits for ISO certifications ## We’re going to need a bigger boat https://cattlegrid.uk/posts/were-going-to-need-a-bigger-boat I say this by way of explanation. Its my job. Here at CattleGrid we’re building a toll that’s at the intersection of governance and technology, AI technology specifically. Fingers on the pulse. However at the moment that pulse is racing. The rate of change is astonishing. The usually staid commentary of the corporate world is buzzing with enthusiasm tempered with some measure of alarm; From a VP at Meta getting her inbox wiped by a rogue openclaw instruction through to the kill chains in the American attacks on Iran AI is the debate everyone’s having. And its the thing everyone’d doing. When you see stories about Accenture struggling to incentivise their senior managers to use their AI tools you know AI is just so *hot* right now. Different story on Discord and Reddit. These communities are building up and out at an alarming rate, built on the lies of Anthropic using its own LLMs to build int next LLMS , so to hiveminds of the global developer community are rushing to their prompts. It is exhilarating and terrifying at the same time to dip into those foaming waters. We cant close the beach now, if even we wanted to. But we do need to draw breath. While this unparalleled degree of activity starts to build up momentum let’s also realise that this community work is a demonstration of the speed, opportunity and challenge and not the challenge itself in the majority of cases. It brings light but not necessarily heat to the campfire. Listening to the corporate technical community its clear that the world of work is now in the sights of the AI giants. It carries some memory of the RPA push of what seems like a lifetime ago, and indeed the two workflows share more similarities than I think the likes of Anthropic would like to let on, but this does have the all important momentum it seems now, AI is in the Overton window, and with a smartphone in their hand the general public are paddling in the shallows in a way they never were with RPA. Technology in the hand and home leaches into the workplace, it forces change, and whilst I see the 85% numbers of AI embedded SMEs in the workplace as weirdly high, it is now an everyday occurrence for most white collar workers in some regard. How then need a CISO respond to this. as I said, you cant close the beach now. The government is trying as best a technocratic wonkocracy can be to be boosterish about the promise of AI but meanwhile looming in the distance is the impending enaction of the EUAI Act and the associated implications for fines and associated impacts. There’s a tendency in this country to lament red tape, especially Brussels red tape, but whatever your persuasion its clear that GDPR and legislation protecting the rights of the individual in a data economy have been implemented in this country far more effectively than anything since decimalisation. The EU Act will be another factor that organisations bringing AI in will need to consider, but to my mind there’s something they need to do first. To draw breath, and to look at the wider aims of the business to begin to trace out where AI has, can and will be interwoven into business practice. that will shine a light on where it overlaps protected or sensitive data -and thereby will it act as a cataract or a logjam. The how is important as it gives a perspective on how controls should be implemented, where controls could be implemented to best support the process as well as aiding compliance. Red tape snarls up the system when its not woven consciously into the system. AI tooling without its speed, its ability to evolve and innovate isn’t an improvement. doing this well and channelling its flow supports both a compliant set of workstreams and acts as a catalyst for innovation. It supports employee engagement, it drives productivity and it satisfies board nervousness without turning away the enthusiastic adoption. Agile controls built with new conformities, that understand the world of work has changed and operate withing a innovative mindset will be the modes of future governance that ensure businesses can thrive in a fast moving and compliant framework