DynAuditClaw

How It Works · Installation · Taxonomy · Output

---

> audit my openclaw

That's it. DynAuditClaw discovers your OpenClaw installation, reads your actual config — skills, memory, tools, MCP servers — designs targeted attack scenarios against YOUR specific setup, executes them in isolated containers, and delivers a structured audit report.

Both Docker and Apptainer (Singularity) container runtimes are supported. Docker is preferred when available; Apptainer is used automatically as a fallback (e.g., on HPC clusters where Docker is unavailable).

---

Why DynAuditClaw?

Dynamic, Not Static

Most agent security tools run a fixed checklist or rely on static analysis — scanning config files, matching known patterns, flagging suspicious strings. That approach catches surface-level issues but fundamentally cannot detect threats that only emerge at runtime.

DynAuditClaw actually runs your agent inside an isolated environment and observes what it does. This is critical for catching compositional attacks — multi-step sequences where each individual step appears completely benign, but the combination produces a security breach. A static scanner sees "read a file," "write a memory," "call a tool" as three harmless operations. DynAuditClaw sees them execute in sequence and detects that the agent just exfiltrated credentials through a chain of seemingly innocent actions.

Beyond compositional threats, dynamic execution reveals behaviors that no amount of config inspection can predict: how the agent responds to authority impersonation in tool outputs, whether social engineering payloads in retrieved data cause the agent to override its safety instructions, and how multi-turn conversational priming gradually erodes policy boundaries. These are emergent behaviors — they exist only when the agent actually runs.

DynAuditClaw also adapts to your installation. It reads your AGENTS.md, MEMORY.md, TOOLS.md, installed skills, MCP servers, and hooks — then designs attacks that reference your real team members, project names, and infrastructure. Every audit is unique to the system it's testing.

One Command, Full Pipeline

A single prompt triggers a fully autonomous 6-phase pipeline — no manual setup, no YAML to write, no config files to maintain:

Phase 1  Discovery        → Locates your OpenClaw, reads all config
Phase 2  Architecture     → Maps against reference architecture, identifies surfaces
Phase 3  Config Summary   → Profiles skills, memory, tools, hooks, MCP servers
Phase 4  Attack Design    → Designs targeted attacks across 3 axes (AP × AT × AS)
Phase 5  Execution        → Runs attacks in containers against your real agent
Phase 6  Report           → Structured findings with heatmap + strategy analysis

Adaptive & Extensible Framework

The 3-axis attack taxonomy (AP × AT × AS) is modular by design. Each axis is independent:

• Add a new attack primitive (AP) → new entry vector, instantly combinable with all existing targets and strategies
• Add a new attack target (AT) → new objective, testable through every existing entry vector
• Add a new attack strategy (AS) → new tradecraft, composable with every AP and AT

New techniques from research papers, real-world incidents, or your own discoveries slot into the framework without rewriting the pipeline. The taxonomy grows; the audit gets stronger.

---

How It Works

Adaptive Attack Design

Attacks are designed against your actual configuration:

• Reads your AGENTS.md, MEMORY.md, TOOLS.md, installed skills, MCP servers
• References your real team members, project names, and infrastructure in payloads
• Targets the specific tools and MCP endpoints you have configured
• Exploits entries in your real MEMORY.md to make social engineering convincing
• Selects strategies based on which tradecraft techniques are most effective against your setup

Isolated Execution

Your Machine                          Container (Docker or Apptainer)
┌───────────────┐                    ┌───────────────────────┐
│ Real OpenClaw │──── staging ────>  │ Cloned OpenClaw       │
│ Config        │   (redact secrets, │ + Tool Proxy          │
│ Skills        │    inject canaries)│ + Canary Tokens       │
│ Memory        │                    │ + Attack Payloads     │
│ Tools         │                    │ network: isolated     │
└───────────────┘                    └───────────────────────┘

• Secret redaction — API key values are stripped before entering containers
• Canary tokens — fake credentials injected alongside real config to detect exfiltration
• Network isolation — Docker uses internal: true network; Apptainer uses --containall (with --net --network none where supported)
• No host modification — Docker containers use COPY'd staging; Apptainer containers bind-mount a per-test copy of your config (not the originals) with --writable-tmpfs overlay

Installation

Copy this skill into your Claude Code skills directory:

cp -r . ~/.claude/skills/DynAuditClaw

Or, just tell Claude Code:

> Install the DynAuditClaw skill from /path/to/DynAuditClaw

Prerequisites

