Control what the agent can do
Giving an agent a tool is different from giving it information. Once an agent can modify files, send messages, update systems, or spend money, you need to think carefully about permissions and human approval.
From access to action
On the previous page, we asked: What can the agent see? The next question is: What can the agent do?
A chat model that only reads information and produces a response has limited ability to affect the outside world. An agent connected to tools can do much more: edit files, update records, send messages, call APIs, or trigger workflows.
That extra capability is useful — but it also increases the consequences of a mistake.
Not all actions carry the same risk
| Agent action | Example | Typical concern |
|---|---|---|
| Read | Analyze a spreadsheet | Data access and privacy |
| Draft | Write a customer email | Quality and correctness |
| Modify | Edit a shared file | Accidental changes |
| Update | Change records in a database | Data integrity |
| Communicate | Send an email or post a message | External consequences |
| Transact | Place an order or spend money | Financial or irreversible impact |
The more consequential or difficult an action is to undo, the more important it is to place a human checkpoint before the action happens.
Drafting and doing are different
Suppose you want to contact 300 customers whose contracts are about to expire.
A lower-risk workflow might be:
1. Agent identifies the customers
2. Agent drafts personalized emails
3. Human reviews the logic and a sample of messages
4. Human approves sendingA much higher-risk workflow is:
1. Agent identifies the customers
2. Agent immediately sends all 300 emailsIn both cases, the agent is capable of doing the work. The difference is where the human checkpoint sits.
Put checkpoints before consequential actions
Earlier in the course, we used human checkpoints to break down complicated tasks. The same idea is useful for controlling risk.
A good checkpoint comes before an action that would be costly, public, difficult to reverse, or harmful if the agent misunderstood the task.
| Before the agent… | You might require… |
|---|---|
| Deletes files | Explicit approval |
| Overwrites a shared report | Preview or backup |
| Sends external messages | Review before sending |
| Changes important records | Confirmation of the proposed changes |
| Spends money | Human authorization |
Prefer reversible actions when possible
A useful design principle is to make the agent's actions easy to inspect and undo.
Instead of:
Delete all duplicate customer records.Prefer:
Identify the records you believe are duplicates and create a
report showing which records you would remove. Don't delete
anything yet.Similarly, an agent can save a new version of a file instead of overwriting the original, prepare a draft instead of sending it, or propose database changes before applying them.
Permissions are part of the workflow
Agent tools often ask for permission before certain actions. Don't treat these prompts as obstacles to click through automatically.
Before granting permission, ask:
- What is the agent trying to do?
- Does this action make sense for the task?
- What could be changed or exposed?
- Can I review the proposed action first?
Permission settings are one of the mechanisms that keep the human in control of the agent.
Give the agent only the tools it needs
The same minimum-access principle from the previous page applies to tools. If an agent only needs to read a database, it may not need permission to modify it. If it only needs to draft an email, it may not need permission to send one.
Suppose you're using an agent to analyze customer support tickets.
It may need access to read the tickets, but it probably doesn't need permission to close tickets, issue refunds, or email customers unless those actions are part of the task.
A useful rule
Give the agent enough authority to do the job — but no more than it needs.
As the potential impact of an action increases, move the human checkpoint closer to the action.
Exercise
Imagine you're building an agent to help manage customer support. It can potentially:
- read support tickets,
- draft replies,
- send replies,
- close tickets, and
- issue refunds.
Decide which actions you would allow automatically and which should require human approval. For each one, consider:
- How costly would a mistake be?
- How easy would the action be to undo?
- Would a human need to review the agent's judgment first?