Skip to main content

ClawGuard AI Agent Security Ecosystem — CODITECT Impact Analysis

Date: 2026-02-18 Pipeline Artifact: 2 of N Analyst: research-agent (Claude Sonnet 4.6) Status: Complete

Executive Summary​

The ClawGuard ecosystem provides three distinct open-source security tools for AI agent systems. For CODITECT, the most relevant tool is ClawGuardian (superglue-ai) — a production-quality TypeScript plugin with a hook-based security architecture that maps directly onto CODITECT's existing 118-hook event system. JaydenBeard's monitoring dashboard provides a complementary post-hoc risk analysis layer with a 55+ pattern library directly applicable to CODITECT session log monitoring. Maxxie114's sanitization server is the weakest fit: its scope is narrowly email-only and its Gmail/GCP dependency is irrelevant to CODITECT's architecture.

The core value proposition is that CODITECT can absorb ClawGuardian's pattern libraries and severity-action routing system to build a native security layer without adopting OpenClaw's plugin framework. The gaps are real and significant: no multi-tenant policy isolation, no CODITECT-native hook integration, no agent identity awareness, and no kill switch for Claude Code-based sessions. These require custom development — approximately 4–6 weeks of engineering effort.

Recommendation: Conditional Adopt (patterns + architecture) — Do Not Adopt (runtime integration)

1. Integration Architecture​

1.1 ClawGuardian Hooks → CODITECT Hook System​

CODITECT has 118 existing hooks covering PreToolUse, PostToolUse, PreAgentStart, and session lifecycle events. ClawGuardian operates via three equivalent OpenClaw lifecycle hooks: before_agent_start, before_tool_call, and tool_result_persist. The conceptual mapping is direct.

Mapping Table:

ClawGuardian HookOpenClaw EventCODITECT EquivalentIntegration Feasibility
before_agent_startSystem prompt inspectionPreAgentStart hook typeHigh — hook pattern is identical
before_tool_callTool input interceptionPreToolUse hook typeHigh — same position in execution chain
tool_result_persistTool output redactionPostToolUse hook typeHigh — same position in execution chain

CODITECT hooks are currently defined as markdown files in coditect-core/hooks/ and invoked at defined lifecycle positions. ClawGuardian hooks are TypeScript modules in src/hooks/. The runtime model differs: CODITECT hooks are Claude Code hooks (shell/Python executables), while ClawGuardian hooks are Node.js modules loaded by OpenClaw's plugin registry.

What this means concretely: CODITECT cannot install ClawGuardian as an npm plugin and call it done. CODITECT hooks run as separate processes (or Python scripts) invoked by Claude Code's hook system — not as in-process Node.js modules. To adopt ClawGuardian's security logic, CODITECT must port the TypeScript patterns to Python hook scripts that implement the same severity-action routing.

Priority port targets from ClawGuardian:

  1. patterns/api-keys.ts — API key detection patterns (6 categories)
  2. patterns/cloud-credentials.ts — AWS, GCP, Azure credential patterns
  3. patterns/tokens.ts — Bearer token and JWT detection
  4. patterns/pii.ts — SSN, credit card, email, phone (uses libphonenumber-js — Python equivalent: phonenumbers)
  5. destructive/detector.ts — rm -rf, git reset --hard, DROP TABLE, sudo, dd patterns

Severity-Action System (highest value to port):

ClawGuardian's severity-action router is its most architecturally significant component. It allows per-severity overrides across five action types: block, redact, agent-confirm, warn, log. CODITECT's existing hooks currently lack this granularity. Adopting this system would allow CODITECT to define differentiated responses — blocking critical secrets while merely warning on medium-severity PII — without hardcoding responses.

# Target CODITECT hook config schema (new)
security_layer:
  secrets:
    critical: block      # PEM private keys, AWS root credentials
    high: redact         # API keys, cloud credentials, bearer tokens
    medium: warn         # Generic environment variable lookups
    low: log             # Low-confidence matches
  pii:
    high: redact         # SSN, credit card
    medium: warn         # Email, phone
  destructive:
    critical: block      # rm -rf /, DROP DATABASE, dd
    high: confirm        # rm -rf, git reset --hard, sudo
    medium: warn         # kill, git checkout
    low: log             # git branch -d

