Skip to main content

ClawGuard AI Agent Security Ecosystem

Executive Summary — CTO / VP Engineering Decision Brief​

Date: 2026-02-18 Prepared by: CODITECT Research Pipeline (Artifact 3 of 5) Decision Required: Adopt, adapt, or pass on open-source AI agent security tooling for CODITECT's 776-agent platform

1. Problem Statement​

CODITECT operates a 776-agent system in which individual agents invoke tools, read filesystem paths, execute shell commands, call external APIs, and pass outputs downstream to other agents. Each of those operations is a potential attack surface.

The threat model is not theoretical:

  • A prompt injection attack embedded in a document, email, or tool result can redirect an agent's behavior mid-session — causing it to exfiltrate credentials, delete data, or manipulate downstream agents.
  • A malicious skill installed from a third-party source can behave correctly during review and activate a payload on trigger conditions.
  • Credential exposure through tool outputs — API keys, JWT tokens, cloud credentials — can persist in session logs and context databases unredacted.
  • Destructive command execution (rm -rf, DROP TABLE, git reset --hard) requires no special privileges when an agent already has filesystem or database access.

This is not a future concern. The research itself surfaced a live example: one of the five repositories evaluated was a trojanized fork containing an injected binary designed to be downloaded and executed. The ClawGuard ecosystem exists precisely because this class of attack is active in the wild and the existing Claude / OpenClaw agent ecosystems lack native prevention controls.

CODITECT's 118-hook framework and JSONL session log infrastructure provide the architectural anchors for a security layer. The question is whether existing open-source tooling accelerates that build or introduces its own risk.

2. Solution Overview — Repositories Evaluated​

Five repositories were identified in the ClawGuard ecosystem. Two were eliminated before substantive analysis.

2.1 Eliminated Repositories​

RepoReason for Elimination
lauty1505/clawguardMALWARE. Trojanized fork of JaydenBeard's repo. Contains injected Software-tannin.zip binary. README rewritten to social-engineer downloads. Classic fork-and-trojanize supply chain attack. Never execute. Never push. Removed from submodules.
yourclaw/clawguardNo functional code. Planning-only repository with README scaffolding. Not evaluatable.

The malware finding is itself a data point: the attack vector this tooling is designed to prevent (supply chain injection via trusted-looking packages) is actively being used against the tooling's own ecosystem.

2.2 Repositories Retained for Analysis​

ClawGuardian (superglue-ai) — Score: 85/100 — HIGHEST VALUE

A TypeScript plugin for the OpenClaw agent framework. Architecture is hook-based: three lifecycle intercept points (before_agent_start, before_tool_call, tool_result_persist) map directly onto the CODITECT hook execution model. Security actions are severity-tiered: block, redact, confirm, agent-confirm, warn, log. Pattern modules cover API keys, cloud credentials, tokens, and PII (via libphonenumber-js). Destructive command detection covers rm -rf, sudo, DROP TABLE, disk format operations.

Strengths: 45,205 lines of vitest tests. Strict TypeScript throughout. Stateless plugin design — state management delegated to host framework. Severity-action routing is the most sophisticated of the three tools.

Critical constraint: Peer dependency on openclaw >=2026.1.0. Cannot be installed directly into CODITECT without adaptation. The plugin manifest and hook registration mechanism are OpenClaw-specific. Integration requires porting, not installing.

clawguard (JaydenBeard) — Score: 78/100 — HIGH VALUE

A Node.js real-time monitoring dashboard that watches JSONL session log files via chokidar and classifies activity against 55+ risk patterns across five severity tiers. Supports multi-gateway monitoring (OpenClaw, MoltBot, ClawdBot). Includes a kill switch, emergency controls, and webhook alerting to Discord, Slack, and Telegram.

Strengths: The most comprehensive risk pattern library of the three tools. Sensitive path monitoring covers .ssh, .aws, .kube, .env, password manager directories, and cloud configuration files. Webhook alerting is operationally valuable. Real-time WebSocket dashboard enables live session visibility. Kill switch provides emergency stop capability.

Weaknesses: Vanilla JavaScript with no TypeScript types. Zero tests observed. No type safety means the pattern library cannot be statically validated. Pulling this repo as a dependency introduces maintenance risk disproportionate to the value — the pattern library is the asset, not the runtime.

The JSONL format this tool parses is the same format CODITECT's session logs already produce. This is the strongest alignment point in the entire ecosystem.

ClawGuard (maxxie114) — Score: 65/100 — MEDIUM VALUE

A Python/FastAPI server for email sanitization with Gmail Pub/Sub integration. Provides risk scoring (0–100 aggregate) across 10 prompt injection patterns and 6 secret detection patterns. REST API with HMAC webhook verification, Bearer token auth, and SQLite-backed event storage.

Strengths: Well-structured Pydantic models. HMAC verification for webhook integrity. Risk aggregation scoring is a reusable design pattern for input validation pipelines.

