Pre-deployment control

Can you stop the exact agent run when it matters?

Before an agent runs unattended, make sure you can stop the exact run, close its authority, retain what happened, and prove the stop worked.

This checklist is a design and testing aid, not a claim that a button alone can contain an agent or repair a compromised environment.

Five steps

Build a stop control that is specific, testable, and useful under pressure.

1

Name the stop owner

Assign a primary and backup person who can stop a run. Record when they may act and how they reach the control.

Why it mattersAvoid a control that exists only in documentation or only one person can operate.

2

Bind the request to one run

Require the stop request to name the exact active session, expire quickly, and reject a replay.

Why it mattersDo not use a permanent, broad stop token that can affect unrelated work.

3

Close authority first

Make the shutdown sequence revoke or close connectors, queued jobs, and delegated credentials before process termination.

Why it mattersStopping a visible process alone may leave work or access active elsewhere.

4

Prove the path in a safe fixture

Use a synthetic job to verify invalid, expired, mismatched, and replayed requests are rejected and that shutdown stays within a deadline.

Why it mattersDo not first discover the shutdown order during a live incident.

5

Keep a restrained receipt

Retain a timestamped, privacy-reduced record of the request, outcome, and follow-up owner. Review it before restarting.

Why it mattersA log should support recovery without copying sensitive prompts, repositories, or identities unnecessarily.

Useful related work

Make the plan observable.

Primary sources checked 2026-07-31

These sources inform the control principles here. They do not certify a specific product or deployment.

Start with your actual access

Map the authority before an agent needs to be stopped.

A CapitalGuard scan helps inventory the connections and access that a stop plan must account for.

Run a scan