Skip to content

Sovereignty Pitfalls

Hidden ways EU data sovereignty is compromised. Most of these are invisible to developers who are not looking for them. Every pitfall here represents a real sovereignty gap, not a theoretical risk.

1. "EU Region" Is Not EU Sovereignty

What happens: A team selects AWS eu-west-1 (Ireland) or Azure West Europe (Netherlands) and marks the integration as "EU-compliant." The data physically sits in the EU. But AWS is a US company. Amazon can be compelled by US law enforcement to hand over that data under the CLOUD Act.

Why it is dangerous: On paper, the data is "in the EU." In legal reality, it is accessible to a foreign government without EU legal process. The sovereignty guarantee is illusory.

Rule: EU region is a necessary condition but not sufficient. The provider must be EU-headquartered.

2. Embedded US Trackers

What happens: A developer adds Google Fonts to the CSS. Every page load sends the user's IP address, browser fingerprint, and referrer URL to Google's servers (US). The analytics dashboard uses Google Analytics. Every user interaction is sent to Google (US). The cookie consent banner is loaded from a US CDN.

Common embedded trackers:

  • Google Fonts (fonts.googleapis.com)
  • Google Analytics (google-analytics.com)
  • Google Tag Manager
  • Facebook Pixel
  • HubSpot tracking script
  • Intercom chat widget
  • YouTube embeds (send data to Google)
  • Google reCAPTCHA (sends behavioral data to Google)

Prevention:

  • Self-host fonts — download and serve from EU infrastructure
  • Use Plausible or self-hosted analytics — no data leaves the EU
  • No third-party tracking scripts without Julian's approval
  • Audit all external script includes quarterly
  • Content Security Policy (CSP) headers that whitelist only approved external sources

3. DNS Resolution Through US Servers

What happens: The domain uses Cloudflare DNS or Route 53 (AWS). Every DNS query for the domain — from every user, every time — flows through US-operated infrastructure. DNS queries reveal which services users access and when.

Why it is overlooked: DNS is invisible to most developers. The application works the same regardless of who resolves the domain. But DNS metadata is data — and it flows through a US company's infrastructure.

Prevention: Use TransIP (NL) or bunny.net DNS (SI) for all DNS resolution. No US DNS providers in the chain.

4. Email Routing Through US Providers

What happens: The application sends transactional email via SendGrid (US — Twilio). Every email — password resets, invoices, notifications — is processed by a US company. Email content, recipient addresses, and metadata are all accessible under the CLOUD Act.

Less obvious: Even if the primary email provider is EU, the delivery path may route through US infrastructure. SMTP relays, spam filtering services, and reputation monitoring may involve US companies.

Prevention:

  • Use Brevo (FR) or Mailjet (FR/SE) for transactional email
  • Verify the delivery path — ask the provider about their SMTP relay chain
  • Use SPF, DKIM, and DMARC to prevent email routing through unauthorized servers

5. npm and Docker Hub as US Dependencies

What happens: Every npm install downloads packages from npm (GitHub/Microsoft — US). Every docker pull downloads images from Docker Hub (US). Package metadata includes IP addresses, download timestamps, and which packages are used.

Why it matters:

  • npm/Docker Hub know exactly what software stack GE uses
  • A US government demand could compel package supply chain information
  • Packages themselves could be tampered with at the registry level

Mitigation:

  • Use a caching proxy (Verdaccio for npm, Harbor for Docker) on EU infrastructure
  • First download goes to US registry, subsequent downloads are from EU cache
  • Pin package versions and verify checksums
  • This is documented as an accepted risk with Julian's approval — no EU npm/Docker alternative exists at scale

6. Client-Side SDK Data Leakage

What happens: A frontend developer includes a JavaScript SDK for a feature (payments, chat, analytics). The SDK phones home to the vendor's servers on every page load. It sends telemetry, crash reports, and usage data. The developer sees a nice widget. The SDK sees user behavior data flowing to a US company.

Common leaking SDKs:

  • Stripe.js — sends telemetry to Stripe (US) on every page load, even before a payment is initiated
  • Intercom Messenger — sends page views and user data to Intercom (US)
  • Sentry Browser SDK — sends error data with user context to Sentry (US) unless self-hosted
  • HubSpot tracking code — sends all page views to HubSpot (US)

Prevention:

  • Audit every client-side SDK for network requests
  • Use browser DevTools Network tab to see where data goes
  • Prefer server-side integrations over client-side SDKs
  • When client-side SDK is necessary, verify the vendor is EU-based or use a self-hosted alternative

7. LLM API Data Exposure

What happens: Agent execution sends prompts to LLM APIs (Anthropic — US, OpenAI — US). If task context includes client data, that data is processed on US infrastructure.

GE mitigation:

  • Client PII is never included in LLM prompts
  • Task descriptions are sanitized before LLM processing
  • LLM providers contractually commit to not training on API data
  • This is documented as a sovereignty exception
  • Active evaluation of EU-hosted alternatives (Mistral — France, self-hosted open-source models on EU infrastructure)

This is the most significant sovereignty gap in GE's stack and is under active remediation.

8. CI/CD Pipeline on US Infrastructure

What happens: GitHub Actions (US — Microsoft) runs the CI/CD pipeline. Every code push, every build, every test run flows through US infrastructure. Source code, build artifacts, test results, and deployment secrets are processed by a US company.

Prevention:

  • Self-hosted CI/CD runners on EU infrastructure
  • GitLab CI (EU entity — GitLab B.V. Netherlands) as migration target
  • GitHub is currently used with documented sovereignty exception
  • Build secrets injected from Vault, never stored in GitHub

9. Browser Geolocation and CDN Routing

What happens: A CDN routes some users through non-EU PoPs for performance optimization. An EU user near a border might be routed through a Swiss or UK PoP. While both have adequacy decisions, the routing is invisible and uncontrolled.

Prevention:

  • bunny.net EU-only routing filter — restricts traffic to EU PoPs
  • Verify routing with traceroute and CDN analytics
  • Monitor for unexpected non-EU PoP hits in CDN logs

10. Cookies Set by Third-Party Domains

What happens: An embedded widget (payment form, chat, video) sets cookies from a third-party domain. Those cookies are sent to the third-party server on every subsequent request — from the user's browser to the third-party's infrastructure (potentially US).

Prevention:

  • Audit all cookies with browser DevTools → Application → Cookies
  • Block third-party cookies via SameSite=Strict where possible
  • Cookie consent must enumerate every cookie and its destination
  • Remove cookies that send data to US-operated servers

Summary

Pitfall Severity Detection
"EU region" confusion Critical Provider HQ verification
Embedded US trackers High CSP audit, network inspection
US DNS providers High DNS chain verification
US email routing High SMTP path verification
npm/Docker Hub Medium Accepted risk, caching proxy
Client-side SDK leakage High Network request audit
LLM API exposure High Documented exception, active remediation
US CI/CD pipeline Medium Migration to self-hosted planned
CDN routing leakage Low EU-only routing filter
Third-party cookies Medium Cookie audit

Ownership

Role Agent Responsibility
Compliance Officer Julian Sovereignty audit, exception approval
Infrastructure Arjan Infrastructure sovereignty verification
Network Engineer Stef Network path verification
Edge Specialist Karel CDN routing verification
All dev agents All Awareness of these pitfalls during development