Limitations: Scope is email-only. Requires GCP credentials for Gmail integration. The 10-pattern prompt injection library and 6-pattern secret detection library are less comprehensive than ClawGuardian and JaydenBeard's pattern sets. Not applicable to agent tool calls, system prompts, or shell execution — the highest-risk surfaces in CODITECT's context.

3. Fit for CODITECT Architecture​

CODITECT already has three structural components that align with this tooling:

3.1 Hook System (118 Hooks) — Maps to ClawGuardian​

CODITECT's PreToolUse, PostToolUse, PreAgentStart, and equivalent hook types correspond directly to ClawGuardian's three lifecycle intercept points. The hook execution pipeline is where security gates belong — before a tool call executes, not after. ClawGuardian's architecture validates this placement.

The action model (block, redact, confirm, warn, log) maps cleanly onto what CODITECT hooks already support: hooks can halt execution, modify inputs, trigger confirmation dialogs, and write to session logs. The gap is not architectural — it is the absence of security-specific pattern evaluation within those hooks.

3.2 Session Logs (JSONL) — Maps to JaydenBeard​

CODITECT session logs are already JSONL. JaydenBeard's monitoring dashboard parses that format natively. This means the risk pattern library can be applied to CODITECT session data with minimal format translation. The 55+ pattern library — covering shell execution, sensitive path access, cloud CLI invocations, camera/microphone access, persistence mechanism installation, and privileged container operations — directly addresses CODITECT's threat surface.

The dashboard and kill switch components are operationally attractive but secondary. The pattern library is the extractable asset.

3.3 Input Validation Pipeline — Maps to maxxie114​

Agents receive inputs from multiple surfaces: user prompts, tool results, document content, email bodies, API responses. maxxie114's sanitization patterns (10 prompt injection variants + 6 secret patterns) and its risk-score aggregation approach provide a reference implementation for input-layer validation. The architecture — score each pattern, aggregate, threshold-route — is reusable independent of the email-specific transport layer.

3.4 Gap: No Existing CODITECT Security Layer​

None of CODITECT's 118 hooks currently perform security evaluation. The task_id_validator.py and task-tracking-enforcer.py governance hooks demonstrate that hooks can intercept and conditionally block tool calls — but they govern process compliance, not security threat detection. A security layer requires its own hook implementations with a pattern evaluation engine behind them.

4. Risks and Unknowns​

4.1 Dependency Risk — ClawGuardian​

ClawGuardian's openclaw >=2026.1.0 peer dependency is non-trivial. The plugin registration mechanism, hook invocation protocol, and action return types are all OpenClaw-specific. Adapting ClawGuardian for CODITECT means reimplementing the plugin harness, not just importing the patterns. Estimated adaptation scope: 2–4 weeks for a complete port, assuming one engineer familiar with both CODITECT's hook system and TypeScript.

The alternative — reading ClawGuardian as a reference architecture rather than a dependency — eliminates the port risk entirely and preserves the pattern library and action model as design inputs.

4.2 Type Safety Risk — JaydenBeard​

JaydenBeard's risk pattern library is the most valuable artifact in the ecosystem. It is also in vanilla JavaScript with no types and no tests. Pulling it as a runtime dependency would mean trusting unvalidated pattern matching logic against production security decisions. The correct path is to extract, translate, and test the patterns in a CODITECT-native implementation — not to import the runtime.

4.3 Pattern Freshness Risk — All Three Repos​

All three tools define their threat patterns as static lists. Attack vectors evolve: new encoding evasion techniques, new credential formats, new destructive command variants. A static pattern library deployed without a maintenance process becomes stale within months. CODITECT would need a defined process for pattern library updates — either a versioned internal registry or a monitored upstream source.

4.4 Supply Chain Risk — Demonstrated, Not Theoretical​

The lauty1505 finding is directly relevant to the decision at hand. The ClawGuard ecosystem attracted a trojanized fork because "security tooling" is a high-trust category — developers are less likely to scrutinize code that presents itself as a protection mechanism. CODITECT should apply the same scrutiny to the three retained repos before incorporating any code. All three are MIT-licensed; code review is the appropriate gate, not license review alone.

4.5 Coverage Gaps — Not a Complete Solution​

Even if all three tools' patterns were integrated, they would not constitute a complete security posture. Missing coverage includes: agent-to-agent message integrity validation, context database tamper detection, privilege escalation through chained tool calls, and runtime behavior baselining. This tooling addresses the detection and prevention layer at individual interaction points — it does not address the broader agent orchestration security model.

5. Recommendation​

CONDITIONAL GO — Adopt patterns and architecture; build CODITECT-native implementation.

Do not pull any of the three repositories as runtime dependencies. Do not fork and deploy JaydenBeard or ClawGuardian directly. The adaptation cost and type-safety gaps make wholesale adoption higher risk than building from reference.

