An AI agent inside a business process, with the controls still on
Most explanations of AI agents stop at the loop: read, think, call a tool, repeat. Most compliance guidance stops at the policy. This page puts the two in the same picture. Pick a process, choose how much the agent is allowed to do, and run a request through it. Every gate that fires is a control an auditor can test.
What is actually running
An agent is a loop, and a serious deployment is a tree of them. Each node has a narrow job, its own tools, and its own permissions. That shape is not only good engineering. It is what makes the system auditable, because every node can be tested on its own.
Why the tree matters to an auditor
- Least privilege per node. The reader can only read. The drafter cannot send. The only node that can change a record sits behind a human gate. One compromised node cannot do the whole job.
- Separation of duties, the old way. The node that proposes an action is never the node that approves it. This is the same control finance has used for a century, applied to software.
- Testable in isolation. Each node has fixed inputs and outputs, so it can be evaluated against a test set before release and re-tested after every model or prompt change. That is a change-management control.
- One log per hop. Every tool call carries the request ID, the node, the human who authorised the run, and the model version. That log is the evidence.
Where each gate lands in the frameworks you already report against
Nothing here requires a new compliance programme. Each gate is an existing control with an AI-shaped implementation.
The agent is the easy part. The work is deciding what it may touch, proving it stayed inside that line, and being able to show the proof six months later to someone who was not in the room.