Fleuret raises €3.5M pre-seed

Sovereign EU AI pentest in 2026: why CLOUD Act, Schrems II, and the EU AI Act disqualify US providers

Augustin Ponsin, CPO9 min read

TL;DR

A US-headquartered cloud or LLM provider cannot offer EU technical sovereignty, no matter where the data sits. The CLOUD Act gives US authorities lawful reach over data held by US companies and their subsidiaries, regardless of the data's physical location. Schrems II invalidated Privacy Shield in 2020 and continues to constrain SCCs. The EU AI Act becomes fully applicable for high-risk systems on August 2, 2026, with penalties reaching 7 percent of global annual turnover.

For a regulated EU buyer evaluating "AI-powered pentest", the only stack that satisfies all three regimes is open-weight LLMs running on EU-controlled infrastructure, with a public sub-processors list and no US API call in the customer-data path.

That is the stack Fleuret runs. This article explains why each piece matters and gives a 7-question vendor checklist any CISO can use to verify the sovereignty claim before signing.

The shift from data residency to technical sovereignty

For a decade, EU compliance discussions have treated "data residency" (where the bytes physically sit) as the central question. That framing is obsolete.

Technical sovereignty is the new question, and it has two precise components:

  1. Operational control: who can read, modify, or copy the data, under whose jurisdiction.
  2. Technological control: who supplies the kernel, the orchestrator, the model weights, the network path, and under what licensing or geopolitical constraint.

A dataset hosted in Frankfurt by a US AWS region passes data residency. It fails technical sovereignty, because AWS is a US legal entity and the CLOUD Act applies. EU regulators (CNIL, BSI, ANSSI) have stated this in increasingly direct terms over the last 24 months.

For an AI pentest tool, the question becomes specific. If the LLM that reasons about your application's vulnerabilities is hosted by OpenAI, Anthropic, or Google, your test target's payloads, response bodies, and authentication artifacts pass through US-controlled infrastructure during the test. That is operationally indistinguishable from giving a US service provider read access to your production attack surface.

CLOUD Act: 60-second primer

The Clarifying Lawful Overseas Use of Data Act (2018, US) authorises US law enforcement to compel US-based providers to produce data they hold, regardless of where that data is physically stored. The provider is on the hook even if the customer is an EU entity and the data centre is in Paris.

US providers have built "sovereignty" offerings (AWS European Sovereign Cloud, Microsoft EU Data Boundary, Google Sovereign Controls) that try to insulate operations from US reach. These offerings reduce risk surface but do not legally extinguish CLOUD Act exposure as long as the legal entity is US.

For DORA-scope financial entities, this matters concretely. DORA Article 28 makes the financial entity ultimately responsible for ICT third-party risk. A US LLM provider in the data path is a third-party concentration risk that EU regulators are starting to flag in supervisory exercises.

Schrems II and the death of Privacy Shield

The 2020 CJEU ruling in Schrems II invalidated the EU-US Privacy Shield as a legal basis for transatlantic personal data transfer. Standard Contractual Clauses (SCCs) survived but require supplementary measures, which are non-trivial for a pentest workflow that processes potentially PII-containing payloads.

The 2023 Data Privacy Framework partially restored a transfer regime. But every CISO should know that Schrems III is widely expected, and the regime is therefore unstable. Buying into a US-LLM-dependent pentest tool today exposes you to the regime's next inflection point.

EU AI Act: high-risk obligations from August 2, 2026

The EU AI Act became applicable in stages. The relevant date for security tooling is August 2, 2026, when high-risk AI obligations take effect.

Pentest AI is not automatically high-risk under Annex III, but specific deployments are. If the AI is used for "evaluation of access to essential services" (financial, healthcare, critical infrastructure) or for cybersecurity decisions in regulated sectors, the high-risk obligations apply: documented data governance, bias detection, human oversight, technical documentation, post-market monitoring, registration in the EU AI database.

Two operational consequences for any pentest vendor:

  1. The model provider's data governance must be documentable. A frontier API where the provider does not disclose training data sources or guarantee model immutability between calls is hard to fit into the AI Act's documentation regime.
  2. The vendor must be able to produce technical documentation on demand. For a provider whose model is a closed third-party API, this documentation is partially controlled by the third party.

Open-weight models (gpt-oss-120b, gpt-oss-20b, Kimi K2.5, Mistral Large) sidestep both issues. The weights are inspectable. The model is bit-identical between calls. The deployment is under the vendor's full operational control.

The DORA disqualification of US providers

DORA does not name countries, but the structural effect is clear. Article 28 (third-party risk) plus Article 30 (concentration risk) plus the supervisory expectations under the RTS make US-headquartered ICT third parties increasingly hard to onboard for designated financial entities.

