Runtime Traffic Guardian Baseline

Summary

This module defines the baseline for a new platform-specific runtime traffic monitoring family:

• skills/openclaw-traffic-guardian/
• skills/hermes-traffic-guardian/
• skills/nanoclaw-traffic-guardian/
• skills/picoclaw-traffic-guardian/

These packages are intentionally specification scaffolds. They reserve the skill names, platform metadata, SBOM entries, frontmatter, folder structure, and safety contracts so platform builders can add implementations without changing the architectural decision.

Capability Gap

The existing ClawSec matrix covers advisory verification, config drift, self-pen-testing/posture review, and supply-chain verification. It does not currently provide live runtime traffic monitoring:

• HTTP request/response inspection
• optional HTTPS inspection with explicit CA trust
• outbound secret exfiltration detection
• inbound command-injection detection
• redacted local threat logging
• platform-specific status/profile/attestation surfaces

Architecture Decision

Runtime traffic monitoring is a separate skill family, not an extension of existing posture or scanner skills.

Reasoning:

• clawsec-scanner is periodic report-only vulnerability scanning and OpenClaw hook DAST.
• hermes-attestation-guardian produces and verifies deterministic posture artifacts; it should attest monitor state, not run a proxy.
• clawsec-nanoclaw owns advisory/signature/integrity MCP tools; traffic interception requires host-side network ownership and stricter container boundaries.
• picoclaw-security-guardian is read-only posture/drift/supply-chain logic; proxy runtime would violate that safety posture.

Shared Safety Contract

All traffic guardian implementations must preserve these constraints:

1. Opt-in only.
2. Detect-and-log by default.
3. No automatic system CA installation.
4. No global HTTP_PROXY or HTTPS_PROXY mutation.
5. No blocking in the first implementation.
6. Redact secret snippets before persistence or surfaced output.
7. Bound scan bytes and log retention.
8. Keep platform adapter state under platform-specific ClawSec security directories.

Platform Ownership

Skill	Runtime owner	Integration point
openclaw-traffic-guardian	OpenClaw adapter	Optional clawsec-suite add-on and optional OpenClaw hook/status integration
hermes-traffic-guardian	Hermes adapter	Posture export watched by hermes-attestation-guardian
nanoclaw-traffic-guardian	NanoClaw host service	Container-safe MCP tools and IPC result channel
picoclaw-traffic-guardian	Picoclaw adapter	Profile fragment consumed by picoclaw-security-guardian

Shared Finding Schema

Builders should use the common schema described in each skill's SPEC.md:

{
  "schema_version": "clawsec-traffic-finding/v1",
  "platform": "openclaw",
  "direction": "outbound",
  "protocol": "http",
  "threat_type": "EXFIL",
  "pattern": "ai_api_key",
  "severity": "high",
  "source": "127.0.0.1",
  "dest": "api.example.com:443",
  "snippet": "[REDACTED]",
  "timestamp": "2026-04-26T00:00:00.000Z"
}

Minimum Detection Families

Outbound EXFIL:

• AI API keys
• AWS access key IDs
• private key PEM markers
• SSH key file paths
• sensitive Unix file paths
• dotenv and cloud credential paths

Inbound INJECTION:

• pipe-to-shell commands
• shell exec flags
• reverse shell command shapes
• destructive remove commands
• SSH authorized-key injection shapes

Platform builders may add stable platform-specific markers, such as NanoClaw WhatsApp session paths or Picoclaw gateway token paths, once those names are verified.

Source References

• skills/openclaw-traffic-guardian/SKILL.md
• skills/openclaw-traffic-guardian/SPEC.md
• skills/hermes-traffic-guardian/SKILL.md
• skills/hermes-traffic-guardian/SPEC.md
• skills/nanoclaw-traffic-guardian/SKILL.md
• skills/nanoclaw-traffic-guardian/SPEC.md
• skills/picoclaw-traffic-guardian/SKILL.md
• skills/picoclaw-traffic-guardian/SPEC.md