Violin: Supervised Agentic Penetration Testing Profile for Hermes Agent

TL;DR: Violin is an open-source, MIT-licensed penetration testing profile developed by Strategic Automation Ltd for Nous Research’s Hermes Agent. Unlike unconstrained AI agents that risk out-of-scope pivots, destructive execution, or hallucinated vulnerability reports, Violin enforces a strict, fail-closed procedural guardrail layer (violin-guard) at the tool boundary. Operating across 35 routed playbooks and 7 specialized skills, it enforces strict scope validation, maintains disk-persistent engagement state across LLM context compactions, and demands tamper-evident, cryptographically signed HTTP execution receipts for every reported vulnerability.

Autonomous artificial intelligence agents are rapidly changing how cybersecurity assessments and offensive security workflows operate. When equipped with command-line access, modern large language models can parse complex network topologies, identify vulnerable web parameters, and construct intricate exploit chains in minutes.

However, deploying unconstrained autonomous agents in authorized penetration tests introduces severe risks. Language models can hallucinate vulnerability findings, lose track of their objective when long engagement logs trigger context window summarization, or pivot into unauthorized production networks. In a worst-case scenario, an unguided agent might execute destructive terminal commands such as unintended disk wipes, resource-exhausting denial of service loops, or out-of-scope credential stuffing against third-party endpoints.

To bridge the gap between autonomous speed and professional engagement integrity, Strategic Automation Ltd created Violin, an open-source agentic profile built natively for the Hermes Agent ecosystem. By placing a deterministic, AST-aware execution guard between the language model and the target environment, Violin ensures that human operators retain complete oversight, every target probe adheres strictly to written scope, and every reported finding is backed by verifiable, signed cryptographic proof.

What is Violin?

Violin is a supervised, Hermes-native penetration testing profile and guardrail framework that couples 35 specialized offensive playbooks with a deterministic, fail-closed tool boundary to guarantee scope compliance, disk-persistent engagement memory, and signed execution receipts for every validated security finding.

+-------------------------------------------------------------------------+
|                        Violin System Architecture                       |
+-------------------------------------------------------------------------+
|  Human Operator / Penetration Tester                                   |
|  - Defines authorization, target boundaries, and scope.yaml             |
|  - Sets testing objectives, review thresholds, and active phase tasks    |
+------------------------------------+------------------------------------+
                                     |
+------------------------------------v------------------------------------+
|  Hermes Agent Core Runtime (Hermes >= 0.18.0)                           |
|  - Language Model (Qwen 2.5/3.8, DeepSeek V3/V4, Claude, GPT-4o)        |
|  - Tool calling orchestration, conversation memory, and session context |
+------------------------------------+------------------------------------+
                                     |
+------------------------------------v------------------------------------+
|  Violin Guardrail Layer (plugins/violin_guard)                          |
|  +-------------------------------------------------------------------+  |
|  | 1. Scope Gate: AST target parsing (IP, CIDR, Domain, URL literals)|  |
|  | 2. Phase Gate: Restricts commands to active PTT engagement stage  |  |
|  | 3. Safety Gate: Blocks destructive commands (rm -rf, dd, mkfs)    |  |
|  | 4. History Gate: Detects redundant command loops and stalls       |  |
|  | 5. Hypothesis Gate: Enforces active hypothesis binding           |  |
|  | 6. Receipt Integrity: Signs execution output with SHA-256 digests|  |
|  +-------------------------------------------------------------------+  |
+------------------------------------+------------------------------------+
                                     |
+------------------------------------v------------------------------------+
|  Target Execution Boundary & Network Environment                        |
|  - violin_exec / violin_exec_burst (Guarded target execution)           |
|  - Kali Linux / Parrot OS tools (Nmap, Nikto, ffuf, sqlmap, curl)       |
|  - Target Network, Web Applications, APIs, and Identity Systems         |
+------------------------------------+------------------------------------+
                                     |
+------------------------------------v------------------------------------+
|  Persistent Engagement Artifacts ($ENG_DIR/)                            |
|  - scope/scope.yaml (Approved target boundaries & exclusions)          |
|  - state/ (ptt.md, history.md, checkpoint.json, coverage-matrix.yaml)   |
|  - evidence/ (Signed execution receipts & raw response captures)       |
|  - evidence/findings.jsonl (Tamper-evident, receipt-backed findings)    |
|  - reporting/ & retrospective/ (Client deliverables & audit trail)      |
+-------------------------------------------------------------------------+