1.2 JaydenBeard Monitoring → CODITECT Session Log + Trajectory Dashboard​

JaydenBeard's tool operates by watching Claude/OpenClaw JSONL session log files with chokidar and streaming parsed events to a WebSocket-connected dashboard at localhost:3847. CODITECT already produces session logs in JSONL format at ~/.coditect-data/session-logs/.

Integration Path: JaydenBeard can watch CODITECT session log directories with zero modification.

// jayden-clawguard config pointed at CODITECT session logs
{
  "sessionsPath": "/Users/<user>/PROJECTS/.coditect-data/session-logs/",
  "alerts": {
    "enabled": true,
    "webhookUrl": "<coditect-notification-endpoint>",
    "onRiskLevels": ["high", "critical"]
  }
}

The risk-analyzer.js tool category mapping already covers CODITECT tool names: Read, Write, Edit, web_fetch, web_search, exec. This is not coincidental — these are Claude Code's standard tool names, and CODITECT sessions are Claude Code sessions. The tool is directly applicable to CODITECT session monitoring as-is.

Gap: JaydenBeard's dashboard is a standalone Express server running on localhost:3847. CODITECT's trajectory dashboard is a separate system. Bridging them requires either embedding JaydenBeard's WebSocket feed into the trajectory dashboard UI, or replacing JaydenBeard's dashboard entirely with a CODITECT-native security panel that consumes the same risk analysis logic.

1.3 Maxxie114 Sanitization → CODITECT Input Validation Pipeline​

Maxxie114's ClawGuard is a FastAPI server that intercepts incoming Gmail messages, sanitizes them through a regex-based prompt injection scorer (0–100 risk score), and routes clean messages to downstream AI agents. Its 10 prompt injection patterns and 6 secret detection patterns are portable. Its Gmail/GCP Pub/Sub architecture is not.

What transfers:

  • 10 prompt injection patterns (ignore_instructions, delimiter_injection, jailbreak_attempt, encoding_evasion, hidden_instruction, etc.)
  • Risk scoring logic (additive regex match scoring, 0–100 scale)
  • Pattern taxonomy: separate injection patterns from secret patterns from PII patterns

What does not transfer:

  • Gmail API integration
  • HMAC webhook verification for Gmail Pub/Sub
  • EventStore SQLite schema (email-centric schema: sender, subject, body)
  • Admin dashboard UI (email event timeline)

Integration Recommendation: Extract the 10 injection patterns and the risk scoring logic into CODITECT's input validation hook. Discard the rest. This is a 1–2 day extraction task, not an integration project.

2. Multi-Tenancy Implications​

2.1 Current State of All Three Tools​

None of the three ClawGuard tools has any concept of multi-tenancy. All configuration is global and single-user:

  • ClawGuardian: single openclaw.plugin.json manifest loaded at plugin install time
  • JaydenBeard: single config.default.json with a single sessionsPath and single webhook URL
  • Maxxie114: single SQLite EventStore, single Bearer token, single Gmail account

This is the most significant structural gap for CODITECT adoption. CODITECT is a multi-tenant platform. Tenant A's security policy cannot bleed into Tenant B's session monitoring. A shared detection rule that blocks Tenant B's legitimate use of the AWS CLI would be a product defect.

2.2 Required Architecture for Multi-Tenant Security​

CODITECT must implement tenant-scoped security policy as a first-class concern. ClawGuardian's configSchema (from openclaw.plugin.json) provides a good baseline schema for per-tenant configuration — the allowlist.sessions, allowlist.patterns, and allowlist.tools fields all support the concept of tenant-specific overrides.

Required CODITECT additions:

# Per-tenant security policy (stored in platform.db or org.db)
class TenantSecurityPolicy:
    tenant_id: str

    # Inherit from org-level baseline, override per-tenant
    secrets_action: Literal["block", "redact", "warn", "log"]
    pii_action: Literal["block", "redact", "warn", "log"]
    destructive_action: Literal["block", "confirm", "warn", "log"]

    # Tenant-specific allowlists
    allowed_tools: list[str]          # e.g., tenant uses AWS CLI legitimately
    allowed_patterns: list[str]       # regex patterns to skip

    # Tenant-specific additions
    custom_patterns: list[PatternDef]  # tenant-specific detection rules

    # Compliance tier
    compliance_level: Literal["standard", "soc2", "hipaa"]

