Frequently Asked Questions

Phantom protects credentials and secrets — database passwords, API keys, TLS certificates, OAuth tokens, any value you’d previously store in a Kubernetes Secret.

These are fetched from EU-hosted OpenBao into process memory at pod startup. They never enter etcd, never appear in a Kubernetes Secret object, and the cloud provider never holds them.

Under a CLOUD Act subpoena or FISA 702 order, the provider has no plaintext credentials to hand over.

Yes. This is one of the most powerful patterns Phantom enables.

A Phantom-wrapped pod receives an encryption key from EU OpenBao directly into process memory. The pod encrypts data client-side using that key, then writes ciphertext to S3, GCS, or Azure Blob. The cloud provider stores the file but never had the key — not in KMS, not in Secrets Manager, not in etcd, not anywhere in their infrastructure.

This is stronger than SSE-KMS (where the cloud holds the key), stronger than SSE-C (where the cloud briefly processes the key server-side), and stronger than HYOK/XKS (where the cloud orchestrates the decryption). With client-side encryption + Phantom, the provider is just a dumb storage layer holding bytes it can’t read.

The same pattern works for any external service: encrypt in the pod with a Phantom-delivered key, send ciphertext to the destination. The key never leaves EU jurisdiction.

MVP targets GKE Standard. EKS and AKS support is Phase 2.

Mutating admission webhooks are a standard Kubernetes feature, so the mechanism works across distributions. The operational specifics differ by provider:

• GKE: Private cluster firewall rules for webhook traffic
• EKS: Fargate limitations (no DaemonSets); EC2 node groups work
• AKS: Admissions Enforcer behavior requires testing
• Self-managed: Works without provider-specific constraints

No. The webhook injects the sidecar automatically for any pod with the phantom: enabled label. Secrets arrive as environment variables or tmpfs-mounted files — the same interfaces applications already use.

There is an optional SDK for applications that want explicit control over secret fetching, but it is never required.

Phantom is architecturally similar to Vault Agent — it fetches secrets from a Vault-compatible backend and injects them into a process. The differences:

• Automatic injection via Kubernetes mutating webhook — no per-app configuration
• EU-hosted OpenBao backend specifically positioned for GDPR sovereignty
• Hardware attestation (AMD SEV-SNP, Intel TDX) — cryptographically proves the sidecar hasn’t been tampered with before keys are released
• SaaS dashboard with compliance-ready audit logs and sovereignty status reporting

Databases are fundamentally different from object storage. S3 is dumb storage — you put bytes in, get bytes out, so client-side encryption works perfectly. A managed database processes data — it needs to read your data to run WHERE, JOIN, ORDER BY. If the database can read the data, the cloud provider can read the data (they control the compute it runs on).

Phantom delivers the database credential from EU OpenBao — the provider can’t get it from etcd. But the data inside RDS / Cloud SQL / Azure Database is accessible to the provider through the database service itself.

Options, from strongest to most practical:

• Self-managed PostgreSQL on Kubernetes with Phantom-delivered credentials — full sovereignty, you control the database entirely
• Client-side field-level encryption — app encrypts sensitive columns before INSERT, decrypts after SELECT. Cloud sees ciphertext. But encrypted columns become unsearchable at the DB level (see question below)
• Deterministic encryption / blind indexes — partially restores equality searches on encrypted columns, but leaks frequency distribution
• Managed DB + Phantom credentials only — credential protected, data not. Still meaningful: prevents credential theft via etcd

Not automatically — but Phantom enables the pattern that does. Object storage itself is US-controlled. SSE-S3 and SSE-KMS encrypt at rest but decryption happens server-side inside US infrastructure.

The solution: client-side encryption with a Phantom-delivered key. Your application encrypts data before it ever leaves the pod, then writes ciphertext to S3/GCS. The cloud provider stores opaque bytes and never had the key. See “Can Phantom-wrapped workloads store data in S3/GCS that the cloud provider can’t read?” above for the full pattern.

This requires ~10–50 lines of application code per storage integration. Compatible with AWS Encryption SDK, GCP Tink, or any AES-256-GCM library.

Server-side encryption variants have different sovereignty implications:

• SSE-S3: AWS holds the encryption keys. CLOUD Act reaches them. Phantom does not help.
• SSE-KMS (AWS CMK): You created the key, but it lives in AWS KMS (US jurisdiction). Encryption and decryption happen inside AWS infrastructure. Phantom does not help.
• SSE-KMS (External Key Store / XKS): You host the key externally. Closer to the Phantom model, but the decryption still happens with AWS as the orchestrator — AWS controls the compute that uses the decrypted data. Not full sovereignty.
• SSE-C (Customer-Provided Keys): You supply the key per-request. S3 uses it server-side and claims to discard it. The plaintext object still exists briefly in AWS compute. Under a CLOUD Act order compelling real-time interception, this window exists. Partial protection.

Phantom can deliver SSE-C keys from EU OpenBao (removing them from etcd), which is a meaningful improvement. But for full sovereignty, client-side encryption is the answer — the provider never sees plaintext or the key during computation.

Without TEE: no. The cloud provider’s hypervisor can snapshot VM memory and read it.

Phantom mitigates this with:

• 15-minute TTL credentials — a memory dump yields secrets that expire quickly
• eBPF detection (Phase 2) — alerts on memory-reading syscalls

But detection is not prevention at the hypervisor level.

With TEE (Phantom Hardened): AMD SEV-SNP or Intel TDX provides hardware memory encryption. The hypervisor sees ciphertext. This is strong protection with a caveat: TEEs have had real vulnerabilities in 2025–2026 (CounterSEVeillance, TEE.Fail, StackWarp). They raise the bar significantly but are not absolute against nation-state actors with non-public exploits.

No. Kubernetes control plane metadata — pod names, namespace structure, resource consumption, replica counts — is visible to the cloud provider. They operate the control plane.

If metadata confidentiality is required, self-hosted Kubernetes on-premise or in a colocation facility is the only current solution.

Not in Phase 1. Network traffic between pods is not encrypted by Phantom’s core product.

Veilnet (inter-pod mTLS mesh) is a Phase 2 component. In the meantime, standard service mesh options (Istio, Linkerd, Cilium with WireGuard) provide in-cluster traffic encryption. Phantom delivers the certificates those services need from EU OpenBao.

Yes. Any cluster-admin with exec access to a running pod can access decrypted secrets in that pod’s memory or environment. This is a fundamental limitation of any in-process secret injection model — not unique to Phantom.

Mitigation: restrict RBAC exec permissions aggressively, audit all exec operations, and use the eBPF DaemonSet (Phase 2) to detect and alert on suspicious exec activity.

Recommendation: For regulated workloads (GDPR high-risk processing, financial data), run self-managed databases on Kubernetes with Phantom-delivered credentials. For operational simplicity where the data itself is less sensitive, SSE-C + Phantom key delivery is a meaningful improvement over the default.

This is where Phantom’s story is strongest. When you run your own database as a StatefulSet in Kubernetes — instead of using a managed service like RDS — every layer becomes protectable.

Popular K8s Database Operators

The full protection stack for a K8s database

1. Phantom delivers DB credentials from EU OpenBao → app pod connects to DB with credentials that never touched etcd
2. Phantom delivers TLS certificates → all client-to-DB and replica-to-replica traffic is encrypted with EU-controlled certs
3. Phantom delivers LUKS / encryption-at-rest key → PersistentVolumes contain only ciphertext; cloud provider’s block storage is opaque
4. Phantom delivers backup encryption key → backups written to S3/GCS are encrypted before upload
5. Phantom Hardened (optional) → TEE protects DB process memory from hypervisor access

Result: The US cloud provider provides VMs, network, and block storage. They hold zero credentials, zero keys, zero plaintext data. A CLOUD Act subpoena produces encrypted blocks and encrypted network captures. All SQL queries work normally — no searchability restrictions.

Three-step pattern for genuine storage sovereignty:

1. Phantom delivers your AES-256 encryption key from EU OpenBao to your application
2. Application encrypts data client-side before writing to S3/GCS/Azure Blob
3. Cloud provider stores ciphertext only — no key, no plaintext, nothing to hand over

Tools: AWS Encryption SDK, GCP Tink, any AES-256-GCM / AEAD implementation. The key never leaves EU jurisdiction. Application change required (typically 10–50 lines per storage integration).

This is genuine client-side encryption — not SSE. The provider never processes your key or plaintext at any point.