Rather than treating the LLM as an unsupervised black box, Violin separates administrative host preparation from actual target execution. Host maintenance runs through Hermes’ standard terminal tooling, while all network packets and target-directed commands must pass through violin_exec and the violin-guard plugin.

The Danger of Unconstrained Agentic Pentesting

To understand why Violin’s architecture is essential, one must look at how standard autonomous agents fail during real-world penetration tests. While an agent may succeed in a short, 15-minute Capture The Flag (CTF) demo, enterprise assessments present obstacles that expose structural weaknesses in raw LLM workflows:

+-------------------------------------------------------------------------+
|                  Common Failure Modes of Raw AI Pentesting              |
+-----------------------------------+-------------------------------------+
| Problem                           | Real-World Impact                   |
+-----------------------------------+-------------------------------------+
| 1. Scope Creep & Pivoting         | Agent follows redirects or DNS links|
|                                   | into third-party cloud infrastructure|
| 2. Context Window Compaction      | Engagement log resets; agent forgets|
|                                   | completed tasks and duplicates work |
| 3. Destructive Command Execution  | Unintended data deletion, schema    |
|                                   | corruption, or denial-of-service    |
| 4. Hallucinated Vulnerabilities   | Agent claims an SQLi or RCE exists   |
|                                   | without raw HTTP proof to replay    |
| 5. Silent Coverage Gaps           | Agent finds one bug and ignores 40  |
|                                   | other in-scope endpoints and routes |
+-----------------------------------+-------------------------------------+

1. Scope Creep and Cloud Boundary Violations

During web and infrastructure discovery, applications frequently link to third-party CDNs, external OAuth providers (such as Google or Microsoft login endpoints), and external analytics hosts. An unconstrained agent running automated crawlers or recursive fuzzers will inadvertently attack out-of-scope infrastructure, resulting in legal liabilities and unauthorized testing violations.

2. Context Collapse During Extended Engagements

A thorough enterprise penetration test spans hours or days, generating thousands of terminal lines. When the agent reaches its context token limit, the underlying LLM summarizer compacts past conversations. In standard agents, this wipes out active state, causing the model to forget which ports it already scanned, re-run long fuzzing jobs, or abandon working exploit hypotheses midway through execution.

3. Hallucinated Exploits and Unverifiable Reports

When an LLM sees a database error string or a verbose stack trace, it frequently reports a critical SQL Injection or Remote Code Execution vulnerability without confirming whether the payload actually executed. In client debriefs, an engineering team will ask for the exact HTTP request and response bytes to reproduce and patch the flaw. An unverified markdown report without raw telemetry cannot be defended.

4. Silent Coverage Failures

Agents are naturally biased toward low-hanging fruit. If an agent discovers a reflected Cross-Site Scripting (XSS) parameter in the first five minutes, it will often spend hours generating variations of that single finding while silently ignoring forty other in-scope API routes, authorization boundaries, and business logic paths. When the client asks, “Did you test our checkout API?”, a conventional agent report cannot differentiate between tested and found clean versus never tested at all.

Core Pillars of the Violin Guard Architecture

Violin resolves these vulnerabilities by embedding a procedural, fail-closed enforcement engine at every critical junction of the assessment lifecycle.

+-------------------------------------------------------------------------+
|                    Violin Guard Enforcement Lifecycle                   |
+-------------------------------------------------------------------------+
|                                                                         |
|  [Written Authorization]                                                |
|            |                                                            |
|            v                                                            |
|  [Approved scope.yaml]  --------> (Blocks out-of-scope targets & ports) |
|            |                                                            |
|            v                                                            |
|  [Active PTT Phase Task] -------> (Prevents running exploit tools early) |
|            |                                                            |
|            v                                                            |
|  [Hypothesis & Skill Gate] -----> (Loads specialist playbook on demand) |
|            |                                                            |
|            v                                                            |
|  [violin_exec Guard] -----------> (AST command check & safety filters)  |
|            |                                                            |
|            v                                                            |
|  [Execution Receipt] -----------> (Signs HMAC/Ed25519 hash of stdout)   |
|            |                                                            |
|            v                                                            |
|  [Batch Review & Settlement] ---> (Validates findings against receipts) |
|                                                                         |
+-------------------------------------------------------------------------+