Shared vs. Tenant-Specific Detection Rules:

Rule TypeSharedPer-Tenant
Core injection patterns (jailbreak, delimiter)YesNo override
Secret detection patterns (API keys, AWS keys)YesAllowlist override
PII detection (SSN, credit card)YesCategory enable/disable
Destructive command patternsYesAction override
Custom business rulesNoTenant-defined only

The architecture should layer: org-level baseline → compliance tier override → tenant override → session allowlist.

2.3 Session Log Isolation​

JaydenBeard's sessionsPath points at a directory and watches all JSONL files recursively. In CODITECT's multi-tenant setup, session logs are already namespaced by projects/{project_id}/{machine_uuid}/. The monitoring layer must respect this namespace — a tenant's security events must not be visible to another tenant's security dashboard.

This requires per-tenant JaydenBeard instances OR a single monitoring process with explicit tenant-scoped filtering before any event is emitted to a dashboard or webhook.

3. Compliance Surface​

3.1 SOC 2 Alignment​

The ClawGuard ecosystem supports SOC 2 Type II indirectly through behavioral monitoring and audit trail generation. Direct alignment:

SOC 2 ControlClawGuard ContributionGap
CC6.1 — Logical access controlsClawGuardian blocks/redacts secrets before tool executionNo identity-based access control; no authentication of who triggered the agent
CC6.6 — Transmission encryptionAll tools are local-process only; no data leaves the machineN/A (local-first is SOC 2 favorable)
CC7.2 — System monitoringJaydenBeard provides real-time activity monitoring with risk scoringNo centralized logging to SIEM; webhook alerting only
CC7.3 — Security incident identificationJaydenBeard alert system triggers on high/critical risk patternsNo incident ticket creation; no severity escalation workflow
CC8.1 — Change managementAudit trail via session JSONL logsNo immutable audit log; JSONL files are mutable
A1.2 — Availability monitoringNot coveredNot in scope for any ClawGuard tool

SOC 2 Assessment: The monitoring and redaction capabilities advance SOC 2 readiness but do not complete any control. CODITECT needs an immutable audit log (append-only storage for security events), SIEM integration, and an incident escalation workflow to satisfy CC7.2 and CC7.3. ClawGuard provides the detection layer; CODITECT must provide the logging and response layer.

3.2 PII Handling​

ClawGuardian's patterns/pii.ts covers four PII categories at defined severity levels:

  • SSN: high severity → redact (default)
  • Credit card: high severity → redact (default)
  • Email address: medium severity → warn (default)
  • Phone number: medium severity → warn (default, uses libphonenumber-js)

For CODITECT's platform context, this coverage is minimal. Enterprise customers handling healthcare data will expect HIPAA-relevant PII patterns: date of birth, medical record numbers, diagnosis codes, drug names. The current pattern set is consumer-oriented, not enterprise-oriented.