This architecture ensures that the US cloud provider handles compute and networking infrastructure, but holds no keys, no plaintext credentials, no unencrypted data, and no decryption capability.

Yes, with caveats.

With Phantom: the database password is protected from provider access, never in etcd, delivered from EU-hosted OpenBao. This is a genuine improvement — credential sovereignty is a real protection.

But the data in the RDS/Cloud SQL instance itself remains US-controlled. This is a partial posture.

It may be sufficient for your regulatory situation — many DPAs care most about access credentials and keys, and some workloads don’t store regulated personal data in the database. Document clearly in your Transfer Impact Assessment which protections apply and which don’t.

Don’t represent partial protection as full sovereignty.

Yes, you can encrypt it. Yes, it affects queries. Here’s the full picture:

Libraries: MongoDB Client-Side Field Level Encryption, CipherSweet (PHP/Node/Python), AWS Database Encryption SDK, or application-level AES-256-GCM per field. All keys delivered by Phantom from EU OpenBao.

Do managed PostgreSQL services (RDS, Cloud SQL, Azure Database) support this? They don’t need to — the encryption happens in your application, not in the database. The DB sees ciphertext in those columns and stores it like any other bytea or text value. This works with any managed PostgreSQL, MySQL, or any database that stores bytes.

Phantom addresses the Schrems II “supplementary technical measures” requirement for data transfers to the US. Specifically, it implements the EDPB’s recommended approach: encryption with customer-controlled keys that the data importer (US cloud provider) cannot access.

However:

• No EU DPA has issued a formal ruling that this specific architecture satisfies Schrems II — it is the strongest technical argument available but is legally untested
• GDPR compliance involves many more requirements beyond technical transfer safeguards (lawful basis, data minimization, subject rights, etc.)
• You should document Phantom’s protections in your Transfer Impact Assessment and seek guidance from your DPA or data protection counsel

The CLOUD Act (18 U.S.C. §2713) compels US providers to produce data “regardless of where such data is located.”

With Phantom: the provider can hand over your Kubernetes cluster data — but your secrets, credentials, and encryption keys are not there. They’re in EU-hosted OpenBao, outside US jurisdiction and outside the provider’s control. The provider has nothing of value to produce for the data Phantom protects.

For data in managed databases and object storage without client-side encryption — CLOUD Act exposure remains. This is why the full sovereignty stack includes client-side encryption for stored data.

FISA 702 allows US intelligence agencies to compel US providers to produce communications data — in secret, without notification to the data subject.

Phantom’s protection is the same principle: if the provider has no keys and no plaintext, the compelled production is ciphertext. For the secrets Phantom protects, this is strong protection.

For data in US-controlled storage or databases, the exposure depends on what is stored there and how it’s encrypted. Client-side encryption closes this gap.

No. AWS European Sovereign Cloud (launched January 2026) is operated by AWS, a US company, subject to US law. Data processed there remains subject to CLOUD Act and FISA 702.

The jurisdictional problem is legal, not geographic. EU data residency is not EU jurisdictional sovereignty.

CloudCondom/Phantom addresses the legal root cause: ensuring US-controlled entities never hold keys or plaintext, making compelled disclosure produce nothing useful — regardless of where the infrastructure is physically located.

No — and we will not claim otherwise.

The EDPB’s Recommendations 01/2020 on supplementary measures explicitly state that encryption is a valid supplementary measure provided “the keys remain under the data exporter’s control and are not accessible to the data importer or the authorities of the third country.”

Phantom’s architecture aligns with this principle. But no DPA has issued a formal opinion validating a specific product implementing this approach. This is a gap in the regulatory landscape, not a gap in our architecture.

Seek formal DPA guidance for your specific situation.

Your TIA should document:

• What Phantom protects: All credentials, secrets, and encryption keys are stored in EU-hosted OpenBao, never in the US cloud provider’s infrastructure (etcd, KMS, or Secret Manager)
• Key control: HSM-backed keys in EU jurisdiction, never accessible to the data importer
• Additional measures applied: Client-side encryption for stored data (if applicable), confidential VMs for memory protection (if applicable), service mesh for network encryption (if applicable)
• Residual risks: Workload metadata visible to provider, TEE side-channel risks (if using Hardened), and any data layers where client-side encryption has not been applied
• Honest limitations: No DPA formal validation. Approach aligns with EDPB guidance but is legally untested