The combination is sharper for AI providers than for general cloud. A general cloud provider can be partially mitigated with encryption-at-rest, BYOK, and customer-managed keys. An LLM provider necessarily decrypts the prompt server-side to compute the response. There is no equivalent of BYOK for inference. If the LLM is in the data path of the pentest, the LLM provider sees the prompt content.

This is why XBOW, Pentera, and Horizon3, regardless of their technical merit, struggle to land EU regulated buyers. It is not a tariff problem. It is a structural sovereignty problem.

What a sovereign pentest stack actually looks like

The five components, each verifiable.

  1. Open-weight LLMs only. We run gpt-oss-120b and gpt-oss-20b for the heavy reasoning agents, plus Kimi K2.5 for long-context tasks. No OpenAI, Anthropic, Google, or other US frontier API in the customer-data path.
  2. Sovereign compute. Inference runs on Scaleway H100 GPU clusters in France. Scaleway is a French legal entity (Iliad group), under French jurisdiction.
  3. EU-only application infrastructure. The web app and serverless functions run on Vercel pinned to the fra1 region. Database is Supabase EU project. No US-region fallback.
  4. Public sub-processors list. Every third party that touches customer data is enumerated on a machine-readable /sub-processors page, with jurisdiction, purpose, and data category. RGPD article 28 + DPA artifact, public and auditable.
  5. No US API in the customer-data path. Marketing analytics and operational telemetry are isolated from the pentest data path. The technical guarantee is enforced by network egress controls, not by policy alone.

7-question sovereignty checklist for any EU pentest vendor in 2026

Use this verbatim. A vendor that says "yes" to fewer than five is not selling sovereign pentest.

  1. Are the LLMs you use open-weight, with the model identifier and version disclosed in your sub-processors page?
  2. Is the LLM inference performed on infrastructure operated by an EU legal entity, with no US legal entity in the operational chain?
  3. Is your full sub-processors list public and machine-readable, with jurisdiction per processor?
  4. Do you contractually guarantee that no customer-test-target data leaves the EU at any point in the pentest workflow?
  5. For DORA-scope buyers, can you produce documentation that supports our concentration-risk and third-party-risk reporting under Article 28?
  6. For EU AI Act high-risk deployments, can you provide the technical documentation required under Articles 11 and 12, including data governance and human oversight processes?
  7. What is your stated position on Schrems III, and what contractual mechanism protects us if a future ruling invalidates the Data Privacy Framework?

If a vendor needs more than 48 hours to answer any of these, the answer is effectively no.

How Fleuret answers each

  1. Yes. gpt-oss-120b, gpt-oss-20b, Kimi K2.5. Versions tracked in /sub-processors.
  2. Yes. Scaleway France (H100), Iliad group, French jurisdiction. No US legal entity in the inference chain.
  3. Yes. /sub-processors is public, JSON-readable, with jurisdiction per processor.
  4. Yes. Customer-test-target data does not leave EU during scan, reasoning, or report generation.
  5. Yes. Concentration-risk and third-party-risk artifacts available on request, structured for DORA Article 28 reporting.
  6. Yes. Technical documentation per AI Act Articles 11 and 12 maintained; published on request to qualified buyers.
  7. We do not bet on the Data Privacy Framework. Our stack is structurally insulated from a Schrems III scenario because no transatlantic transfer occurs in the customer-data path.

What this means if you are a CISO or DPO buying pentest in 2026

The "best AI pentest tool" question collapses, for an EU regulated buyer, into a sovereignty filter applied before any technical evaluation. Tools that fail the sovereignty filter cannot be used regardless of how strong their detection rate is.

The EU agentic-pentest set that passes the filter is small. Fleuret (sovereign FR), Patrowl (FR, exposure management), and parts of Escape's stack (FR) clear the bar. Most of the well-funded category leaders (XBOW, Horizon3, Pentera) do not.

If you are evaluating pentest tooling for a NIS2-scope or DORA-scope entity in 2026, run the 7-question checklist before the product demo, not after. It saves a four-week procurement loop on a vendor that will fail your legal review.

For mid-market entities (300 to 5,000 employees) in the design partner cohort window: the cohort is open. 5 slots. €4,900 flat. 3 AI pentests in 6 weeks. NIS2 / DORA-ready PDF. June 1, 2026 kickoff. Sovereign stack by default.

Sources

Share this postShare on LinkedIn

The Fleuret newsletter

One email a month. Cyber analysis, DORA, NIS2, and what we learn pentesting our customers' apps.

Privacy Settings

This site uses third-party website tracking technologies to provide and continually improve our services, and to display information according to users' interests. I agree and may revoke or change my consent at any time with effect for the future.

Privacy PolicyLegal NoticeMore Information