Most teams answer from memory. "We had guardrails." "The system prompt tells it not to touch prod." "We'd have caught it." All of these might be true. None of them is something you can show anyone.

There's also some new pressure behind the question. The Hawley/Murphy AI agent accountability bill was introduced on Oct 1. It is not law, and it may never be. The phrase "reasonable safeguards" comes up in the conversation around it, but nobody has said what counts. When the definition is that vague, the only thing you control is your own record: what you checked, when you checked it, and who did it.

This isn't legal advice. It's an engineering habit, and one you'd want anyway the first time an agent does something weird at 2am.

The template

One page per agent. Copy it into your repo as EVIDENCE.md, paste it into a doc, or print it and write on it. The rule that makes it work: if you didn't run it, leave the row blank. A blank row tells the truth. A backfilled date doesn't.

Operator Evidence Log

Agent / system: __________ Env: __________ Owner: __________

1. Network / tool allowlists

What the agent can reach: domains, DNS record types, tools, write scopes. Review again whenever the surface changes.

2. Kill-switch / auto-stop tests

3. Incident timestamps

4. Credentials held outside the agent workload

One row per review, test, or incident.

How to fill each section

Allowlists

Write down what is actually allowed, not what you meant to allow. Pull it from the config or the egress policy that's live, then record the commit it came from. Each time someone adds a tool or a write scope, that's a new row.

A bad entry:

"egress restricted" | Q3 | team | n/a | looks fine

A good entry:

api.payments-sandbox.test (write: refunds), mail.internal (send: templated). Removed pastebin.com, *.githubusercontent.com. Metadata IP 169.254.169.254 denied | 2026-09-30 | oncall | a19f03d | 14 entries down to 9

The good one can be checked. Someone can open commit a19f03d and see whether it matches.

Kill-switch tests

The trap here is testing the stop on an idle agent. An idle agent always stops. That test tells you nothing.

Run it with work in flight. Queue a few tool calls, fire the stop, and measure two numbers: how long until the agent halted, and how many calls executed after you hit stop. Pass means zero calls after stop.

Here's an illustrative sandbox example of why the second number matters. The stop flag gets checked between plan steps. A batch of three calls was queued before the stop, so those three calls run anyway, spread over about 40 seconds, before the next step boundary reads the flag. If you only measure "did it eventually stop," that test passes. Moving the check into the tool executor, so it runs before every individual call and cancels whatever is pending, gets you to zero calls after stop and a time-to-stop in the hundreds of milliseconds.

def run(call):
    if stop_flag.is_set():
        batch.cancel_pending()
        raise Halted(call.id)
    return call.execute()

A bad entry:

Sept | manual | fast | pass | worked

A good entry:

2026-09-24 14:02:10 | API /stop, 3 calls queued | 412 ms | pass | 0 calls after stop, commit 7c41e2a

Incident timestamps

Detected, alerted, stopped. The gap between detected and stopped is your exposure window, and it's the number people will ask about first. Write the timestamps down the same day, from logs if you can. Times reconstructed a month later from Slack scrollback are mostly guesses.

Also write down what was touched. "Sandbox ledger table, 11 rows" is useful. "Some data" is not.

A bad entry:

afternoon | ? | ~15 min later | someone | db | fixed

A good entry:

14:31:05 | 14:31:40 | 14:32:02 | on-call via pager | sandbox ledger, wrong table, 11 rows | PR to scope writes by table, ticket OPS-212

Credentials outside the workload

If the agent process can read a credential, the agent can use it in ways you didn't plan for. That includes passing it to a tool you didn't expect, or writing it into a log. Record where each credential lives and confirm it isn't sitting in the agent's environment.

A bad entry:

yes | secure | | | should be ok

A good entry:

yes | payments key in vault, fetched by the tool proxy, not in agent env | 2026-10-02 | oncall | checked env inside agent container, no secrets present

Why bother if it's not required

Because every time this comes up, the conversation is the same. Someone asks what you had in place, and the honest answer is a shrug plus a few vague claims. Four short tables turn that into dates, commits, and numbers. It takes maybe ten minutes per review, and the kill-switch test is the only one that takes real setup.

Start with the kill-switch test. It's the one most likely to surprise you.

Disclosure: I sell the full Agent Debug Checklist ($19), and this log is page 8 of it: https://marshalleet6.gumroad.com/l/hgkgsa