Phantom implements three-tier caching:

1. Hot cache: In-memory cached secrets in the sidecar — instant, no network call
2. Sealed local cache: Encrypted on tmpfs — survives sidecar restart, opaque without cluster key from OpenBao
3. Grace period: Running pods continue operating with cached secrets during extended outages

New pods cannot start until vault is reachable — they fail explicitly with a clear error, not silently. There is no data loss. The design philosophy: fail loud, never fail open.

Two options:

• Managed SaaS: CloudCondom operates EU-hosted OpenBao on your behalf. You hold the HSM-backed unseal keys and master encryption keys — CloudCondom operates the infrastructure but cannot decrypt your secrets
• Self-hosted: You run OpenBao on your own EU infrastructure, pointed at by the Phantom webhook configuration. Full control, full operational responsibility

Kubernetes service account tokens (OIDC-federated) plus optional hardware attestation.

The sidecar presents the pod’s service account JWT to OpenBao. OpenBao verifies the token against the cluster’s OIDC issuer. Access is scoped to namespace and service account — a compromised pod in namespace A cannot access namespace B’s secrets.

With Phantom Hardened (TEE enabled): AMD SEV-SNP or Intel TDX attestation is added. OpenBao verifies a hardware-signed quote proving the sidecar is running unmodified code in a genuine confidential VM before releasing secrets.

Running pods are unaffected — secrets are already in their memory.

New pods will not have the sidecar injected, but this is immediately visible (pods start without Phantom protection). The Phantom operator runs a reconciliation loop that restores the webhook within seconds of deletion.

The eBPF DaemonSet (Phase 2) detects webhook deletion and fires an audit alert. An attacker deleting the webhook does not gain access to existing secrets — it only affects new pod startups, and only briefly.

No. Phantom Standard runs on any Kubernetes node, no special instance type required.

Phantom Hardened (optional upgrade) adds TEE support:

• Standard: Credential sovereignty — secrets never in etcd, provider can’t read etcd to get them. But hypervisor can theoretically read process memory.
• Hardened: Adds hardware memory encryption — hypervisor sees ciphertext. Requires AMD SEV-SNP or Intel TDX capable instances.

Cost premium for confidential VMs: typically 5–20% above standard instance pricing.

The phantom-proxy sidecar uses approximately 50MB of memory per pod. At scale:

• 100 pods: ~5GB total sidecar overhead
• 1,000 pods: ~50GB total sidecar overhead
• 10,000 pods: ~500GB — at this scale, a DaemonSet mode (one agent per node instead of per pod) is recommended. This is planned for Phase 2.

CPU overhead is minimal — the sidecar is mostly idle after initial secret fetch, waking only for TTL renewal.

• Helm install: 10–15 minutes for a functioning cluster
• Full configuration: Secret policies, namespace scoping, audit log routing — 1–2 days
• Enterprise onboarding: Security review, compliance mapping, production hardening — 1–2 weeks

No application changes required — the webhook injects automatically for labeled pods.

Open-core. The webhook, sidecar, and Phantom operator are open-source.

Pricing is for managed EU-hosted OpenBao SaaS: approximately $50–150 per node per month depending on tier (Standard vs. Hardened) and scale.

Enterprise pricing includes SLA guarantees, compliance reporting dashboard, dedicated support, and audit log export. Contact for enterprise pricing.

GKE Standard first, with AMD SEV-SNP attestation.

v1 includes:

• Mutating webhook + sidecar
• OpenBao secrets injection (env vars + tmpfs)
• Three-tier caching + circuit breaker
• Hardware attestation on GKE
• Prometheus metrics
• Helm chart + documentation

Phase 2: EKS + AKS support, eBPF DaemonSet, SaaS dashboard, Veilnet (network encryption), DaemonSet mode for high-density clusters.

Yes. Phantom is designed for low-friction evaluation:

• Install the Helm chart in a test namespace
• Label one pod with phantom: enabled
• Observe: the pod starts with secrets from OpenBao, kubectl get secrets in the namespace shows nothing
• Verify: kubectl exec into the pod to confirm secrets are available as environment variables

PoC can run alongside existing secret management with zero disruption to production workloads.