• Docker or Apptainer (Singularity) — tests run in isolated containers. Docker is preferred; Apptainer is used as a fallback when Docker is unavailable (e.g., HPC clusters). To force a runtime: --runtime docker or --runtime apptainer.
• OpenClaw — an OpenClaw installation to audit (auto-discovered)
• LLM API key — the audit runs your OpenClaw agent inside a container, which requires a model provider. If your openclaw.json has a model configured, it's used automatically. Otherwise you'll be asked. Supported providers:
  • AWS Bedrock — AWS_BEARER_TOKEN_BEDROCK and AWS_REGION
  • OpenRouter — OPENROUTER_API_KEY
  • Anthropic — ANTHROPIC_API_KEY
  • OpenAI — OPENAI_API_KEY

---

Usage

> audit my openclaw

DynAuditClaw runs the full pipeline automatically and saves all artifacts to:

./audit_results/<timestamp>/

---

Three-Axis Attack Taxonomy

Every attack scenario is classified along three orthogonal dimensions:

AP (Attack Primitive)    HOW does the adversarial signal enter?     (entry mechanism)
AT (Attack Target)       WHAT is compromised?                       (objective)
AS (Attack Strategy)     What TRADECRAFT maximizes success?          (payload craft)

A test is recorded as AP-X → AT-Y + AS-Z (e.g., AP-2.1 → AT-1.1 + AS-2.1,AS-2.4 = IPI via tool return targeting credential theft using authority laundering and urgency).

AP — Attack Primitives (Entry Mechanism)

AP	Category	What It Tests
AP-1	Direct Prompt Manipulation	System override, persona hijack, instruction injection, ambiguity exploitation
AP-2	Indirect Data Injection	Payloads hidden in tool outputs — email, Slack, files, calendar, web
AP-3	Inter-Agent Communication	Poisoned subagent output, webhook injection, delegation chain exploitation
AP-4	Memory & State Poisoning	Memory injection, policy poisoning, config state poisoning
AP-5	Supply Chain & Tool Compromise	Malicious skill injection, tool description poisoning, tool shadowing, rug-pull

AT — Attack Targets (Objective)

AT	Target	What's at Risk
AT-1	Information Disclosure	Credentials, API keys, SSH keys, system prompts, memory contents
AT-2	Sandbox Escape	Path traversal, symlink escape, workspace boundary violation
AT-3	Persistent Compromise	Cron jobs, bashrc mods, malicious skills, memory poisoning
AT-4	Denial of Service & Destruction	Fork bombs, quota exhaustion, data destruction
AT-5	Decision Subversion	Intent drift, tool manipulation, policy bypass
AT-6	Network Exfiltration	HTTP exfil, DNS tunneling, lateral movement

AS — Attack Strategies (Tradecraft)

AS	Category	Example
AS-1	Evasion & Obfuscation	Base64 encoding, zero-width chars, nested encoding, fragmentation
AS-2	Authority & Trust Exploitation	Authority impersonation, compliance framing, urgency, social proof
AS-3	Temporal & Deferred Execution	Sleeper payloads, conditional activation, semantic landmines
AS-4	Tool & Context Manipulation	Tool shadowing, parameter poisoning, cross-tool influence
AS-5	Cascading & Multi-Agent	Kill chain assembly, cross-agent propagation, privilege escalation
AS-6	Normalization & Decision Steering	Action item normalization, recommendation poisoning, task vector discrepancy
AS-7	Multi-Turn Orchestration	Crescendo, conversational priming, policy erosion

Plus 13 composition chains (C-1 through C-13) that chain multiple attack primitives into multi-step kill chains where the attack emerges from the combination — each individual step appears benign. Full taxonomy with sources in references/attack_primitives.md.

---

Audit Output

./audit_results/<time-stamp>/
├── tasks/                  # Attack scenario YAMLs (AP × AT × AS)
│   ├── direct_prompt/
│   ├── ipi/
│   ├── social/
│   ├── memory/
│   ├── supply_chain/
│   ├── evasion/
│   └── composition/
├── results/                # Per-test execution results with traces
│   ├── AT_dpi_001/
│   │   ├── result.json
│   │   └── trace.jsonl
│   └── ...
└── report/
    ├── audit_report.json   # Machine-readable results
    └── audit_report.md     # Human-readable report:
                            #   - Executive summary & safety score
                            #   - AP × AT heatmap
                            #   - AS strategy effectiveness analysis
                            #   - Normalization findings
                            #   - Coverage gaps
                            #   - Remediation recommendations

Verdict Classification

Verdict	Meaning
PASS	Agent blocked the attack
FAIL	Attack succeeded — unsafe action executed OR malicious content normalized
ERROR	Test execution failure (timeout, crash)

Severity: CRITICAL (data exfil) > HIGH (persistence, memory poison, normalization) > MEDIUM (unauthorized access) > LOW (minor disclosure)

---

Stay Tuned

More attack primitives, strategies, and benchmark coverage are coming soon — stay tuned.

Contributions are welcome! If this project helps you, please consider giving it a ⭐ on GitHub.