Method

Updated 2026-10-30 · version 0.1Draft · awaiting review

Why you need this: Read Before Run

The problem. New AI tools for security work appear every week: AI agents, skills and MCP servers. Which one fits your task, what it needs and what it touches is buried in READMEs and source code. You read it all by hand, or you run the tool blind, with the rights of your agent.

What is done here. One page per tool, and every page answers the same questions: what it does and is good for, what it needs, how it runs, who maintains it, what else does the job. Then what it can reach: which files, which hosts, which commands, which credentials, what it leaves behind, whether it asks first. Each is read three ways: what the author declares, what the code shows and, once we have run it, what it did. Where we have used a tool, our notes say where it fits, and where not, marked as ours. Every fact links to its file and line; what was not found stays unknown, never zero.

What you get. The right tool in minutes, on facts instead of marketing: compared side by side per task, with one word on how to run it and evidence you can check. Read before run.

Real entry · MCP serverreach 3 · privileged
332?1?FilesNetworkExecutionSecretsPersistenceApproval
HexStrike AIRun isolated

MCP server that lets an agent drive more than 150 offensive security tools through a local API server, including arbitrary shell commands.

Can write system paths · tunnel or exfiltrate · run shell commands or eval · Secrets, Approval: no evidence

by 0x4m4 · checked 2026-10-24 at d689933 · not run yet Draft · awaiting review

  1. Reach word. The highest level its code reaches, 0 to 3, and its word: what the tool can reach, in one glance.
  2. Plate. Six rights, one spoke each: files, hosts, commands, credentials, what it leaves behind, whether it asks first.
  3. Points. Each carries its digit from the code; dashed means the code showed no evidence, and that never counts as zero.
  4. Chip. The one word on how to run it when a verdict exists, else “Code shows”. No tool is ever called safe.
  5. “Can” line. The worst findings as verbs. The entry page holds the full table: author says, code shows, run showed, every value with its file and line.
  6. Meta line. Who maintains it, when it was checked at which commit, and whether it has run in our lab.
  7. No notes of ours on this tool yet; they appear in the record once we have used it. The record

What is checked

Every tool gets one page, and every page answers the same questions in the same order, so two tools can be read side by side.

What the tool is. What it does and what it is good for. What it needs: accounts, keys, runtimes. How it runs: inside your AI client, on your machine, in a container, or outside. Who maintains it, and what else does the job.

What the tool can reach. Six rights, each one a question:

Right The question
Files Where does it read and write?
Network Whom does it talk to?
Execution What does it run?
Secrets Which credentials does it touch?
Persistence What survives the run?
Approval Does it ask before acting?

Each right gets a level: 0 contained (reads only what you give it), 1 scoped (its task and its target, nothing beyond), 2 open (writes, executes, reaches the open network), 3 privileged (touches secrets, persistence or admin rights). The highest level is the tool’s reach. It is a ceiling, not a judgement: a pentest agent with a shell and network honestly lands on 2.

Three readings, kept apart. Each right is read three ways: what the author says (manifest, README, annotations), what the code shows (a static reading at a pinned commit) and, once we have run it, what the run showed in our lab. Declarations are often incomplete and scanners can be bypassed; that is why there are three. The reach always comes from the code, because that is what you sandbox against. A run shows what happened, not what is possible, so it never lowers the reach.

Two rules that never bend. Zero never means safe. “?” means no evidence was found, and that never counts as zero.

Which tools get in. An open licence, a commit in the last six months, at least two weeks old, a documented install path, pinned to one commit, a static scan passed or with its finding explained. Models, closed products and tools with a malicious finding stay out. A tool that misses one of these is not listed. Placement, badges or fast tracks are not for sale.

How to use it

Start from your task. The tasks page lists the jobs. Each task page sets the tools for that job side by side: how each one runs, what it needs, where it sends data, what it can change.

Read the card. Every entry opens with a card. The plate draws the six rights from the code; the reach word sums them up; the “Can” line names the worst findings as verbs; the chip gives one word on how to run the tool:

  • Run isolated when the default setup does one of five things: accepts connections from other machines without a login; runs commands the model chooses without asking; reads other programs’ credentials and can send them to hosts nobody named; runs hostile input by design; or installs something that starts on its own.
  • Restrict first when the code shows a right at level 2 or 3, or a right is unknown, and a setting can contain it.
  • Keep confirmations on when nothing above scoped rights was found. It is not a safety rating.

Without a verdict the chip reads “Code shows”, and the plate is all you have. No chip is green, and no tool is called safe.

Check the evidence. Below the card, the record holds every value with its file and line at the pinned commit. “Not found in the files read” means someone looked; “not read yet” means nobody did. Where we have run a tool, the record says whether it did more than its author declared, right by right, with the log lines. Our own notes, where we have used a tool, are marked as ours and change no value.

Before you run. The advice box lists the steps before first use; each step names the right it closes or contains. The install block gives the command at the pinned commit.

Dispute a value. Anyone can dispute a value with evidence (file, line, commit) at hello@readbeforerun.ai. A changed value is logged on /changes/; a stricter word is published only after a 14-day window, and corrections stay visible on the page.

Limits

  • One run is an observation, not a benchmark.
  • Server-side behaviour of remote MCP servers stays “?”.
  • The lab is not your production environment.
  • Static analysis can miss behaviour that appears only at runtime; that is why the run exists.

The rules

What each level of each right means, where the three readings come from, how a lab run is read, how the one word is derived, the inclusion criteria in full and the evidence format: Rules of the method v0.1. The changelog lives there. The term behind the comparison has its dated definition under Agent Privilege Surplus, in German under Schatten-Administration.

Cite as

Ilja Schlak. “Method v0.1”. Agentic Security Field Guide, 2026. https://readbeforerun.ai/method/