The correct use of this research is as validated design input for a CODITECT Security Layer — a new component in the hooks system that provides security gate evaluation at agent lifecycle events.

Phase 1 — Pattern Library (2–3 weeks)

Extract and translate JaydenBeard's 55+ risk patterns into a versioned, typed pattern registry. Supplement with ClawGuardian's API key, cloud credential, and PII patterns, and maxxie114's prompt injection and secret patterns. Implement in TypeScript (or Python, matching the hook host language) with full test coverage against known attack samples. Store patterns as a versioned JSON schema with a defined update process.

Phase 2 — Hook Security Gates (2–3 weeks)

Implement PreToolUse security evaluation hooks using ClawGuardian's action model: evaluate input against the pattern library, route to block, redact, confirm, or log based on severity. Target the three highest-risk hook points first: tool call inputs, system prompt modifications, shell command execution. Map directly onto CODITECT's existing hook invocation protocol.

Phase 3 — Session Log Monitoring (1–2 weeks)

Port JaydenBeard's JSONL parser and risk analyzer against CODITECT's session log format. Implement as a background service (not a dashboard dependency) that streams alerts to the existing webhook infrastructure. Add kill switch capability as an emergency stop hook that halts agent execution on critical risk detection.

Phase 4 — Input Sanitization Pipeline (1 week)

Incorporate maxxie114's risk-score aggregation model into the input validation layer for user-facing prompt entry points. Risk score thresholds should be configurable per agent class — a documentation agent and a filesystem agent carry different risk profiles.

Decision Factors​

FactorFor AdoptionAgainst Adoption
Architectural alignmentHook model matches CODITECT exactlyRepos are OpenClaw-native, not CODITECT-native
Pattern library value55+ validated patterns, 3 independent sourcesStatic patterns require ongoing maintenance
Build costReference design reduces design timeFull port is 6–9 weeks of engineering effort
RiskSupply chain risk is demonstrated and manageableJaydenBeard has no type safety or tests
Urgency776 agents with no security layer is the current stateMarch 11 public launch timeline is constrained

The tradeoff is between build quality and speed. Pulling these repos as dependencies is faster but introduces maintenance debt and type-safety risk in security-critical code. Building CODITECT-native implementations from these reference architectures takes longer but produces a maintainable, tested, properly typed security layer that does not inherit the upstream repos' quality gaps.

Given the March 11 public launch timeline, a phased approach is practical: implement Phase 1 (pattern library) and Phase 2 (PreToolUse hooks) before launch as a foundation, with Phase 3 and Phase 4 completing in the first post-launch sprint.

What This Does Not Resolve​

This recommendation covers detection and prevention at individual interaction points. It does not address: agent-to-agent trust boundaries, context database integrity, long-running session hijacking, or privilege escalation through chained tool calls. Those require a separate architectural decision beyond the scope of this ecosystem evaluation.

Appendix A — Repository Quick Reference​

RepoLanguageScoreLicenseTestsPrimary Value
ClawGuardian (superglue-ai)TypeScript85/100MIT45,205 linesHook architecture + action model
clawguard (JaydenBeard)JavaScript78/100MITNoneRisk pattern library (55+ patterns)
ClawGuard (maxxie114)Python65/100MITpytestInput sanitization patterns
lauty1505/clawguardJavaScriptREMOVEDN/AN/AMALWARE — trojanized fork
yourclaw/clawguardNoneREMOVEDN/AN/ANo code

Appendix B — CODITECT Integration Mapping​

ClawGuard CapabilityCODITECT Hook PointImplementation Path
before_agent_startPreAgentStart hookSystem prompt injection detection
before_tool_callPreToolUse hookInput pattern evaluation + block/redact/confirm
tool_result_persistPostToolUse hookOutput redaction before session log write
JSONL risk analysisSession log watcherBackground risk analyzer against sessions.db
Email sanitizationInput validation middlewarePrompt injection scoring for user-facing inputs
Kill switchEmergency stop hookCritical-risk triggered PreToolUse block-all

Appendix C — Pattern Coverage by Source​

Pattern Categorymaxxie114ClawGuardianJaydenBeardRecommended Source
Prompt injection10 patternsHook-level—ClawGuardian architecture + maxxie114 patterns
Secret/credential detection6 patterns3 modules (API, cloud, tokens)Path monitoringClawGuardian (most comprehensive)
PII filtering—patterns/pii.ts—ClawGuardian (libphonenumber-js)
Destructive commands—destructive/detector.ts11 critical + 30 highJaydenBeard (most extensive)
Sensitive path access——30+ pathsJaydenBeard
Cloud CLI detection——YesJaydenBeard
Persistence mechanisms——YesJaydenBeard

Document: executive-summary.md Full Path: submodules/core/coditect-core/analyze-new-artifacts/clawguard-ai-agent-security/artifacts/executive-summary.md Research Pipeline: Artifact 3 of 5 Next Artifact: Technical Integration Specification (Artifact 4)