Who Approved That?.

When a company talks about governing its AI agents, two controls come up. What can the agent see, which is permissions. And what did the agent do, which is the audit log. We have a video on each. Both are real, and both leave a question open: before the agent did it, who said it could? That is the third control, and it is the one almost nobody has configured. In Zoho CRM it already exists. It is called an approval process, and it was built for people: a rule that holds a change until a named person says yes.

This video shows how the same rule governs an agent. Everything on screen is a mock demo of Zoho CRM with sample data. Six minutes, one rule. Strip the word agent down to what happens in the system. An agent reads records, and then it changes records: it updates a stage, assigns an owner, sends an email, creates a task, changes an amount. Every one of those is a write to a record, under the permissions of whoever ran the agent. Here is a mock list of what an agent did on a Tuesday: it moved four deals to negotiation, reassigned nine leads, drafted twelve emails and discounted one deal by eight percent.

The audit log recorded all of it, correctly, after it happened. The question is not whether those were good actions. Some were. The question is which of them should have waited for a person. The discount, obviously. The stage moves, probably. The emails, maybe. That list is a governance decision, and it has to be written somewhere the system can enforce it. The approval process lives under Setup, then Automation, then Approval Processes. A rule names a module, say Deals. It names criteria: when the amount changes by more than five percent, or when the stage moves to Closed Won.

It names an approver: the sales manager, or the record's owner's manager. And it says what happens on approval and on rejection. When a change matches the criteria, the record is held. The change is visible, marked as waiting, and the approver gets it in their queue. Nothing downstream fires until they say yes. If they say no, the record goes back to what it was. It was designed so a rep could not discount a deal without a manager seeing it. It works exactly the same way when the change came from an agent, because to the system a change is a change.

One detail matters for agents in particular. The approval holds the record, not the agent. The agent proposed, finished, and moved on to the next task; the proposal waits in the queue on its own, which is exactly how a rep's discount waits. Nothing special was built for the machine. So the governance decision becomes three or four rules. Any change to an amount: approval by the manager. Any stage move to Closed Won or Closed Lost: approval by the owner. Any reassignment of more than five records in an hour: approval by the sales operations lead.

Any email to a customer in a deal over fifty thousand: approval by the owner. Notice what is not on the list. Creating a task. Drafting a note. Updating a phone number from a signature. Those are the things you want an agent to do without asking, and the rules leave them alone. The list is short because it should be. If every action waits for a person, nobody uses the agent. If none does, nobody governs it. The rules are the line, and it is written by the business, not by the model.

Write the list before the agent is switched on, not after the first surprise. A rule added after the fact governs the next action; the one that prompted it is already in the audit log, and the log, as we said in another video, is a record and not a control. Here is the mock deal on Tuesday afternoon. The agent proposed an eight percent discount on Harbor Dental. The rule caught it. The deal shows the proposed amount, the previous amount, who triggered the change, which was the agent running as Priya, and a button for the manager: approve or reject.

The manager reads the reason the agent gave, looks at the deal, and rejects it, because the customer has not asked for a discount and the quarter is not that desperate. The amount reverts. The audit log records the proposal and the rejection, so the record is complete. That is the whole loop. The agent proposed, a person decided, the system kept the record. Nobody had to find out on Friday. Put the three controls side by side. Permissions decide what the agent can see and touch at all. Approval processes decide which of the things it can touch wait for a person.

The audit log records what it did, including what was held and what was rejected. Most companies we review have the first partly configured, the third on by default, and the second not at all. Which means their agents can act on anything they can see, and the company finds out from the log. The second control is an afternoon of configuration, and it is the one that turns an agent from something you watch into something you govern. If you have agents on in Zoho CRM and no approval processes written for them, you have decided, without deciding, that everything they can see they can change.

Write the four rules. It takes an afternoon. We are CodeStringers, a Zoho authorised consulting partner. The link below is a no-risk discovery: we read your permissions, your approval rules and your audit log and show you where the agents are acting unasked.