Controlled AI agents
Before an AI Agent Takes Action, Write Its Operating Rules
A practical operating brief for an agent’s authority, evidence, approvals, exceptions, and recovery.
An AI assistant that summarizes a report has a different responsibility from one that changes an order, emails a customer, or publishes a product record. Once software can act, a misunderstanding can leave the conversation and become a business event.
Before granting that authority, write down the job in operational terms. Define the allowed actions, approved data, limits, human decisions, completion evidence, and recovery path. Then enforce those boundaries in the tools and systems the agent uses.
Begin with a narrow job
“Help sales” leaves too much undefined. “Prepare a daily list of open quotes needing review, using these fields from these accounts, for this sales manager” provides a workable starting point.
The first version may only read and prepare. Sending messages, changing records, or making commitments can be added as separate decisions when the business has evidence that the workflow is ready. A model’s ability to call a tool does not establish that the business should authorize it.
OWASP describes excessive agency as a risk arising from too much functionality, permission, or autonomy. Its guidance supports limiting tools and privileges and requiring human approval for consequential actions. The operating brief below translates that principle into questions a business owner can resolve.
Write an operating brief the team can inspect
- Purpose: What work should be completed, for whom, and under what trigger?
- Sources: Which systems, accounts, records, and fields may the agent read?
- Authority: Which actions may it perform, and which must it only propose?
- Limits: What volume, cost, time, recipient, or record boundaries apply?
- Approval: Who can approve an action, and what exact content or change must they see?
- Exceptions: What causes a stop, and who receives the unresolved work?
- Evidence: What record demonstrates the actual action and outcome?
- Recovery: Who can disable access, investigate, and restore normal operation?
Keep the brief close to the people operating the process. A useful rule is specific enough to test. “Be careful with customer information” needs to become a defined set of allowed records, destinations, and retention practices.
Put the boundary outside the prompt
A prompt can explain the job, but permissions and action checks should be enforced independently. A read-only integration should lack the ability to update records. A tool for preparing a message should not quietly include a send operation. Verify the target company, record, recipient, and authorization again at the point where a consequential action would occur.
Approval needs to attach to the specific action. If the message, destination, amount, or affected record changes materially after review, the earlier approval should not silently carry over. A reviewer should see enough context to make a real decision, including supporting evidence and uncertainty.
Set boundaries on retries as well. A timeout after submission may mean that an action completed but its response was lost. Check the receiving system before trying again, and design duplicate protection where supported.
Treat retrieved text as information
Agents may read emails, documents, websites, and uploaded files. Those materials can contain instructions aimed at the agent, including malicious instructions. They should not gain authority merely because the agent encountered them while doing a legitimate job.
OWASP’s prompt-injection guidance discusses this class of risk. No single wording trick eliminates it. Reduce exposure, separate untrusted content from instructions, validate tool inputs, and limit what a compromised step could do.
A supplier document asking the agent to send internal customer data to a new address is not an authorized business instruction. The process should stop that action and surface the conflict to the appropriate person.
A hypothetical quote-follow-up agent
Illustration only: A distributor wants a daily review list of quotes that have had no recorded activity for an agreed period. This example describes a possible operating boundary, not a deployed customer agent.
The agent can read selected quote fields and prepare a list for the sales manager. Each entry includes the record link, last activity date, and reason for inclusion. It cannot change prices, mark a quote lost, access unrelated accounts, or contact customers.
If the source is unavailable, it reports an incomplete run with the last successful check. It does not issue a clean bill of health from stale data. If the manager later authorizes draft follow-up emails, sending remains a separate capability with its own review and evidence requirements.
Test failures before expanding authority
Test an ordinary request, ambiguous identity, an unauthorized record, stale information, malicious text in a retrieved document, a tool failure, and a partially completed action. Confirm both what the agent should do and what the system must prevent.
Maintain an action log with appropriate access controls and retention. Include source references, proposed and approved actions, the identity used, timestamps, result references, and exceptions. Avoid collecting secrets or unnecessary personal data in the name of auditability.
Review results with the process owner. Expand authority only when the evidence supports that particular expansion. A controlled agent should leave the business able to explain what happened, stop it when needed, and finish the work safely when automation cannot.
Sources & further reading
Primary references checked October 7, 2026. The practical recommendations and hypothetical examples are Wheeler IS editorial guidance; they are not customer results or vendor endorsements. Product capabilities and requirements can change.