EXPLORE THE WORKFLOW
An example that requires human approval.
1. Receive the request
A signed-in colleague requests a change to a specific business record. The agent identifies the desired action and asks for clarification if the request is incomplete.
2. Check the scope
The integration verifies who is asking, which record they can access, and whether this type of change is permitted. The model cannot grant itself a permission it lacks.
3. Review the exact change
A person sees the target record and proposed changes before approving. Approval should be tied to that action and data, so a different change cannot reuse an earlier approval.
4. Apply and verify
After a valid approval, the controlled integration performs the update and checks the result. It records the outcome and handles a failed or uncertain response without blindly repeating the change.
Step 1 of 4
Approved and still validApply the exact authorised change and verify it.
Denied, expired, or changedStop and return to the appropriate review step.
Different tasks need different permissions
| Task | Possible starting policy |
|---|---|
| Retrieve an approved report | Read-only access to defined records. |
| Prepare a draft response | Create a draft for a person to review. |
| Update a business record | Validate the request and require approval where specified. |
| Delete records or publish externally | Restricted tool, explicit scope, and human approval. |
| Manage credentials or security settings | Keep outside the general business agent’s permissions. |
On smaller screens, scroll across the table to compare columns.
This table is a design example, not a universal policy. The correct rules depend on the consequences of the action, the user’s existing authority, and your business process.
Enforce limits outside the prompt
Instructions can guide an agent’s behaviour, but permission checks belong in the systems that provide data and execute actions. A tool should validate the caller, allowed operation, target record, and input before performing work.
Expose a narrowly defined action such as “prepare a report draft” instead of giving a general agent unrestricted database or server access. Use separate tools for reading and changing records when they need different permissions.
Make approval a meaningful decision
Show the reviewer what will change, where it will change, and any relevant consequences. Avoid a vague “Allow AI?” prompt that grants more access than the specific task needs.
The official MCP tools guidance calls for clear visibility and human control. In a business workflow, we would also design how approval expires, how it is recorded, and what happens if the underlying record changes before execution.
Treat uncertainty as a workflow state
An agent can misunderstand a request or encounter incomplete information. Content retrieved from a document or external system can also contain misleading instructions. Retrieved content should be treated as data; it must not grant new permissions or override the workflow’s controls.
When the target record is unclear, ask a person to resolve it. When a tool response is uncertain, verify the outcome before retrying a change. Define when the agent should stop, who receives the exception, and what evidence they need.
Keep the work observable and reviewable
- Record which user requested the action and which tool handled it.
- Capture approvals and outcomes without unnecessarily storing sensitive content.
- Make it possible to pause an integration or revoke a user’s access.
- Test denied permissions, malformed requests, missing data, and failed dependencies.
- Review behaviour after changes to prompts, tools, models, or connected software.
These measures reduce risk; they do not guarantee that every AI output or action will be correct. A sensible first project has a limited scope, clear success criteria, and a person responsible for reviewing exceptions.
Further reading
Official references for the concepts in this guide. The workflow examples are illustrative; the design for your business depends on its systems, access, and operating requirements.