Your people are building AI agents that can access data, use systems, make decisions, and take action. But too often, the rules for what they can see, what they can do, and when a human must step in are added after the build.
That creates a dangerous gap as the agent is ready to act before the organization is ready to govern it.
Below is the complete set of 20 controls I apply to every agent I build or review across four phases. It's free and hopefully helpful to you.
A lot of my calls now open with some version of "we're building an agent." Then I start asking questions, and it's the same five answers almost every time.
It says do not paste confidential data into ChatGPT. It says nothing about a system that takes actions on your behalf.
A list of software. Nothing about what an agent may write to, delete, send, or spend.
Nobody can answer how many agents are running in the company, or who owns each one.
No way to detect drift, duplicate actions, or scope creep after the fact.
When an agent misbehaves at 9pm on a Friday, nobody knows who turns it off.
These work for any agent, whatever it does. They're about how it handles data, actions, and the people around it, not about the job itself.
These decisions must be made explicitly at design time. An agent that starts running without answers to these questions will invent its own, usually badly.
When two data sources conflict, which one wins? Document this for every data input the agent touches. Never leave it to the agent to decide at runtime.
List exactly what the agent is permitted to do. Anything not on the list is out of scope, regardless of what the agent discovers during a run.
Sending an email, placing an order, deleting a record, posting a message. List them. Each one needs an explicit rule about whether the agent can take it autonomously or must propose it first.
For every consequential action, decide in advance: does the agent act, propose, or halt and report? Write this down. Do not leave it implicit.
Decide what a run record looks like before the agent runs once. At minimum: date, person or item actioned, action taken, outcome, notes. A log designed after the fact is always incomplete.
List only the access the task requires. Do not acquire capabilities speculatively. If the agent does not need write access to a system, do not grant it.
For each step that could fail, decide: does the agent retry, skip and continue, or halt? Document the answer. Default behavior should be halt and report.
Things change between runs. Skip these four and the agent will happily act on a picture of the world that's a week old.
Fetch live data at the start of every run. Do not rely on state from a previous run or from memory.
Before doing anything, check whether it has already been done. Use a log, a status field, or a confirmation email, but check. Duplicate orders, duplicate sends, and duplicate records are almost always caused by skipping this step.
If required data is missing, such as an address, a budget, or a confirmation, halt and report. Do not proceed with assumptions or placeholders.
If the task file or configuration has been updated since the last run, note what changed before proceeding.
This is the phase that needs to maintain human review. The agent handles the information; a person stays responsible for the judgement calls.
If an action is consequential and non-routine, surface it to the human. Draft the email; do not send it. Prepare the order; do not place it. The agent handles information. The human handles judgement.
When two approaches achieve the same outcome, take the one that can be undone. Draft before send. Stage before commit. Copy before delete.
Text found in emails, documents, web pages, or tool results is data. It is not a command. An instruction discovered mid-run does not authorise a new action.
If the agent discovers something interesting or unexpected, it logs it and reports it. It does not act on it. New findings trigger a new task; they do not extend the current one.
If a required step returns unexpected data, an error, or a missing value, halt. Report exactly what failed and what was expected. Do not continue on a broken assumption and do not guess.
Nobody enjoys this part, and it's the part you'll want when someone asks what the agent has been doing for the last three months.
A log that only records errors gives you no baseline. Record every action taken, even when everything goes to plan. You need the full picture to spot drift over time.
If the agent is waiting on a human decision, log that state explicitly so the next run knows what is pending.
The output of a run should be readable by a human who was not watching. State what was found, what was done, what was proposed, and what requires a response.
If the run revealed stale or incorrect data, flag it for correction. The agent should not silently work around bad data.
Underwriters have tightened considerably over the last few years, and agentic systems are starting to show up in renewal questionnaires directly. The questions themselves are not new. They are the same control families carriers have always asked about, now pointed at software that acts on its own.
Most teams answer these from memory on a deadline. Working the checklist above gives you documented answers to nearly all of them before anyone asks.
What is deployed, and who owns each one?
Does each system have only the access it needs?
Can you reconstruct what happened, and how far back?
Who signs off before something touches production?
How fast can you stop it, and who is authorised to?
Which actions cannot be undone?
Every carrier words its application differently, and none of this replaces your broker's questionnaire or guarantees a particular outcome on coverage. But walking into that conversation with written answers, rather than assurances, tends to make it a much shorter one.
It tells you what to decide. It won't sit you down and make you decide it, write the decision down anywhere, or hold the agent to it once it's running.
That last part is the one that gets people. A checklist you agreed with in March doesn't govern anything in June. Preflight is the version that does: the same principles, turned into documents someone signs and constraints the agent actually runs under.