Hermes AI Agent for Automated Penetration Testing: A Deep Dive into Skills, Memory, and Cron Jobs

A systematic, hands-on tutorial for AI agent automation in penetration testing and bug bounty hunting has long been missing. This practical walkthrough of the Hermes Agent — originally shared on Bilibili — fills that gap, covering everything from cloud deployment and Telegram integration to building custom Skills, training persistent Memory, and using Cron Jobs for round-the-clock asset monitoring.

One important disclaimer upfront: every technique discussed below should only be applied to authorized penetration testing, bug bounty programs, or your own lab environments. Any unauthorized scanning or attacking is illegal.

Why Hermes Agent Instead of a General-Purpose Chatbot

The author directly compared Hermes Agent with general coding assistants like Claude Code and Codex, and the core difference comes down to the Memory mechanism.

General-purpose LLMs exhibit noticeable "forgetting" over long sessions. As the author puts it, "Claude Code on day 30 won't be the same as on day 1" — context window limitations cause it to gradually lose rules and conventions established early in the conversation. Hermes Agent is designed to grow alongside the user: when you tell it "my name is Zach," it displays updating memory and writes that information into a persistent memory layer. As usage accumulates over days and weeks, it gradually learns your questioning habits, workflows, and vulnerability-hunting methodology — reducing the overhead of re-feeding instructions every session.

This is especially critical for penetration testing. Vulnerability research is a long-term, methodology-accumulating process. An agent that remembers your preferences and can reuse your historical tactics is far more productive than a conversation window that starts from scratch every time.

Environment Setup: From VPS to Telegram Integration

The infrastructure for this setup is straightforward, but a few key steps deserve close attention.

Deploying to a Cloud VPS

The author chose a VPS as the Agent's "home" — because the agent needs a persistent, command-capable environment. The demo configuration uses 2 vCPUs, 100GB storage, and Ubuntu, which is sufficient to run Hermes Agent. The deployment process is standard: purchase a VPS → copy the IP → connect via SSH (ssh root@<IP>) → copy the install command from the Hermes website and run it.

Configuring the LLM Backend

Two paths are available for model integration: use the Hermes official portal (NewResearch) with a unified API Key to call multiple models after topping up credits, or connect a third-party aggregator (similar to OpenRouter) to switch between DeepSeek^Ad, Opus, OpenAI, and other models — including some free options.

The author's actual setup is using DeepSeek V4 Flash for vulnerability discovery and a stronger model for validation — this division of labor is covered in detail below. It's worth noting that free models are not recommended for serious penetration testing tasks.

Telegram Remote Control Integration

Hermes supports multiple chat interfaces including Telegram, Discord, and WhatsApp — the author prefers Telegram. The manual integration flow is: find BotFather on Telegram → create a new bot → copy the generated API Key → enter it in Hermes → then bind your own user ID to restrict control access.

One security warning here is critical: the Bot's API Key is equivalent to your VPS password. Anyone who obtains it can take over your Agent — keep it strictly confidential.

Telegram Bots receive messages via long polling or Webhooks through the Telegram Bot API. BotFather is Telegram's official bot management interface — all bot creation, token issuance, and permission configuration goes through it. The generated Bot Token looks like 110201543:AAHdqTcvCH1vGWJxfSeofSs4tq09sFDoje, where the first half is the Bot ID and the second half is the secret key. If leaked, an attacker can directly control bot behavior via APIs like sendMessage. Binding a "user ID whitelist" matters because Telegram Bots are visible to any user by default — without restrictions, anyone who knows the bot's username can send commands. User IDs can be looked up via tools like @userinfobot, are purely numeric, differ from usernames, and cannot be forged — making them an effective access control mechanism.

Core Capability: Building and Learning Skills

Skills are the "brain" of this entire setup — essentially a structured instruction set you define for the Agent. The author covers three ways to build Skills.

Three Construction Approaches

The first is conversational generation: hand your HackerOne API Key directly to the Agent, let it pull your historical XSS or IDOR submissions, auto-summarize them, and generate a custom Skill — effectively distilling your real-world methodology into a reusable capability.

The second is manual paste: if you've accumulated Skills in Codex or Claude Code, you can copy them directly into New Skill.

The third — and the author's most recommended — is the Learn Skill feature: feed the Agent URLs from high-quality technical blogs, HackTricks pages, or public HackerOne disclosure reports, click Learn, and it crawls those pages and automatically distills a complete skill document. The author specifically warns against using Medium articles: "they sometimes lie or are too vague." Stick to genuinely high-quality vulnerability technical resources.

The Learn Skill feature works by crawling target URLs and extracting content — conceptually aligned with Retrieval-Augmented Generation (RAG): converting unstructured external documents into structured knowledge the Agent can invoke. HackTricks is the most widely referenced penetration technique knowledge base in the security community, organized by vulnerability type and protocol, with content battle-tested through extensive real-world use. HackerOne's public disclosure reports contain complete attack chains on real targets and represent some of the highest-quality methodology sources available. By contrast, content platforms like Medium lack peer review mechanisms and are prone to technical inaccuracies or exaggeration — training Skills on them can introduce flawed testing logic, causing the Agent to produce invalid or harmful operation sequences in real engagements.

What a Good XSS Skill Looks Like