1. The 12 Typed Guard Tools

The violin-guard Hermes plugin exposes twelve dedicated tools that govern the engagement lifecycle:

2. AST-Based Command Parsing and Scope Admission

Before violin_exec passes a command string to the operating system shell, the guard parses the command’s Abstract Syntax Tree (AST). It extracts all hostnames, IP addresses, CIDR blocks, URLs, and target variables across pipelines, subshells, and arguments.

If any parsed target is not explicitly declared inside scope/scope.yaml, the command is halted immediately with an exit code of 1 (Blocked) or 2 (Review Required). Furthermore, dangerous shell patterns (such as recursive directory deletions, raw partition writes, or unauthorized network pivoting scripts) trigger unconditional hard blocks.

3. Signed Execution Receipts and Finding Integrity

In Violin, an offensive finding cannot exist as mere free-form text. Every finding submitted via violin_submit_finding must cite one or more signed execution receipts generated by violin_exec.

When a command completes, the guard captures:

• The exact shell command string and timestamp.
• The raw stdout and stderr streams containing the HTTP request and response bytes.
• SHA-256 cryptographic hashes of all generated evidence output files.
• A cryptographic HMAC-SHA-256 or Ed25519 signature sealing the receipt.

If an operator or an AI edits the saved evidence files after execution, the SHA-256 hash check fails and the guard rejects the finding submission. This creates an unshakeable, audit-grade chain of custody that security teams can directly share with software engineers and compliance auditors.

{
  "receipt_id": "rcpt_20260918_041289",
  "command": "curl -s -i -X POST https://api.target.internal/v1/user/reset -d '[email protected]'",
  "exit_code": 0,
  "timestamp": "2026-09-18T04:12:45Z",
  "evidence_digests": {
    "evidence/vuln-research/password_reset_response.txt": "a8f5c2d3e4b1a6c7e8f90123456789abcdef0123456789abcdef0123456789ab"
  },
  "signature": "hmac-sha256:9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e"
}

The Engagement Phase Model and State Engine

Violin organizes penetration testing into a structured seven-stage lifecycle:

SCOPING -> RECON -> VULN_RESEARCH -> EXPLOITATION -> POST_EXPLOITATION / PRIVESC -> REPORTING -> RETROSPECTIVE

Moving between phases requires an active, approved task on the Problem-To-Task (PTT) board. For example, an agent cannot run exploitation payloads while the active PTT task is registered under RECON.

+-------------------------------------------------------------------------+
|                  Disk-Persistent Engagement Directory                   |
+-------------------------------------------------------------------------+
|  $ENG_DIR/                                                              |
|  ├── scope/                                                             |
|  │   └── scope.yaml                  # Target definitions & exclusions  |
|  ├── state/                                                             |
|  │   ├── ptt.md                      # Problem-To-Task board & status   |
|  │   ├── history.md                  # Deduplicated command history     |
|  │   ├── checkpoint.json             # Serialized execution state       |
|  │   ├── coverage-matrix.yaml        # Route & parameter coverage ledger|
|  │   └── methodology-gates.yaml      # WSTG testing category checklists |
|  ├── hypotheses.md                   # Formulated vulnerability theories|
|  ├── evidence/                       # Signed receipts & raw PCAPs/logs |
|  │   ├── recon/                                                         |
|  │   ├── vuln-research/                                                 |
|  │   ├── exploitation/                                                  |
|  │   └── findings.jsonl              # Verified, receipt-backed findings|
|  ├── reporting/                      # Final executive & technical docs |
|  └── retrospective/                  # Engagement review & lessons learned
+-------------------------------------------------------------------------+

Because all state files reside on disk in human-readable Markdown, YAML, and JSON formats, Violin is completely immune to context window loss. When a large conversation is compressed by Hermes, the agent simply reads $ENG_DIR/state/ptt.md and $ENG_DIR/state/checkpoint.json to resume work seamlessly with zero loss of momentum.

35 Offensive Playbooks Across 7 Routed Skills

Rather than flooding the LLM context window with hundreds of pages of security methodologies at once, Violin implements Just-In-Time Skill Delivery. When the agent selects a PTT task, the orchestrator delivers only the specific playbook required for that immediate task:

