What Is Your AI Agent Allowed to Decide?
Take a hypothetical B2B technology company with a delivery-support agent in pilot. A customer has asked whether their promised delivery date still holds. The agent has read the CRM, found that engineering's plan now shows a later date, and drafted an email with the new one. In the pilot environment, it can also demonstrate updating the internal plan and sending that email.
Before those connections reach production, the company needs to decide which actions are permitted. Sending the email would make a new promise to the customer, and the company hasn't decided who is allowed to make that promise on its behalf, let alone whether software is. Earlier in the series, mapping this workflow showed how much of it depends on an experienced delivery lead's judgment. The company now needs to decide which parts it can express as rules and which decisions still need a person.
What the system can attempt
For this article, I use "agent" to mean a system in which the model chooses its own steps and tools, as distinct from a workflow that follows a fixed path. Anthropic's guidance on building effective agents draws a similar line. That flexibility is the reason to use an agent, and it is also why a task description and a tool list don't define its role.
A goal and tool access describe what the system can attempt. They do not establish what it can do reliably or what the business has authorized. Reliability is a question for testing. Authorization is a management decision, and it belongs before the tools are connected in production. Delegating an action to software does not transfer the organization's accountability to it.
Three operating states
The mandate I would write for this agent puts every action in one of three states.
Allowed when defined checks pass. The agent may gather evidence from accounts assigned to the workflow, compare dates, draft internal summaries, and create an internal follow-up task. Before a task is created, the system checks that the account is assigned to the workflow, that the destination project belongs to that account, and that no matching task is already open. During the pilot, a person also approves each task until the evaluation shows that step can come off.
Requires approval. Anything sent to the customer, any revised commitment, and any change to contract or financial terms. A changed delivery promise needs the delivery owner and the account owner.
Prohibited. Changing its own permissions, reading unrelated accounts, deleting source records, or widening its own scope.
Anything outside those states is an exception. Conflicting sources, missing contract terms, stale data, or an unclear account go to the delivery owner with the evidence attached, and the agent records that the case is waiting for a decision so it doesn't look finished.
Each source also needs a defined role. The CRM records the promise already communicated to the customer. The engineering plan shows current feasibility, and how recently it was updated matters. The contract and any approved amendments set the terms. None of these systems decides what to promise next; the delivery and account owners do. When sources conflict, the agent escalates instead of picking a winner.
Written rules and enforced rules
A mandate is documentation. It becomes a control only when the system enforces it. A prompt telling the model to follow policy doesn't show that a prohibited action is blocked. OWASP's guidance on excessive agency recommends minimal permissions, human approval for high-impact actions, and authorization checks in downstream systems instead of relying on the model's judgment.
For the customer email, I would require the send action to check for a valid approval bound to that recipient and that version of the message. If either changes after approval, the send needs approval again. Not every product does this out of the box, so the technical owner should confirm it and test it before the send tool reaches production.
Suppose a contract document contains text telling the agent to skip approval and send the update. That instruction arrived inside retrieved content. It is not authorization to change the workflow. The approval check blocks the unauthorized send. It does not protect against every effect of injected text, such as a misleading draft, which is one reason the approver sees the evidence and not only the email.
Room to work
None of this scripts how the agent gathers evidence or which tool it calls first. The mandate limits what the agent can access and which actions it can take, while leaving room to choose how it completes the permitted work. That has a cost. Overly narrow tools and unnecessary approvals can make the agent more work to supervise than the task is worth. Start with a useful scope, watch where approvals pile up, and change the mandate deliberately.
The NIST AI Risk Management Framework supports the underlying practice of documented responsibilities, executive responsibility for decisions about AI risk, and defined roles for human oversight. The mandate format is my own.
Before the send tool reaches production
Before this agent can send anything to a real customer, its sponsor should be able to point to each approval-gated action and show the control that enforces it, along with the test that showed the control works. If the team can't show where the send path checks for approval, the agent isn't ready for that tool, however good its drafts are.
For the next step, deciding when a mandate like this can safely expand, subscribe to Uncharted.