CODITECT PII Gap: No detection for:

  • Healthcare identifiers (MRN, NPI, ICD codes)
  • Financial account numbers (IBAN, routing numbers)
  • Government IDs beyond US SSN (passport numbers, driver's license patterns)
  • Canadian SIN, European VAT numbers (relevant given C-of-C-CANADA project context)

3.3 Data Residency​

All three tools are explicitly local-first:

  • Maxxie114: SQLite on local disk, no cloud telemetry
  • ClawGuardian: stateless, in-memory only during plugin execution
  • JaydenBeard: in-memory + local file watching, webhook export is optional

This is a compliance asset, not a liability. Local-first processing means no customer data leaves the customer's environment for security scanning. This aligns with CODITECT's data residency obligations for enterprise customers and simplifies GDPR compliance (data processed locally, not transmitted to a third-party service for analysis).

The only data residency concern is JaydenBeard's optional webhook export — if configured to POST to an external URL, security event data (tool names, partial arguments, risk flags) leaves the local environment. CODITECT must document this clearly and ensure tenant-controlled webhook configuration with audit logging of webhook destinations.

4. Observability Integration​

4.1 JaydenBeard WebSocket Dashboard → CODITECT Trajectory Dashboard​

JaydenBeard runs an Express server on localhost:3847 with:

  • WebSocket endpoint for real-time event broadcast
  • REST routes: /sessions, /activity, /alerts, /streaming, /exports, /dump, /gateway, /config, /version
  • Static HTML+JS dashboard at root (vanilla JS, no framework)

CODITECT's trajectory dashboard is a separate system tracking agent execution progress. The two are not the same thing — trajectory is about task completion state, security monitoring is about risk events. They should remain separate concerns with a shared notification layer.

Integration Pattern A — Embed (Not Recommended): Embed JaydenBeard's risk event stream into the trajectory dashboard as a "security panel." This couples two concerns and makes both harder to maintain.

Integration Pattern B — Parallel Panels (Recommended): Run JaydenBeard as a separate local service. Surface a "Security Events" link in the CODITECT UI that opens JaydenBeard's dashboard at localhost:3847. Low coupling, immediate value.

Integration Pattern C — Native CODITECT Security Dashboard (Long-term): Port JaydenBeard's risk analysis logic (risk-analyzer.js) into CODITECT's session monitoring pipeline. Build a CODITECT-native security dashboard that consumes the same sessions.db and security event data. This eliminates the dependency on a separate Node.js process and allows per-tenant scoping that JaydenBeard cannot provide.

Recommendation: Pattern B for immediate adoption (days of work), Pattern C as the 6-month target.

4.2 Webhook Alerts → CODITECT Notification System​

JaydenBeard's alert system sends JSON payloads to a configured webhook URL on high/critical risk events. The payload schema is:

{
  "type": "activity_alert",
  "timestamp": "<ISO 8601>",
  "activity": {
    "tool": "<tool_name>",
    "arguments": { ... },
    "timestamp": "<ISO 8601>"
  },
  "risk": {
    "level": "<low|medium|high|critical>",
    "flags": ["<flag_name>", ...]
  },
  "message": "<human-readable summary>"
}

CODITECT's messaging.db and notification system can consume this webhook payload directly. The payload is clean and well-structured. Integration requires:

  1. A CODITECT webhook receiver endpoint (or pointing JaydenBeard at the existing notification service endpoint)
  2. A mapping from JaydenBeard's risk.level to CODITECT notification severity
  3. Tenant context injection — JaydenBeard does not include tenant_id in the payload; CODITECT must add it

Telegram note: JaydenBeard has first-class Telegram alert support (detected by api.telegram.org URL prefix). Discord and Slack are supported via generic webhook. CODITECT's notification system should be the destination, not these consumer chat platforms.

5. Multi-Agent Orchestration Fit​

5.1 Pre-Execution Security Gate (ClawGuardian before_tool_call)​

CODITECT's 776-agent system executes tool calls across many agent types. A security gate positioned at the PreToolUse hook point — equivalent to ClawGuardian's before_tool_call hook — is the correct architectural position for input filtering.

Implementation model for CODITECT:

# hooks/security-gate/pre_tool_use.py
# Invoked by Claude Code PreToolUse hook before every tool call

import sys
import json
from security_layer import SecretsDetector, PIIDetector, DestructiveDetector

def run(tool_name: str, tool_input: dict, tenant_id: str) -> dict:
    """
    Returns: {
        "action": "allow" | "block" | "redact",
        "modified_input": dict | None,  # populated if action == "redact"
        "findings": list[Finding]
    }
    """
    detector = CompositeDetector(tenant_id=tenant_id)
    result = detector.analyze(tool_name=tool_name, input_data=tool_input)

    if result.action == "block":
        # Exit non-zero — Claude Code interprets this as hook block
        sys.exit(2)
    elif result.action == "redact":
        # Output modified input for Claude Code to use
        print(json.dumps(result.modified_input))
    # allow: exit 0, no output

Key design decision: Claude Code's hook system uses exit codes to signal block vs. allow. ClawGuardian uses JavaScript return values within an in-process plugin. The port requires mapping ClawGuardian's return-value API to Claude Code's exit-code API. This is straightforward but must be done deliberately — incorrect exit codes will silently pass or silently block.

5.2 Post-Execution Monitoring (JaydenBeard Session Parser)​

JaydenBeard's parser reads JSONL session log entries and categorizes tool calls by risk level. In CODITECT's multi-agent orchestration context, this provides visibility into what each of the 776 agents is doing in aggregate — not just per-session, but across all active sessions.

Orchestration-specific value:

  • Ralph Wiggum loops (autonomous loops via scripts/core/ralph_wiggum/) run for extended periods without human checkpoints. JaydenBeard's sequence detection (sequenceWindowMinutes: 5, enableSequenceDetection: true) identifies multi-step attack patterns across a rolling time window. This is the correct safety layer for autonomous loops.
  • The kill switch capability in JaydenBeard (route /gateway) maps to stopping a Ralph Wiggum loop. However, JaydenBeard's kill switch only works for OpenClaw/MoltBot/ClawdBot gateways — not for Claude Code sessions. A CODITECT kill switch for Claude Code would require writing a sentinel file that the running process checks, or SIGTERM on the Claude Code process.

5.3 Input Sanitization Pipeline (Maxxie114 Patterns)​

The 10 injection patterns from Maxxie114 represent a baseline for prompt injection detection. In CODITECT's context, the most relevant application is not email sanitization but rather tool input sanitization — specifically for agents that consume user-provided content (e.g., DMS document ingestion, web content processing, external API responses being fed back to agents).

Pattern applicability by agent type:

PatternRelevant CODITECT Context
ignore_instructionsAny agent processing external text content
new_instructionsDocument ingestion (DMS), web scraping agents
system_prompt_overrideMulti-agent orchestration where agents pass content between each other
delimiter_injectionAgents processing structured data with separator characters
tool_call_injectionAgents parsing tool output from external APIs
exfiltration_attemptAny agent with network access and access to file system
secret_requestAgents operating in user-facing contexts
jailbreak_attemptAll customer-facing agent contexts
encoding_evasionWeb content processing, document ingestion
hidden_instructionAny content that includes HTML, markdown, or rich text

The scoring approach (additive regex matching, 0–100 scale) is too coarse for CODITECT's needs. A per-pattern match should route to the severity-action system rather than accumulate a numeric score that requires a threshold calibration that will drift over time.

6. Advantages​

6.1 Pattern Libraries Ready to Use

ClawGuardian has 45,205 lines of tests validating its pattern library. This is the highest-quality starting point available in the open-source ecosystem for CODITECT's security use cases. Porting these patterns to Python saves approximately 3–4 weeks of pattern development and validation work.

6.2 Proven Severity-Action Architecture

ClawGuardian's six-action system (block, redact, confirm, agent-confirm, warn, log) with per-severity overrides is architecturally superior to a binary allow/block model. This design allows CODITECT to deploy security incrementally — start in warn-only mode, move to redact for confirmed patterns, move to block only when false positive rate is acceptable. Adopting this architecture now avoids costly redesign later.

6.3 JaydenBeard Session Monitoring Works Today

JaydenBeard's tool can watch CODITECT session log directories without modification, because CODITECT session logs are Claude Code JSONL sessions and JaydenBeard's tool category mapping already covers Claude Code's standard tool names (Read, Write, Edit, web_fetch, web_search, exec). This means CODITECT can deploy real-time security monitoring in days, not weeks.

6.4 Local-First Compliance Alignment

All three tools are local-first by design. No customer session data leaves the customer environment for security analysis. This is directly compatible with CODITECT's data residency requirements and GDPR obligations, and avoids the legal complexity of transmitting potentially sensitive data to a third-party security scanning service.

6.5 MIT Licensed — No Restrictions

All three tools are MIT licensed. CODITECT can incorporate, modify, and redistribute any portion of the code without license friction.

6.6 Sequence Detection for Autonomous Loops

JaydenBeard's sequence detection — the ability to identify multi-step risk patterns within a rolling 5-minute window — is directly applicable to CODITECT's Ralph Wiggum autonomous loops, which run without human checkpoints. This is a safety capability that CODITECT currently lacks entirely.

7. Gaps and Risks​

This section is explicit about what is missing. These are not minor gaps.

7.1 No Multi-Tenant Policy Isolation (Blocker)

None of the three tools has any concept of multi-tenancy. Every configuration is global and single-user. CODITECT is a multi-tenant platform. Adopting any of these tools without building a multi-tenant policy layer on top means all tenants share one security policy. A customer's legitimate use of sudo for a DevOps tenant would be blocked or flagged identically to an attack attempt in another tenant's session. This is a product defect, not a configuration issue.

Multi-tenant security policy isolation is the largest single item that requires custom CODITECT development. Estimate: 3–4 weeks of engineering.

7.2 No Claude Code Kill Switch

JaydenBeard has a kill switch (/gateway route) for OpenClaw, MoltBot, and ClawdBot gateways. There is no mechanism to stop a running Claude Code session. Claude Code does not expose a programmatic stop API. Stopping a Claude Code session requires SIGTERM to the process, writing a sentinel file that the hook system checks, or having the PreToolUse hook return a block at the next tool call. None of these are as clean as JaydenBeard's kill switch concept.

This is a real safety gap for CODITECT's autonomous Ralph Wiggum loops: if a critical risk event is detected post-execution (by JaydenBeard) rather than pre-execution (by ClawGuardian), there is no mechanism to stop the running loop. The only mitigation is ensuring pre-execution checks are comprehensive enough that post-execution detection is a monitoring function, not a safety function.

7.3 No Agent Identity in Security Events

JaydenBeard's risk events contain tool, arguments, timestamp, and risk.flags. They do not contain which agent invoked the tool, which tenant the session belongs to, which task ID is active, or which user initiated the session. In CODITECT's 776-agent system, knowing that "a critical risk event occurred" without knowing which agent, which tenant, and which task context is insufficient for incident response.

Enriching security events with CODITECT context (agent_id, tenant_id, task_id, session_id) requires either post-processing the session log before JaydenBeard reads it (not feasible) or building a CODITECT-native monitoring pipeline that has access to this context natively.

7.4 ClawGuardian is Not Portable Without a Port

ClawGuardian is a TypeScript npm plugin designed for OpenClaw's in-process plugin registry. CODITECT hooks are Python/shell executables invoked by Claude Code's hook system via subprocess. These runtime models are incompatible. ClawGuardian cannot be installed and used directly in CODITECT — its patterns must be ported to Python hook scripts.

This is not a risk so much as a scope clarification: "adopt ClawGuardian" means "port ClawGuardian's patterns and severity-action system to Python" — not "npm install @yourclaw/clawguardian."

7.5 Vanilla JavaScript — JaydenBeard Has No Tests and No Types

JaydenBeard's source is vanilla JavaScript (ESM, no TypeScript) with no test suite. The one test file (tests/api.test.js) contains integration-style API tests, not unit tests of the risk analysis logic. The risk-analyzer.js and parser.js modules — the core of the tool's value — are untested.

This means the 55+ risk patterns in risk-analyzer.js have unknown false positive and false negative rates in CODITECT's operational context. Before relying on JaydenBeard's pattern library for security decisions, CODITECT should validate patterns against a sample of real CODITECT session logs and measure actual FP/FN rates.

7.6 No Rate Limiting or Alerting Deduplication

JaydenBeard's alert system sends a webhook POST for every qualifying event with no deduplication, no rate limiting, and no alert correlation. In a high-activity CODITECT session (a Ralph Wiggum loop running for hours), a single misconfigured agent could generate hundreds of high-risk events per minute, flooding the webhook endpoint and potentially triggering downstream service throttling.

This is a production reliability risk, not just a theoretical concern. JaydenBeard's 10-second timeout per alert (ALERT_TIMEOUT_MS = 10000) and no retry logic means alerts will silently drop under load.

7.7 Pattern Evasion — Regex-Only Detection

All three tools rely on regex pattern matching for security detection. Regex-based detection is bypassable. An adversarial input designed to evade known patterns — encoding variation, Unicode normalization attacks, context-splitting across tool calls — will not be caught by regex matching.

This is an inherent limitation of the approach, not specific to these tools. CODITECT should treat the ClawGuard pattern library as a minimum viable detection layer, not a comprehensive defense. LLM-based prompt injection detection (using a separate classification model to evaluate suspicious inputs) would be a complementary capability not provided by any of these tools.

8. Integration Patterns​

Pattern A: Direct Session Monitoring (JaydenBeard, Days of Work)​

Deploy JaydenBeard immediately, pointed at CODITECT's session log directory. No code changes required.

# Install
npm install -g @jaydenbeard/clawguard

# Configure (create coditect.config.json)
# sessionsPath: ~/.coditect-data/session-logs/
# alerts.webhookUrl: <coditect-notification-endpoint>
# alerts.onRiskLevels: ["high", "critical"]
# detection.enableSequenceDetection: true

# Run as background service
clawguard install --config coditect.config.json
clawguard start

Value delivered: Real-time risk visibility into all active CODITECT sessions, webhook alerting on high/critical events, kill switch capability (for OpenClaw sessions — not Claude Code).

Limitation: No tenant isolation, no agent identity, no CODITECT context enrichment.

Pattern B: Pre-Execution Security Hook (ClawGuardian Port, 3–4 Weeks)​

Port ClawGuardian's pattern library to a CODITECT Python PreToolUse hook. This is the primary security gate for the 776-agent system.

Implementation sketch:

# File: coditect-core/hooks/security-gate/pre_tool_use.py
# Hook type: PreToolUse (runs before every tool call)
# Input: STDIN JSON with tool_name and tool_input
# Output: exit 0 (allow), exit 2 (block), or STDOUT modified_input (redact)

import sys
import json
import re
from dataclasses import dataclass
from typing import Literal

Action = Literal["block", "redact", "warn", "log", "allow"]
Severity = Literal["critical", "high", "medium", "low"]

# Ported from ClawGuardian patterns/api-keys.ts
API_KEY_PATTERNS = [
    (r'sk-[a-zA-Z0-9]{20,}', 'critical', 'openai_api_key'),
    (r'AKIA[0-9A-Z]{16}', 'critical', 'aws_access_key_id'),
    (r'ghp_[a-zA-Z0-9]{36}', 'high', 'github_token'),
    (r'-----BEGIN (?:RSA |EC )?PRIVATE KEY-----', 'critical', 'private_key'),
    # ... full pattern set ported from ClawGuardian
]

# Ported from ClawGuardian destructive/detector.ts
DESTRUCTIVE_PATTERNS = [
    (r'\brm\s+-rf?\s+/', 'critical', 'rm_root'),
    (r'\brm\s+-rf\b', 'high', 'rm_rf'),
    (r'\bDROP\s+(TABLE|DATABASE|SCHEMA)\b', 'critical', 'sql_drop'),
    (r'\bgit\s+reset\s+--hard\b', 'high', 'git_reset_hard'),
    (r'\bdd\s+if=', 'critical', 'dd_disk_write'),
    # ... full pattern set
]

def get_tenant_policy(tenant_id: str) -> dict:
    """Load per-tenant security policy from platform.db."""
    # TODO: implement multi-tenant policy lookup
    return DEFAULT_POLICY

def analyze_input(tool_name: str, tool_input: dict, policy: dict) -> dict:
    input_str = json.dumps(tool_input)
    findings = []

    for pattern, severity, name in API_KEY_PATTERNS + DESTRUCTIVE_PATTERNS:
        if re.search(pattern, input_str, re.IGNORECASE):
            findings.append({
                "name": name,
                "severity": severity,
                "action": policy[severity]
            })

    if not findings:
        return {"action": "allow"}

    # Highest severity finding wins for action routing
    severity_order = ["critical", "high", "medium", "low"]
    worst = min(findings, key=lambda f: severity_order.index(f["severity"]))
    return {"action": worst["action"], "findings": findings}

if __name__ == "__main__":
    event = json.load(sys.stdin)
    tool_name = event.get("tool_name", "")
    tool_input = event.get("tool_input", {})
    tenant_id = event.get("tenant_id", "default")

    policy = get_tenant_policy(tenant_id)
    result = analyze_input(tool_name, tool_input, policy)

    if result["action"] == "block":
        print(json.dumps({"error": "Blocked by security gate",
                          "findings": result.get("findings", [])}),
              file=sys.stderr)
        sys.exit(2)
    elif result["action"] == "redact":
        # Output redacted input for Claude Code to pass to the tool
        redacted = redact_input(tool_input, result["findings"])
        print(json.dumps(redacted))
    # warn/log: exit 0 with optional stderr logging

Pattern C: Unified Security Event Schema (CODITECT-Native, 6 Weeks)​

Build a CODITECT-native security event model that enriches all security events with CODITECT context before storage or alerting.

# Security event schema — enriches ClawGuardian/JaydenBeard events with CODITECT context
@dataclass
class SecurityEvent:
    # From ClawGuardian/JaydenBeard
    event_type: str          # "pre_tool_block", "post_tool_alert", "sequence_detected"
    tool_name: str
    risk_level: str          # low | medium | high | critical
    flags: list[str]         # specific pattern names that matched
    timestamp: str           # ISO 8601

    # CODITECT context (not present in ClawGuard tools)
    tenant_id: str
    agent_id: str
    task_id: str             # CODITECT track task ID
    session_id: str
    project_id: str

    # Resolution
    action_taken: str        # block | redact | warn | log | allow
    redaction_applied: bool

Events stored in sessions.db with a security_events table, queryable per-tenant, available to the trajectory dashboard, and exportable for compliance reporting.

Pattern D: Pattern Validation Before Production Deployment (1 Week)​

Before deploying any detection logic in block mode, validate all ported patterns against a sample of real CODITECT session logs.

# scripts/security/validate-patterns.py
# Run against ~/.coditect-data/session-logs/ sample
# Output: FP rate, FN rate, pattern-level match counts
# Decision gate: no pattern with FP > 5% enters block mode without review

python3 scripts/security/validate-patterns.py \
    --sessions ~/.coditect-data/session-logs/ \
    --patterns security_layer/patterns/ \
    --mode dry-run \
    --output analysis/security-pattern-validation-2026-02-18.json

This is not optional. Deploying block-mode patterns without validation will block legitimate agent operations and create production incidents.

Summary: Priority Implementation Roadmap​

PriorityActionEffortBlocker
1Deploy JaydenBeard against CODITECT session logs (Pattern A)1 dayNone
2Validate JaydenBeard patterns against real CODITECT sessions (Pattern D)1 weekPattern A complete
3Port ClawGuardian injection + secret patterns to Python (Pattern B)3–4 weeksPattern D results
4Build multi-tenant security policy schema in platform.db3–4 weeksParallel with item 3
5Build CODITECT-native security event schema (Pattern C)6 weeksItems 3 + 4
6Integrate security dashboard into CODITECT trajectory dashboard4 weeksItem 5
7Enterprise PII patterns (healthcare, financial, regional)2 weeksItem 3

Do not skip Pattern D (validation). Deploying block-mode patterns without empirical FP validation in CODITECT's operational context is the highest risk action in this roadmap.

Source Files Referenced​

  • /Users/halcasteel/PROJECTS/coditect-rollout-master/submodules/core/coditect-core/analyze-new-artifacts/clawguard-ai-agent-security/artifacts/research-context.json
  • /Users/halcasteel/PROJECTS/coditect-rollout-master/submodules/dev/coditect-bot/clawguardian/openclaw.plugin.json
  • /Users/halcasteel/PROJECTS/coditect-rollout-master/submodules/dev/coditect-bot/jayden-clawguard/config.default.json
  • /Users/halcasteel/PROJECTS/coditect-rollout-master/submodules/dev/coditect-bot/jayden-clawguard/src/lib/risk-analyzer.js
  • /Users/halcasteel/PROJECTS/coditect-rollout-master/submodules/dev/coditect-bot/jayden-clawguard/src/lib/alerts.js