+-------------------------------------------------------------------------+
|                      Violin Routed Skills Directory                     |
+-------------------------------------------------------------------------+
| 1. pentest (Core Methodology)                                           |
|    - Scoping, Reconnaissance, Vulnerability Research, Exploitation,     |
|      Post-Exploitation, Reporting, Anti-Automation, Supply Chain        |
+------------------------------------+------------------------------------+
| 2. web-app (Web Application Security)                                   |
|    - SQLi, XSS, SSRF, SSTI, XXE, Command Injection, Path Traversal,     |
|      Prototype Pollution, Java/Python Deserialization, NoSQL, LDAP,     |
|      XPath Injection, Input Validation Bypasses                         |
+------------------------------------+------------------------------------+
| 3. identity-auth (Identity & Access Management)                         |
|    - Authentication Bypass, IDOR / Broken Object-Level Auth (BOLA),     |
|      JWT Attacks (Algorithm None, Key Confusion), CSRF, Cryptography    |
|      Flaws, Unvalidated Open Redirects                                  |
+------------------------------------+------------------------------------+
| 4. api-testing (Modern API Security)                                    |
|    - REST Endpoints, SOAP Services, GraphQL Introspection & Batching,   |
|      WebSocket Message Manipulation & Hijacking                         |
+------------------------------------+------------------------------------+
| 5. business-logic (Workflow & Financial Abuse)                          |
|    - Workflow State Abuse, Price Manipulation, Coupon/Discount Race     |
|      Conditions, Quota Bypass, Referral Multi-Accounting Abuse          |
+------------------------------------+------------------------------------+
| 6. llm-security (AI & Agent Security)                                   |
|    - Indirect & Direct Prompt Injection, Model Context Protocol (MCP)   |
|      API Fuzzing, JSON-RPC Privilege Escalation                         |
+------------------------------------+------------------------------------+
| 7. misconfig (Infrastructure & Deployment)                              |
|    - Security Misconfiguration, Observability & Debug Leaks,            |
|      Security Through Obscurity Analysis, Default Credentials           |
+-------------------------------------------------------------------------+

Enforcing Coverage Discipline: The Anti-Skipping Matrix

A standout innovation in Violin is its formal Coverage Matrix (state/coverage-matrix.yaml).

In standard penetration tests, if an agent fails to test an API route, no record is generated. In Violin, every route specified in scope.yaml‘s coverage_obligations must be explicitly dispositioned before the vulnerability research phase is allowed to close:

# state/coverage-matrix.yaml
coverage:
  'post /api/v1/auth/login':
    status: tested
    evidence_or_reason: 'evidence/vuln-research/login_probe.txt - 401 on bad creds, 200 on valid token'
  'post /api/v1/user/password-reset':
    status: tested
    evidence_or_reason: 'H-012; evidence/vuln-research/reset_rate_limit.txt - missing rate limit confirmed'
  'get /admin/internal-metrics':
    status: blocked
    evidence_or_reason: 'blocked by scope guard: /admin subnet excluded in scope.yaml'
  'put /api/v1/profile/avatar':
    status: not_applicable
    evidence_or_reason: 'evidence/vuln-research/avatar_options.txt - endpoint disabled on target host'

The Three Closed Dispositions

1. tested: Proves that the route was actively engaged. Must cite an active evidence file or a verified hypothesis ID.
2. not_applicable: Confirms that a feature or parameter does not exist or is disabled. Must cite an execution log proving that a diagnostic probe was dispatched.
3. blocked: Explicitly documents that testing was halted by an intentional scope restriction or safety rule.

If an agent attempts to close a phase while obligations remain open, the guard halts the workflow with a detailed error:

VULN_RESEARCH cannot close - fix ALL of the following:
  - undispositioned coverage:  POST /api/v1/payments/process (no coverage-matrix cell)
  - undispositioned methodology gates:  cryptography
  - unresolved hypotheses:  H-014 (status remains Candidate without discriminator test)

Step-by-Step Walkthrough: Installing and Running Violin

Setting up Violin requires the Hermes Agent environment and a standard security distribution such as Kali Linux or Parrot OS.

+-------------------------------------------------------------------------+
|                     Violin Quick-Start Installation                     |
+-------------------------------------------------------------------------+
|                                                                         |
|  # 1. Install Hermes Agent (if not already present)                     |
|  curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash     |
|                                                                         |
|  # 2. Install the Violin Pentest Profile                                |
|  hermes profile install https://github.com/Strategic-Automation/violin  |
|                                                                         |
|  # 3. Launch Hermes with the Violin Profile                             |
|  hermes -p violin                                                       |
|                                                                         |
+-------------------------------------------------------------------------+

