ReadBeforeRunAgentic Security Field Guide

For security leaders

Updated 2026-10-19Draft · awaiting review

The Field Guide reads every AI security tool three ways: what its author declares, what its code can do, and what it did in one lab run. For a security leader, three numbers at the end of this page carry the message: how many tools declare nothing about their rights, how many have code that reaches secrets, persistence or admin rights, and how many of the tools we ran used more than they declared.

What the distribution means

  • Silence is the normal case. Most agent skills today say nothing about the files, hosts, programs or credentials they will touch. Approving such a tool means approving rights nobody has written down.
  • The code sets the ceiling. The reach level comes from the code because that is the boundary you sandbox against. A quiet lab run does not lower it.
  • The lab shows the gap. When a tool does more than it declared, that gap is the finding: used above declared. It is independent of whether the agent is in your inventory.

Five questions for every agent vendor

  1. Which files, hosts, programs and credentials can the agent reach, and where is that declared in machine-readable form?
  2. Which actions run without a per-action approval, and how do I narrow the pre-approvals?
  3. Which hosts does the agent contact at runtime, including telemetry, and can I restrict it to an allowlist?
  4. What survives a run: caches, configuration changes, installed packages, new skills or agent configuration?
  5. Is each release pinned to a commit or package hash, and how do I learn that a new version changes the rights?

Minimum rules for onboarding agents

  1. No agent without a declaration of its rights; where the vendor declares nothing, measure the task scope yourself before approval.
  2. Run agents with an egress allowlist; an undeclared host is a finding, not a default.
  3. Pin the version you approved; a new major version is a new approval.
  4. Keep approval events on: modes that bypass approvals are not allowed in production.
  5. Keep credentials scoped to the task: one token per service, no wholesale environment access, no credential stores.

Read further

The method explains the scale and every rule. The catalog shows each tool as a card with its run advice; the record below each card holds the six rights with their evidence. A German version of this page is at /de/.

//01 The numbers behind the catalog

1 of 20

tools say nothing about what they may access: no files, hosts, commands or secrets are named anywhere.The author names no files, hosts, commands or secrets anywhere. In the method this is “declares nothing”.

Show them

12 of 20

tools contain code that can read stored passwords or tokens, change your machine permanently, or use admin rights.The code contains paths that reach the highest level of a right: credential stores, autostart or users or keys, sudo or the Docker socket. In the method this is “code level 3”.

Show them

2 of 3

tools we ran did more than their description says.In the lab run the tool used a right its description does not name, for example a host the documentation never mentions. In the method this is “beyond declared”.

Show them

20 tools in the catalog · 3 run in our lab · 25 candidates reviewed, 5 not listed. Not listed? Ask us why at hello@readbeforerun.ai and we answer with the criterion and its evidence.

The scale behind the numbersThe six rights a tool can take (files, network, execution, secrets, persistence, approval), each read three ways and rated 0 to 3. 0 never means safe; “?” means no evidence.

  1. 0 containedreads only what you give it
  2. 1 scopedits task and its target, nothing beyond
  3. 2 openwrites, executes, reaches the open network
  4. 3 privilegedtouches secrets, persistence or admin rights
  5. ? unknownno evidence, never zero

Six rights per tool: files, network, execution, secrets, persistence, approval. Red means run isolated, not bad. 0 never means safe.

  • Three readings. Every tool is read three ways: what the author says, what its code shows, and what it did in one lab run.
  • The level. The highest value found in the code (0 to 3) is the ceiling: the value you build your sandbox against. A quiet lab run does not lower it.
  • The lab. One run shows whether the tool stayed within what its author says. Declarations are often incomplete and scanners can be bypassed, so we run each tool once and compare.

Highest level found in the code, over 20 tools

0 contained 01 scoped 02 open 83 privileged 12? unknown 0

Did more than their description says, in the lab