Use Cases

Where CloudTaser makes a difference — from regulatory compliance to securing AI agents.

EU Data on US Cloud Infrastructure

The core use case. You're an EU company running workloads on AWS, GCP, or Azure — because the technology is best-in-class. But the CLOUD Act (2018) and FISA Section 702 give US authorities the legal power to compel your cloud provider to hand over data, regardless of where it's stored. The Schrems II ruling (CJEU, 2020) invalidated the EU-US Privacy Shield for exactly this reason. The current EU-US Data Privacy Framework is already facing legal challenges.

The EDPB recommends "effective supplementary technical measures" — specifically, client-side encryption where the cloud provider does not have access to the keys. That's exactly what CloudTaser implements.

How it works

01

Deploy your EU vault

Run an OpenBao (or HashiCorp Vault) instance in an EU/UK jurisdiction — Frankfurt, Amsterdam, Dublin, London. You own it. The cloud provider has no access. Store your database credentials, API keys, encryption keys, and TLS certificates there.

02

Install CloudTaser via Helm

A single helm install deploys the operator, wrapper, and eBPF agent to your managed Kubernetes cluster. Works on GKE, EKS, and AKS. The operator registers a mutating admission webhook — from this point, any pod with the cloudtaser.io/inject: "true" annotation gets automatic protection.

03

Annotate your workloads

Add annotations to your deployments. The operator wraps the application process, fetches secrets from the EU vault into memory, and the eBPF agent monitors for unauthorized access. No Dockerfile changes, no application code changes, no Helm template rewrites.

metadata:
  annotations:
    cloudtaser.io/inject: "true"
    cloudtaser.io/vault-address: "https://vault.eu.example.com"
    cloudtaser.io/vault-role: "my-app"
    cloudtaser.io/secret-paths: "secret/data/db/credentials"
    cloudtaser.io/env-map: "password=DB_PASSWORD,username=DB_USER"

Who this is for

Client-Side Encryption for Object Storage

Even without the EU sovereignty angle, the CloudTaser S3 Proxy is useful as a standalone encryption layer for any S3-compatible storage.

The problem with server-side encryption

AWS SSE-S3, SSE-KMS, GCS CMEK, and Azure CMK all encrypt data at rest — but the provider holds the keys or has access to them during encryption/decryption operations. "Encryption at rest" means the disk is encrypted, not that the provider can't read your data. They can, and under a court order or internal access, they will.

How CloudTaser S3 Proxy works

The proxy sits between your application and the storage endpoint. It implements envelope encryption: each object gets a unique data encryption key (DEK), the DEK encrypts the object with AES-256-GCM, and the DEK itself is wrapped via the OpenBao Transit secret engine using a transient key. The plaintext DEK never persists — it exists only in memory during the encryption operation.

Your application connects to the proxy instead of the provider endpoint (just change the S3 URL). The proxy handles encryption on upload and decryption on download transparently. Works with any S3 SDK — AWS CLI, boto3, MinIO client, any application that speaks S3 protocol.

Standalone benefits

Regulatory Landscape

The legal ground under EU-US data transfers gets shakier every year. The only thing that survives regardless of which framework gets invalidated next is technical measures that make provider access physically impossible.

Key events CloudTaser addresses

Date Event What happened CloudTaser relevance
Jul 2020 Schrems II CJEU invalidated EU-US Privacy Shield. Transfers require "effective supplementary measures." Source The ruling that created the legal requirement for what CloudTaser does
Mar 2018 US CLOUD Act US providers must hand over data regardless of where it's stored — including EU data centers. Source Provider can't hand over what they can't decrypt
Apr 2024 FISA 702 expanded Broadened "electronic communication service provider" definition. Source More providers can be compelled — more workloads need protection
Jan 2025 PCLOB gutted All Democratic members fired, DPF compliance review suspended. Source Key DPF safeguard gone — technical measures are the only reliable fallback
Mar 2025 FTC commissioners fired DPF enforcement body weakened. Source Contracts alone are unreliable — need cryptographic guarantees
May 2023 Meta fined EUR 1.2B Largest GDPR fine ever — SCCs without adequate protections. Source SCCs alone aren't enough — CloudTaser is the supplementary measure
Mar 2024 EDPS: Commission's M365 use illegal EU Commission itself found violating data protection using Microsoft 365. Source If the Commission can't comply without technical measures, nobody can
Nov 2025 DORA: hyperscalers designated critical AWS, Google, Azure classified as Critical ICT Third-Party Providers. Source Financial sector must demonstrate third-party risk management
Sep 2025 EU Data Act enters application Chapter VII blocks unlawful third-country government access. Source Codifies what CloudTaser enables technically
Feb 2025 Norway DPA: prepare exit strategies First national DPA to formally advise US cloud exit planning. Denmark, Germany followed. Source CloudTaser is the alternative to exit — stay on US cloud, remove the risk
Oct 2024 NIS2 transposition deadline Cloud providers classified as essential entities. Fines up to EUR 10M or 2% revenue. Source eBPF monitoring + encrypted secrets satisfies cybersecurity requirements
Jul 2022 Denmark bans Google Chromebooks Datatilsynet banned Google Workspace in schools. Expanded nationwide Jan 2024. Source "Encryption at rest" is insufficient when the provider holds the keys
Nov 2025 France-Germany sovereignty summit Joint task force to reduce US cloud dependence. Procurement restrictions expected. Source CloudTaser lets you comply without migrating off US cloud