Step 1: Initializing an Authorized Engagement

When you start a session in Hermes with -p violin, you prompt the agent with your assessment target:

Operator: Run an authorized penetration test against api.internal.corp.

Violin automatically initializes the engagement directory and prompts for scope boundaries:

# Administrative CLI engagement bootstrap
python scripts/violin_guard.py init-engagement engagements/target_corp --host api.internal.corp

Step 2: Validating the Scope Configuration

Inspect and edit engagements/target_corp/scope/scope.yaml to confirm hosts, CIDRs, forbidden endpoints, and coverage requirements:

target:
  primary_host: "api.internal.corp"
  allowed_hosts:
    - "api.internal.corp"
    - "auth.internal.corp"
  allowed_cidrs:
    - "10.10.40.0/24"
  excluded_paths:
    - "/admin/shutdown"
    - "/billing/charge-card"
engagement:
  audit_mode: true
  require_methodology_gates: true
  coverage_obligations:
    - "POST /api/v1/auth/login"
    - "GET /api/v1/user/profile"
    - "POST /api/v1/user/transfer"

Step 3: Executing Guarded Assessments

The agent systematically records tasks on the PTT board, tests hypotheses, and executes commands through violin_exec.

# Example guarded command executed by the agent
violin_exec(
  eng_dir="engagements/target_corp",
  phase="RECON",
  command="nmap -sV -sC -p 80,443,8080,8443 -oA engagements/target_corp/evidence/recon/nmap_scan api.internal.corp"
)

If the agent attempts to target an unauthorized host (e.g., google.com or 192.168.1.1), the guard blocks the execution instantly before any packet touches the network interface.

Step 4: Generating the Final Report

Once all methodology gates and coverage matrices are dispositioned, Violin compiles an executive summary, technical vulnerability dossiers, and full proof-of-concept replay instructions into $ENG_DIR/reporting/.

python scripts/violin_guard.py generate-closeout --eng-dir engagements/target_corp

Comparison Matrix: Violin vs. Alternative Pentest Approaches

Frequently Asked Questions (FAQ)

What is Violin?

Violin is an open-source penetration testing profile for Hermes Agent that enforces scope validation, persistent engagement state, and cryptographically signed execution receipts across 35 offensive playbooks.

How does Violin prevent out-of-scope attacks?

Violin uses Abstract Syntax Tree (AST) parsing on every shell command, extracting all domain, IP, CIDR, and URL literals and blocking any target not explicitly approved in scope.yaml.

What is a signed execution receipt in Violin?

A signed execution receipt is a tamper-evident record created by violin_exec that seals the command, raw HTTP observations, exit code, and evidence SHA-256 hashes using HMAC-SHA-256 or Ed25519 cryptography.

Which LLMs work best with Violin?

Violin is model-agnostic. It performs exceptionally well with local models like Qwen 2.5 / 3.8 27B or hosted frontier models like DeepSeek V3/V4, Claude 3.5 Sonnet, and GPT-4o.

Does Violin replace human penetration testers?

No. Violin is a supervised assistant designed to eliminate repetitive scanning and documentation tasks while keeping human operators in full command of approvals, scope, and final reporting.

Summary: Elevating AI Agents to Professional Security Standards

Violin by Strategic Automation Ltd represents a major leap forward for offensive security engineering. By acknowledging the real-world limitations and failure modes of large language models, Violin replaces wishful prompt engineering with rigorous, procedural software guards.

Through AST-level scope enforcement, cryptographically signed receipts, explicit coverage matrices, and context-resilient state files, Violin proves that AI-assisted penetration testing can be fast, autonomous, and completely auditable.

73 from 9M2PJU.

Sources and Further Reading

• Violin GitHub Repository – Official source code, playbooks, and release verification suite.
• Violin Official Documentation & Landing Page – Architecture guides, guard specifications, and engineering notes.
• Hermes Agent Official Portal – Autonomous agent platform developed by Nous Research.
• OWASP Web Security Testing Guide (WSTG) – Industry-standard web application security testing framework.
• Escape Tech AI Pentesting Benchmark – Empirical evaluation methodology for agentic security tools.
• 9M2PJU Amateur Radio & Technology Portal – Open-source software, radio engineering, and security research.