Hermes Traffic Guardian
A consent-based, auditable baseline for monitoring Hermes runtime traffic.
The evidence specifies opt-in operation, detect-and-log defaults, process-scoped proxying, no automatic system CA changes, no global proxy changes, no external traffic submission, redaction, and bounded scanning; it also documents signed manifest verification. Points are deducted because no runtime implementation exists, while user confirmation, privilege isolation, rollback, log access control, and dependency-supply-chain handling are not implemented or fully specified. Publisher identity is unverified and receives no extra trust credit.
SKILL.md, SPEC.md, and skill.json consistently describe a specification scaffold with no runtime implementation, and declare node/python3 dependencies plus interface contracts. Points are deducted because key paths and tests for this skill are absent; lifecycle behavior, abnormal-input handling, stale-process cleanup, and diagnostic failures cannot be reproduced or verified statically.
The evidence clearly targets Hermes traffic monitoring and lists scenarios for outbound exfiltration, inbound injection, HTTP/HTTPS inspection, posture export, trigger phrases, and out-of-scope behavior. Points are deducted because input/output boundaries remain largely planned, Chinese-language support is absent, and installation/signature verification relies on npx and GitHub release resources whose mainland reachability is not established.
The package includes frontmatter, versioning, AGPL-3.0-or-later licensing, README, SPEC, CHANGELOG, metadata, layered architecture, schemas, and required-test documentation. Points are deducted because this beta scaffold lacks operational installation guidance, FAQs, troubleshooting, a named maintenance owner, or a clear update path; the changelog mainly records metadata re-releases.
The documents define intended detection, redacted JSONL findings, lifecycle commands, and posture JSON output, with a stated benefit over ad hoc implementation. Points are deducted because the version explicitly ships no proxy or runtime implementation, cannot directly perform Hermes monitoring, provides no verified representative outputs, and requires substantial builder work.
The skill provides commands for signed release-manifest, archive, and file-hash verification, plus auditable finding and posture schemas. Points are deducted because these are instructions rather than verified execution evidence in the selected skill; it contains no implementation or test suite, and the repository CI evidence shown covers other Hermes skills rather than this one.
- This is a specification scaffold, not a runnable traffic monitor; do not claim that exfiltration or injection detection is already delivered.
- The verification procedure depends on GitHub release assets, curl, openssl, jq, shasum/sha256sum, and npx; confirm network reachability, tool versions, and release-signing materials first.
- HTTPS MITM, proxy scoping, log placement, and redaction remain implementation work and require operator review; do not expand to system-wide CA or global proxy changes without explicit confirmation.
- No Chinese operator documentation or selected-skill test evidence is provided.
What does this skill do, and when should you use it?
Hermes Traffic Guardian is a Hermes-focused specification skill for runtime traffic monitoring, not a finished proxy or runtime implementation. It defines an implementation contract covering proxy inspection, outbound exfiltration detection, inbound prompt-injection detection, redacted local logs, and posture export. Its default posture is detect-and-log: no automatic blocking, system CA installation, or global proxy changes. It fits teams that want a security baseline for Hermes before building platform-specific runtime components.
Provides Hermes traffic-monitoring metadata, scope, and safety requirements; supplies a Vercel Skills CLI installation command; and documents a release-verification flow that downloads the manifest, signature, public key, archive, SKILL.md, and skill.json with curl. The flow uses OpenSSL to verify the public-key fingerprint and manifest signature, then jq and SHA-256 checks to validate the archive and individual files. The specification also requires a future implementation to validate configuration, scope proxy variables to a target Hermes process, inspect bounded HTTP text, optionally support per-process HTTPS MITM trust, emit redacted JSONL findings, and export posture JSON for hermes-attestation-guardian.
- A Hermes security engineer needs a concrete contract for building runtime HTTP traffic monitoring.
- An operations team wants to detect outbound exfiltration or inbound prompt injection without default traffic blocking.
- A maintainer needs to verify the integrity of standalone skill release artifacts before installation.
- A builder needs to expose traffic-monitoring status or configuration for Hermes attestation.
What are this skill's strengths and limitations?
- Defines clear safety boundaries: opt-in operation, detect-and-log defaults, and secret redaction.
- Includes a detailed signed-manifest, public-key, archive, and file-checksum verification procedure.
- Covers exfiltration, inbound injection, and posture export for attestation workflows.
- Explicitly excludes global proxy changes, automatic system CA installation, and default blocking.
- The current version explicitly ships without a proxy or runtime implementation.
- Builders must implement the specification, scripts, detection rules, and tests; an existing test suite is not evidenced.
- HTTPS inspection requires operator-supplied per-process trust configuration and cannot automatically mutate the system trust store.
- The source provides direct evidence for Hermes only, not for other runtimes.
How do you install this skill?
Install with the Vercel Skills CLI:
npx skills add prompt-security/clawsec --skill hermes-traffic-guardian -a hermes-agent -y
For standalone installs, follow the verification script in SKILL.md to validate the signed release manifest, archive, SKILL.md, and skill.json before installing or extracting anything. The source does not specify the final installation directory.
How do you use this skill?
This package is a specification baseline and cannot itself start a monitoring proxy. Builders should read SPEC.md, then use lib/ for detectors, redaction, posture export, and reporting; scripts/ for lifecycle, validation, log-query, and attestation helpers; and test/ for unit, proxy-fixture, redaction, and attestation-export tests. The first implementation should support configuration validation, foreground or explicit background operation, process-scoped proxy variables, bounded HTTP inspection, optional per-process HTTPS MITM trust, redacted JSONL findings, and posture JSON export. No directly runnable monitoring command or example trigger prompt is documented.
How does this skill compare with similar options?
It complements rather than replaces the repository's hermes-attestation-guardian: this skill defines the traffic monitor's status and configuration, while the attestation skill should attest them and should not own the proxy runtime. The integration itself is not implemented here.