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
Deploy your EU vault
Run an OpenBao (or HashiCorp Vault) instance in an EU jurisdiction — Frankfurt, Amsterdam, Dublin. You own it. The cloud provider has no access. Store your database credentials, API keys, encryption keys, and TLS certificates there.
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.
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
- EU financial services running regulated workloads on managed Kubernetes
- Healthcare companies with patient data subject to GDPR and sector-specific rules
- SaaS companies whose EU customers require data sovereignty guarantees
- Government contractors who need to demonstrate technical supplementary measures
- Any EU company that wants to use US cloud technology without the legal risk
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
- True client-side encryption — data is encrypted before it leaves your cluster
- Per-object unique keys — compromising one DEK doesn't compromise other objects
- Transient key wrapping — plaintext DEKs never touch disk or persistent storage
- Zero application changes — swap the S3 endpoint URL, everything else stays the same
- Multi-backend — works with AWS S3, GCS (S3-compatible mode), MinIO, Ceph, any S3 API
- Supports multipart uploads and range reads
- Audit trail — every encryption/decryption operation goes through the vault, creating a tamper-proof log
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
- API keys from environment variables and config files (OpenAI, Anthropic, cloud provider keys)
- Messaging tokens (Telegram bot token, Slack OAuth, Discord token)
- Crypto wallet credentials and seed phrases
- SSH keys, TLS certificates, service account tokens
- Chat history and persistent memory (personal data, business context)
- Browser session cookies via the built-in Chromium automation
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:
- "Scan my cluster for exposed secrets" — runs the CloudTaser CLI to discover K8s Secrets in pod specs and reports which workloads are unprotected
- "Show me which pods are CloudTaser-protected" — queries for
cloudtaser.io/injectannotations across namespaces - "Deploy CloudTaser to my cluster" — walks through Helm chart installation, configures vault address, sets up Kubernetes auth
- "Check eBPF alerts" — surfaces recent secret access violations from the eBPF agent logs
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:
- Application-level token sharing — if OpenClaw passes a token to a skill through its internal API (in-memory), CloudTaser can't intercept that handoff
- Prompt injection — a skill that tricks OpenClaw into running destructive commands is an application trust problem
- The missing skill vetting — ClawHub needs signing, provenance tracking, and sandboxing. CloudTaser reduces the blast radius but doesn't replace proper supply chain security