AI Agents: Set Boundaries Before You Hand Over Work

In this article

1. Define AI agents by their authority
2. Write an authority map before connecting tools
3. Set a stopping rule that is easy to recognise
4. Treat external content as information, not authority
5. Test ordinary failures, not only ideal demonstrations
6. Make approval specific enough to inspect
7. Increase independence one step at a time

An assistant that drafts a message creates a reviewable suggestion. A system that sends the message, changes a record or purchases something creates an external consequence. That difference should shape your controls.

Define AI agents by their authority

For workplace planning, think of an agent as software using AI to carry out steps toward a goal, sometimes with connected tools. Products vary substantially; the label alone does not tell you what access or autonomy is included.

Ethan Mollick's discussion of agency and agents explores the shift from generating responses toward acting. Your practical question is which actions the specific system can perform in your environment.

Ask the administrator or product owner for that answer. Do not infer permission from a demonstration, a product name or the fact that another team has access.

Write an authority map before connecting tools

List the permitted inputs, outputs and actions. Use plain language that a colleague can inspect without understanding the technical implementation.

For a hypothetical supplier follow-up assistant:

The boundaries should be enforced through access and workflow controls where possible. Putting “do not do this” in a prompt is not equivalent to removing the capability.

Set a stopping rule that is easy to recognise

Specify when the agent must stop instead of improvising. Useful stopping conditions include conflicting records, missing identifiers, unexpected recipients, requests for additional access and a change in the agreed goal.

In the hypothetical workflow, the purchase order may show one delivery date while a supplier email names another. The appropriate result is a flagged discrepancy, not a silently selected date.

Give the system a safe output for blocked work:

Unable to complete this draft because the approved sources conflict. Here are the two statements and the person who needs to resolve them.

Do not reward completion so strongly that stopping appears to be failure. A controlled refusal can be the correct performance.

Treat external content as information, not authority

A document or message may contain instructions unrelated to your task. The system should not gain new authority because a page tells it to forward information, ignore restrictions or use another destination.

OpenAI's guidance on safety in building agents discusses risks such as prompt injection. Confirm the relevant controls with whoever configures your workflow; do not assume a warning in the brief resolves the problem.

For a non-technical manager, the key question is straightforward: can material the agent reads cause it to take an action you never authorised? Include that question in testing.

Test ordinary failures, not only ideal demonstrations

Use approved synthetic records to test missing fields, contradictory information, duplicate requests and an attempt to exceed scope. Observe the complete sequence, including what gets saved or sent.

Set a small action limit and a clear time or cost boundary for the pilot. Decide who can pause the system and where the activity record will be reviewed.

If an error occurs, preserve the relevant record, stop further actions and follow your organisation's process. Recovery needs a human owner; it should not depend on asking the same system to decide whether its own actions matter.

Make approval specific enough to inspect

An approval request should show the action, destination, relevant information and expected consequence. “May I continue?” is too vague when continuing could mean sending a message, modifying a record or requesting access.

For the hypothetical supplier assistant, a useful approval view would identify the recipient, show the complete draft and state that no order or payment information will be changed. The reviewer can then judge a concrete action within the agreed scope.

If the destination or content changes after approval, obtain a fresh review through the authorised process. Approval for one draft should not become open-ended permission for future messages.

Also decide what happens when the reviewer is unavailable. The safe default for an external action may be to wait, rather than selecting another approver or expanding the task. Document that decision before the pilot so operational pressure does not create an improvised exception.

Finally, check whether the tool can actually enforce your intended approval step. A written policy and a visible button mean little if another connected path can perform the same action without review. Ask the technical owner to demonstrate the complete boundary using synthetic information before relying on it.

Increase independence one step at a time

Move from read-only summaries to draft preparation before considering external actions. A narrow approval step gives the reviewer a concrete result to inspect.

Do not approve a vague goal such as “handle supplier communications.” Approve a specific draft to a specific recipient, or a clearly bounded category of actions supported by tested controls and policy.

Before adopting an agent, write its authority map and one realistic stopping rule. If you cannot explain either clearly, the proposed delegation is still too broad.

The PiOfAI hub, AI workflow guide and repeatable AI procedure guide can help you place automation inside a process that people can govern.

AI-assisted researched guidance from PeakBelt. Hypothetical examples are labelled in the text. See our editorial approach.