The author spends considerable time critiquing a common beginner mistake: dumping a one-liner command into the terminal (mass-replacing parameters with qsreplace + detecting reflections with httpx) and expecting to find XSS. The problem is clear — blindly injecting large numbers of payloads triggers WAFs, gets your IP blocked, and even if the target has a real vulnerability, you won't be able to test it.

His recommended approach is a layered, progressive flow:

1. First check if Content-Type is text/html — injecting HTML into a JSON endpoint is pointless and just exposes your activity;
2. Test reflection with a unique marker — inject xyz or zac to see if it gets reflected into the DOM;
3. Inject HTML code first to determine if HTML injection exists;
4. Then progressively escalate to XSS — add event handlers like onerror or onhover to trigger confirm(1).

This "recon first, then escalate" logic is what elevates a Skill from "finding basic XSS" to "finding advanced XSS" — and all these details need to be explicitly written into skills.md.

Using a Separate Model for Result Validation

AI will inevitably produce false positives. The author's solution is a dedicated validation Skill — using a different, stronger model to double-check findings. His combination is DeepSeek V4 Flash for discovery and DeepSeek V4 Pro or Opus for validation, with the emphasis that even when AI declares something "100% a vulnerability," a human must still manually verify.

Each confirmed finding generates structured output: JSON, a Markdown report, and most importantly a finding.html proof-of-concept file. This PoC can be sent directly to the bug report reviewer (triager), who only needs to open the HTML to automatically reproduce the issue — the demo shows an auto-submit PoC for a POST-based XSS, dramatically reducing communication overhead between both parties.

False positive problems are especially prominent in AI security tooling, fundamentally because large models rely on pattern matching rather than truly understanding the semantics of HTTP context. A typical false positive scenario: the model sees the injected string appear in the response body and concludes "reflection successful" — but the string may actually be HTML entity-encoded (< becomes <) or JavaScript string-escaped, and would never execute in a browser. This is precisely where dual-model validation earns its value: the first model acts as a "scout" — casting a wide net, tolerating false positives to ensure coverage; the second, stronger model acts as a "judge," applying stricter contextual reasoning to candidate findings. This pipeline design strikes a balance between cost and accuracy — stronger models cost more to run, making full-pipeline deployment prohibitively expensive, while concentrating them in the validation stage delivers the best cost-effectiveness ratio.

Composition and Automation: Web Scan and Cron Jobs

Using a Master Skill to Orchestrate Sub-Skills

When a target requires coverage beyond just XSS — including IDOR, SSRF, LFI, and broken access control — the author's approach is to build an orchestrating Skill called web scan that invokes sub-Skills like XSS and IDOR.

The key is having the Agent intelligently select strategies based on asset characteristics: after crawling a page, if it sees id or email parameters, prioritize testing for IDOR; if it sees parameters like url, redirect, or file, focus on SSRF or LFI. The complete web scan flow is broken down as: scope → surface → route → load playbook → confirm → report, with a mandatory confirmation step built in at the end.

Cron Jobs: Capturing the Time Advantage on New Assets

This is the most practically valuable part of the entire setup. The core logic of bug bounty hunting is "the money is in new assets" — when a target launches a new subdomain or new asset, the first person to act is the one who earns the bounty.

Cron Jobs fully automate this: you can schedule a recon task to run every night at midnight, having the Agent run a target through the recon skill (configurable with subfinder, assetfinder, or paid APIs), compare newly discovered subdomains against a historical list (e.g., x.txt), and the moment a new subdomain appears, automatically trigger a web scan and push an alert via the already-integrated Telegram/Discord.

This applies equally to commercial client engagements: schedule weekly or monthly security checks, automatically generate PDF reports, and deliver them to clients or hold them for your own review before handoff. The author's personal setup is "scan specified targets every 24 hours + check for new assets every night at midnight," with all findings aggregated into a unified Dashboard.

Cron is the built-in task scheduler for Unix/Linux systems. Its syntax consists of five time fields (minute, hour, day, month, weekday) followed by a command — for example, 0 0 * * * means execute every day at midnight. In bug bounty asset discovery, it's commonly paired with tools like subfinder (passive subdomain enumeration) and assetfinder (certificate transparency and multi-source DNS queries). The core logic is incremental comparison: diff each enumeration result against a historical baseline file and only trigger downstream scanning for new entries, rather than doing a full rescan every time — this conserves computing resources and avoids triggering rate limits or bans by frequently hitting known assets. For bug bounty purposes, program targets are most defensively exposed in the 24–72 hours after a new asset goes live; automated monitoring can systematically capture this time window.

Practical Value and Risk Considerations

The real value of this Hermes Agent setup isn't any single feature — it's the way it chains persistent memory + structured Skills + dual-model validation + scheduled automation into a complete vulnerability-hunting pipeline. It addresses two persistent problems in AI-assisted security testing: context forgetting and the lack of reusable, accumulated methodology.

But its limitations must also be acknowledged soberly: AI false positives still require human oversight, and the author repeatedly emphasizes "never unconditionally trust AI judgment"; misconfigured automated scanning is likely to trigger WAF blocking; and most importantly, all operations must remain strictly within authorized scope. The right way to use this is as a lever that amplifies your own methodology — not as a black box that replaces professional judgment.