Compliance frameworks CloudTaser covers

Framework Requirement How CloudTaser satisfies it
GDPR (Articles 44-49) Adequate protection for data transferred to third countries. Supplementary measures required post-Schrems II. Client-side encryption with EU-held keys = EDPB-recommended supplementary measure. Provider physically cannot access plaintext.
EDPB Recommendations 01/2020 Use Case 2: "Transfer to cloud service providers or other processors which require access to data in the clear." Recommends encryption where the importer does not hold keys. Exact implementation: encryption keys in EU vault, secrets in process memory, provider sees only ciphertext.
DORA ICT risk management framework, third-party risk assessment, incident reporting, resilience testing for financial entities. eBPF monitoring provides runtime incident detection. Vault audit logs provide tamper-proof access records. S3 proxy encryption provides data-at-rest protection. Exit strategy enabled by portable vault + standard K8s.
NIS2 Cybersecurity risk management, supply chain security, incident reporting for essential/important entities. Cloud providers are essential entities. eBPF kernel-level monitoring, encrypted secrets not on disk, runtime enforcement mode for blocking unauthorized access.
EU Data Act (Chapter VII) Providers must take reasonable technical measures to prevent unlawful third-country government access to non-personal data. Client-side encryption makes data inaccessible to the provider regardless of government demands. Transient DEKs mean no persistent key material on provider infrastructure.
PCI DSS 4.0 Protect stored cardholder data. Encrypt transmission of cardholder data across open networks. Restrict access to cardholder data by business need-to-know. Secrets in memory (not on disk), AES-256-GCM object encryption, eBPF access monitoring enforces need-to-know at kernel level.
ISO 27001:2022 (A.8.24, A.8.11) Use of cryptography. Data masking. Protection of information in cloud services. Envelope encryption with transient keys, EU-jurisdiction key management, per-object unique DEKs, vault audit trail.
SOC 2 Type II Security, availability, processing integrity, confidentiality, privacy criteria for service organizations. Demonstrates encryption controls, access monitoring (eBPF logs), key management practices, and data residency for EU-focused trust service criteria.
German C5 Cloud Computing Compliance Criteria Catalogue by BSI. Required for German public sector cloud procurement. EU-hosted key management, client-side encryption, runtime monitoring satisfy C5 data sovereignty and encryption requirements.
France SecNumCloud ANSSI qualification for cloud service providers handling sensitive data. Requires immunity from non-EU laws. CloudTaser provides the technical layer that makes US-hosted infrastructure functionally immune to CLOUD Act access — data is ciphertext, keys are in EU.

Securing Self-Hosted AI Agents (OpenClaw) Planned

OpenClaw is an open-source personal AI assistant that connects to 20+ messaging platforms (WhatsApp, Telegram, Slack, Signal, iMessage), executes shell commands, browses the web, and manages credentials for 50+ services. Its skills ecosystem lets anyone publish extensions — and that's where the problems start.

The threat landscape

OpenClaw's ClawHub skill marketplace has seen over 1,000 malicious skills uploaded, leading to $1.2M+ in cryptocurrency stolen via the AMOS stealer campaign. Skills execute with full agent privileges — shell access, filesystem, network, keychains — with no sandboxing. Kaspersky identified 512 vulnerabilities, 8 critical. Multiple CVEs have been published including a CVSS 8.8 one-click RCE.

The core problem: OpenClaw stores API tokens (OpenAI, Telegram, Slack, crypto exchanges), chat history, and persistent memory either on disk or in cloud storage. When deployed to cloud infrastructure — which many users do for always-on availability — all of this becomes accessible to the cloud provider and to any malicious skill that can read files or environment variables.

What a malicious skill can steal today

There are no official, security-audited skills for critical integrations like Slack, Telegram, cloud provider APIs, or AI model endpoints. Every skill is community-contributed with no mandatory code review, no signing, and no provenance tracking. The lack of vetted skills for the most sensitive integrations — messaging platforms, financial APIs, AI model credentials — means users are forced to trust unaudited code with their most valuable secrets.

How CloudTaser helps

Attack vector Without CloudTaser With CloudTaser
API keys on disk / env files Trivial to steal — cat .env In process memory only — never on disk
/proc/environ reads Undetected — all env vars exposed eBPF detects and blocks the read
Chat history / memory storage Plaintext in object storage AES-256-GCM ciphertext via S3 proxy
Credential exfiltration to C2 Undetected curl to attacker server eBPF detects secret patterns in network buffers
Cloud provider access Provider can read everything Provider sees only ciphertext
Skill scanning local files for secrets Full filesystem access — SSH keys, wallets, configs Secrets not on filesystem — vault-only, memory-only
Court order / CLOUD Act Full access to all stored data Ciphertext and no keys to decrypt

Key insight: malicious skills that scan local files for secrets (SSH keys, wallet files, API key configs) find nothing — because CloudTaser ensures secrets never exist on the filesystem. They're fetched from the EU vault into process memory at startup and never written to disk. A skill executing find / -name "*.pem" or grep -r "sk-" ~/.config/ comes up empty.

CloudTaser as an OpenClaw Skill

CloudTaser can also be installed as an OpenClaw skill, providing a natural language interface to secret management and compliance monitoring:

The skill itself runs through the CloudTaser wrapper — so even the management interface is protected by the same secret injection and eBPF monitoring it manages.

What CloudTaser does not fix

CloudTaser is defense-in-depth, not a fix for OpenClaw's fundamental trust model. It cannot prevent: