Cisco released DefenseClaw last week and the timing is not a coincidence. It landed at RSA Conference 2026 alongside a Talos report documenting how quickly the OpenClaw ecosystem became a supply chain attack surface — 800 malicious skills in weeks, a critical RCE vulnerability (CVE-2026–25253), coordinated injection campaigns. The message was clear: the fastest-growing open-source AI project in history needed a security governance layer, and Cisco built one.

This document is about what that composition looks like, and why it matters for anyone running OpenClaw in a context where real data is involved.

None

The combined stack

OpenObscure and DefenseClaw operate at orthogonal layers — one governs what data the model sees, the other governs what components are allowed to run.

None
Deployment Architecture
None
Deployment stack

What DefenseClaw actually does

DefenseClaw is the governance layer for the OpenClaw ecosystem. Before you can even install a skill, it runs the component through five scanners: skill-scanner, mcp-scanner, a2a-scanner, CodeGuard static analysis, and an AI bill-of-materials generator. HIGH/CRITICAL findings auto-block. MEDIUM/LOW install with a warning. Everything is logged to an audit store and streamed to Splunk.

At runtime, DefenseClaw hooks into OpenClaw via the before_tool_call interface. Every tool call the agent makes is inspected. Block decisions are enforced in under two seconds, no restart required. When you block a skill, its sandbox permissions are revoked and its files are quarantined. When you block an MCP server, it's removed from OpenShell's network allow-list.

This is exactly the right architecture for the supply chain threat. It's zero-trust applied to agentic components: nothing runs until it's verified, and enforcement is hard rather than advisory.

The threat model DefenseClaw wasn't designed to solve

Here's a scenario that DefenseClaw handles perfectly: a malicious skill with a hardcoded credential tries to exfiltrate conversation history to an attacker-controlled endpoint. DefenseClaw's CodeGuard scanner detects the hardcoded credential during the admission scan. The skill is blocked before it ever runs.

Here's a scenario that falls outside DefenseClaw's scope: a user pastes their medical record number, home address, and date of birth into an OpenClaw prompt. The skill that processes the prompt is completely clean — it passed all five scanners, it has no malicious code, it behaves exactly as documented. It forwards the prompt to a cloud LLM. The LLM generates a response. The data is now at a cloud inference provider.

No violation occurred at the security layer. The supply chain was intact. The data leak happened at the content layer, and it was entirely user-initiated. This is the threat model OpenObscure was designed for.

What OpenObscure does

OpenObscure is an on-device privacy firewall that intercepts AI agent requests before they reach the inference engine. It uses two complementary mechanisms depending on the PII type.

For structured data — SSNs, credit card numbers, account numbers, phone numbers — it applies FF1 format-preserving encryption (NIST SP 800–38G). The output is indistinguishable in format from the real value: 123-45-6789 encrypts to 847-23-9156. A valid-looking SSN reaches the model; the actual identity does not. Reversal requires the encryption key, which never leaves the device.

For unstructured PII — names, addresses, free-form identifying text — it uses NER-based tokenization: entities detected by TinyBERT-4L-312D INT8 (with CRF fallback) are replaced with labeled placeholders. John Smith becomes [PERSON-a3f1]. The semantic role is preserved for model reasoning; the identity is not.

None

The structured identifiers are format-preserved and cryptographically protected; the name is tokenized. The model receives a prompt it can reason about — relationships, roles, and data types are intact — but no real values are present.

When the model responds, privacy tokens in the output are mapped back to original values locally. The user sees a coherent, correctly-attributed response. The cloud inference provider saw only encrypted and pseudonymized data.

Image PII is handled by a separate pipeline: BlazeFace for face detection, PaddleOCR for text in images, and a ViT classifier for NSFW content. The entire stack runs within a 275 MB RAM / 70 MB storage budget — designed to work on mobile and constrained on-device deployments. OpenObscure integrates with OpenClaw, Ollama, OpenRouter, Enchanted on iOS, and RikkaHub on Android.

How they differ

The two projects share an ecosystem but address entirely distinct threat surfaces. Neither is a substitute for the other.

None
Comparison

Why stack both

Each layer has a blind spot the other fills.

None
Defense in depth
None

Why this matters more than it might seem

None

That fear is real, and it's not fully addressed by supply chain security alone. The exposure isn't just malicious skills. It's the ordinary fact that agentic AI systems, by design, ingest personal context at a scale and intimacy that nothing before them has. Calendar data. Medical history. Financial information. Family schedules. That data is the point — it's what makes the agent useful. And it's also exactly what makes the privacy threat fundamentally different from a traditional application security problem.

DefenseClaw secures the agent. OpenObscure secures the data flowing through the agent. For anyone using OpenClaw with real personal or organizational data — and Sampath's home use case is exactly that — both layers matter.

EU AI Act considerations

OpenObscure includes an explicit EU AI Act Article 5 cognitive firewall layer. DefenseClaw's current architecture and framing is U.S.-enterprise-SOC-centric — Splunk telemetry, Duo IAM, NVIDIA DGX-class infrastructure targets.

For organizations subject to GDPR and the EU AI Act, the combined stack addresses both the governance layer (DefenseClaw handles zero-trust agent identity and supply chain requirements) and the data protection layer (OpenObscure handles PII minimization and data subject rights requirements). These are legally distinct obligations that currently require distinct technical solutions.

Getting started

Both projects are open-source and available now.

Privacy layer: openobscure.ai

Architecture, deployment guide, integration docs

Security layer: github.com/cisco-ai-defense/defenseclaw