Your OpenClaw Agent Remembers Everything. So Would an Attacker.
OpenClaw has crossed 180,000 GitHub stars in weeks. Developers are wiring it into WhatsApp, Slack, email, calendars, and shell access — building the personal AI assistant we've all wanted. Cisco called it "groundbreaking from a capability perspective" and "an absolute nightmare from a security perspective." CrowdStrike is hosting emergency briefings. The Register called it a "security dumpster fire."
But most of the coverage is focused on the obvious risks: prompt injection, exposed API keys, malicious skills on ClawHub. Those are real problems, and they're getting patched.
There's a deeper problem that nobody's patching, because it's not a bug. It's the architecture.
OpenClaw's Memory Is Built on Plaintext Embeddings
OpenClaw's persistent memory — the feature that makes it feel like a genuine assistant instead of a stateless chatbot — works by converting your conversations, preferences, documents, and session history into vector embeddings. These embeddings are stored in SQLite via the sqlite-vec extension, sitting at ~/.openclaw/memory/<agentId>.sqlite.
Here's the schema, straight from the codebase:
CREATE TABLE IF NOT EXISTS chunks (
id TEXT PRIMARY KEY,
path TEXT NOT NULL,
text TEXT NOT NULL,
embedding TEXT NOT NULL,
updated_at INTEGER NOT NULL
);
That embedding TEXT NOT NULL column? It's a plaintext vector representation of your data. Every conversation, every preference, every document your agent has processed — encoded into dense numerical vectors and stored unencrypted on disk.
This isn't unique to OpenClaw. It's how every vector database and embedding store works by default: Pinecone, Milvus, Weaviate, Chroma, pgvector — all of them store and query embeddings in plaintext. OpenClaw just makes the risk personal, because the data is yours.
Why Plaintext Embeddings Are a Problem
There's a common misconception that embeddings are "just numbers" and therefore safe. They're not. Embedding inversion attacks use machine learning to reconstruct the original text from vector representations with high fidelity.
At the Confidential Computing Summit in June 2025, Cyborg demonstrated this attack against a production-like vector database containing synthetic sensitive data. The result: 99.38% successful reconstruction of original documents in under 5 minutes from initial access to full data recovery.
The attack chain is straightforward:
- Access the database — in OpenClaw's case, it's a local SQLite file with default permissions
- Extract the plaintext embeddings — no decryption step needed, they're stored as-is
- Run inversion models — gradient optimization or transformer-based techniques reconstruct the original content
- Correlate across sources — because OpenClaw aggregates data from email, chat, documents, and browsing, the attacker builds a complete intelligence profile
This isn't theoretical. CVE-2026-25253 (CVSS 8.8) demonstrated one-click remote code execution against OpenClaw instances. Researchers at Snyk found 7.1% of ClawHub skills (283 out of nearly 4,000) leak sensitive credentials. Zenity demonstrated how an attacker could backdoor an OpenClaw instance via a Google Doc, then exfiltrate files through a Telegram bot.
Once an attacker has access to the host, the embedding database is the highest-value target. It's a semantic index of everything the agent knows about you.
The Architectural Root Cause
OpenClaw's documentation is admirably honest about this: "There is no 'perfectly secure' setup." But the issue extends far beyond OpenClaw.
Every AI system that uses vector search — whether it's a personal agent running locally or an enterprise RAG pipeline serving thousands of users — faces the same fundamental problem. Vector databases must perform mathematical operations (cosine similarity, dot products) on embeddings to return search results. Traditional databases require those embeddings to be in plaintext to do the math.
This creates a structural vulnerability: the data that makes your AI useful is the same data that's exploitable when accessed by an attacker. Encrypting at rest doesn't help, because the database decrypts everything into memory to run queries. Encrypting in transit doesn't help, because the exposure happens at the storage and compute layer.
The security community is focused on OpenClaw's application-layer vulnerabilities — prompt injection, exposed ports, malicious skills. Those are important. But they're symptoms of a larger issue: any system that centralizes semantic intelligence into plaintext embeddings creates a single point of compromise that traditional security controls can't protect.
What Encryption-in-Use Changes
CyborgDB takes a fundamentally different approach. Instead of storing plaintext embeddings and hoping your perimeter holds, CyborgDB performs vector search operations directly on encrypted data. Embeddings are encrypted with AES-256-GCM before storage, and they stay encrypted during query operations.
This means that even if an attacker gains full access to the database — disk, memory, backups, snapshots — they get ciphertext. Inversion attacks require plaintext vectors as input. Encrypted embeddings are mathematically non-invertible without the encryption keys.
The practical impact for developers building with AI agents:
Forward-secure indexing prevents attackers from reconstructing embeddings even if they observe query patterns over time. This directly addresses the pattern analysis attacks that OpenClaw's architecture is vulnerable to.
Customer-controlled key management (BYOK/HYOK) means the encryption keys never leave your control. Not the database vendor, not the cloud provider — you hold the keys. For personal AI agents, this is the difference between trusting a file on disk and trusting cryptography.
No application rewrites required. CyborgDB works as infrastructure between your application and your existing database. If you're already using Postgres or Redis as a backing store, the integration path doesn't require rebuilding your data layer.
What This Means if You're Experimenting with OpenClaw
If you're running OpenClaw at home to learn how AI agents work — and based on 180,000+ GitHub stars, many of you are — here's what to think about:
Your agent's memory is a plaintext semantic index of your life. Every conversation, every document it's processed, every preference it's learned is encoded in vectors that can be reconstructed into readable text. Today that SQLite file sits on your laptop. Tomorrow, when you bring these patterns into production at your company, the same architectural choice scales to become an enterprise-wide intelligence target.
The skills you're building now — RAG pipelines, persistent memory, semantic search — are the same skills enterprises need. The security model needs to scale with them.
OpenClaw is a remarkable tool for understanding what agentic AI can do. The question isn't whether to build with AI agents. It's whether the infrastructure underneath them is designed to protect the data that makes them useful.
Go Deeper
CyborgDB's security architecture is designed specifically for this problem. Read the full security overview — including threat models, attack mechanics, and encryption specifications — at docs.cyborg.co/versions/v0.14.x/intro/security-overview.
