The policy sits in a document. The agent runs in a runtime. Nothing connects them, so the agent never actually reads the policy it's supposedly governed by.
Here's the whole checklist I run against every agent I build or review. 20 controls, four phases. No email gate, no PDF, no call required. Take it and use it. If you think I've got something wrong, I'd like to hear it.
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.
None of this is a knowledge problem. Hand a team the checklist below and they'll nod along to every line of it. Then they build the agent the following week and none of it makes it into the build. That's the actual failure, and it's a boring one.
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 where a small mistake turns into an expensive one. Everything here is about keeping that from happening.
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.
I've watched deals stall because a security team couldn't get comfortable. The technical folks loved the demo. Legal killed it anyway. What I've learned from those calls is that security isn't really asking whether your agent works. They're asking how bad it gets when it doesn't.
So give them a number. A limit reads as someone who's thought it through. An adjective reads as someone who hasn't.
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.