Why prompts and approval buttons are not enough
Agents fail quietly. There is no error: a wrong value lands in the right field, or the right value lands in 500 rows when you meant 5. Each single action looks reasonable, so a person approving them one by one sees nothing wrong, and soon stops reading.
Good guardrails do three things: they sit outside the model, they show the whole result, and they make putting things back cheap. We wrote up the reasoning in AI agent approval workflows: review the batch, not each call.
Every change lands on a branch
A branch is a full copy of the workspace: records, types, workflows and settings. The live branch, main, is protected, and an agent never writes to a protected branch, whatever key it holds. On its own branch the agent's work is real: it can read it back and build on it, while nobody else's data moves.
A coding session's branch is private to its person until they ask for a merge, so half-done work is not put in front of the team.
A person reviews the whole change
When the agent is done it commits and asks for a merge, and the people who may merge get the request in their Inbox. A commit lists each record that was added, modified or deleted, and field by field what the values were before and after.
The reviewer can merge, fix a few records and merge the rest, or revert a commit. Reverting makes a new commit that undoes the old one, and brings back records that were deleted.
What each kind of action meets
| Action | What stops it |
|---|---|
| Reading | The person's own access, and the grant |
| Changing records on its own branch | Nothing while it works: all of it is reviewed at the merge |
Merging into main | A person who may merge |
| Calling another service | Held until the merge, then sent once |
| A decision only a person can make | ask: one question in the Inbox |
| What the grant does not allow | Refused outright |
Agents hold grants, not keys
An agent acts for a person and can do no more than that person may. It also never works with the key itself: it holds a grant narrowed from the key, which can be narrowed again for a subagent, never widened. A grant can carry a budget, and it ends when the session does. What your agents hold in Settings lists every grant, and Revoke ends one. You can pause or stop an agent there too.
You can see which agent did it
The first time an agent changes something in a workspace, it gets an Agent of its own, and that is what its records and commits say: "Claude, for Maria". Answers to its questions stay with the question: who decided what, and when.
Effects outside your data wait
Records can be put back. An e-mail cannot be unsent. A connector action run on a session's branch is held: the merge sends it, once, and a branch closed without merging sends nothing.
Where to go next
- Version control for business data: how the branches work
- MCP server for business data: connect the agent you already use
- AI agents for operations teams: what this looks like day to day