Build your hackbot, part 1: architecture

A hackbot is a small program that puts a language model in a loop with tools, so it can run part of your recon and testing by itself and stop for your approval before anything touches a target. This is the first of three posts that build one. This one is the design. Part two writes the code, and part three connects it to shared tools and the editor. If agents are new to you, read what are AI agents and tool use first.

#What a hackbot is, and is not

A hackbot automates the boring, repeatable middle of the loop: run a recon command, read its output, decide the next command, keep notes. It is not an autonomous attacker, and you should not build one. The value is a tireless assistant that proposes steps and records what it did, with you holding the decisions and the keyboard for anything that sends traffic.

#The four parts

Part	Role	In this build
Model	Reads output, plans, calls tools	The NotHoly OpenAI-compatible API
Tools	The things it can actually do	Shell commands you allow, plus research calls
Memory	What it remembers across steps	The message list, plus a notes file on disk
Guardrails	What it may not do	Scope check and approval before every command

The model does no acting on its own. It reads, plans, and asks to call a tool. Your code decides whether to run that tool. This split is the whole design: the model is the brain, your code is the hands, and the hands ask permission.

#The agent loop

The loop is short. You send the model the goal and the tools it may call. The model answers either with text or with a request to call a tool. If it asks for a tool, your code runs it, after your approval for anything that touches a target, and sends the result back. The model reads the result and decides the next step. This repeats until the model says it is done or you stop it.

The model you use is your choice from the catalog. List the models with GET /v1/models and pick one that supports tool calling and a context large enough for your notes. The code never hardcodes a model name; it reads one from configuration, so you can switch without touching the loop.

#Guardrails that keep it in scope

Two guardrails matter. The first is scope: before any command runs, check its target against the program's scope and refuse or pause on anything outside it. The second is approval: a command that sends traffic waits for your yes. These are not optional extras; they are the reason the thing is safe to run.

A third guardrail is quieter and just as important. Tool output is data, not instructions. A page or a scan result can contain text that reads like a command to the model, and a naive loop will follow it. The OWASP Top 10 for LLM Applications calls this prompt injection, its top risk. Your loop must treat every tool result as untrusted input and never let it widen what the agent is allowed to do.

#Why it runs on your machine

The agent runs on your machine so that every request leaves from your address, every command is yours to approve, and every log is yours to keep. The model runs on the NotHoly API, which does inference and nothing else: it never scans or sends traffic to a target. That division is what makes the agent usable for bug bounty. The traffic comes from where the program expects it, and you can prove what you sent.

#What to build and what to reuse

Build the loop and the guardrails yourself, because they are small and because you need to understand them. For the tools, reuse what exists: the shell you already have, the research tools the NotHoly CLI exposes, and later the shared tools of MCP. Do not write a framework. The next post is about a hundred lines of Python.

#Next in this track

Part two codes the loop with tool calling, approval, and notes, using the Model Context Protocol later in part three.