The checklist before the agent.

Before I let an agent anywhere near a real workflow, I run a checklist. It didn’t come from an AI paper. It came from the National Institute of Standards and Technology cybersecurity framework — six functions security teams have used for years — because it turns out “a new employee made of software” and “a new risk in your environment” are the same shape.

Translated out of security language into operator language:

Govern — who owns this thing? Not “which team”. A name. Who approves changes to it? What is it allowed to do, and — more useful — what should it never be allowed to do? An agent without an owner is an incident with a delay on it.

Identify — what can it touch? Which systems, which data, which tools. If you can’t list them, you don’t have an agent, you have a surprise.

Protect — who trained the humans? Can you control what the agent sees and who it talks to? Do the people around it know what it can and can’t do? Most agent failures I’ve seen were really expectation failures.

Detect — would you know? If the agent starts doing something unusual, is anyone looking? “We’d notice eventually” means no.

Respond — what’s the plan for the bad Tuesday? Something goes wrong. Who gets told, who can stop it, how fast?

Recover — can you undo it? Could you restore the data, replay the queue, unpick the actions? If an action can’t be undone, it should have needed a human in the first place.

If the agent only drafts and suggests, this list is light work. The moment it can read customer data, update a system or send something into the world, every one of these questions earns its place.

None of this is meant to slow anyone down. It’s meant to let you speed up without flinching — because you know who owns it, what it touches and how it stops.

Try this

Try it: the Agent-Ready Audit turns this thinking into ten questions you can run on one workflow in five minutes. Its scoring refuses to let a good total cancel a missing boundary — that’s deliberate.