Somewhere in your Zoho org, there is probably already an agent. Someone in sales switched on a prebuilt one from the marketplace. An ops manager built a small one to triage tickets. Or nothing yet, and it arrives next quarter because a department head saw a demo.
Before any of that goes further, one question is worth more than all the others: when that agent updates a record, whose authority is it acting on?
Zoho answers this plainly. Its own MCP documentation states that agents “operate under user-level permissions, so they can only perform actions that the user is authorized to do.” That is the right design. It is also the sentence that should make an operator sit up, because it turns an AI question into an access-control question — one you already know how to answer, and probably have not.
An agent connected under an administrator's credentials is an administrator. Not approximately. Exactly. It can reach every record that account can reach, in every module that account can open. The model does not decide what it may touch. Your permission configuration does, and it was written for humans who ask before doing unusual things.
Zoho has moved fast here. Its July 2025 launch announcement described Agent Studio giving builders “ready-made access to over 700 actions across Zoho's products,” 25-plus ready-to-deploy agents in an Agent Marketplace, and an MCP server exposing actions from more than 15 Zoho applications so outside agents can work against the same estate.
That is a genuine platform capability, and Zoho shipped controls alongside it. Agent Studio's documentation is explicit: “Guardrails define what your agent can and cannot do.” For sensitive work, “you can require human approval before anything happens.” Role assignment decides “who builds, who edits, and who just views.” Built-in observability means you “can see exactly what's happening at every step.” The July announcement adds that admins can run behavioral audits on agents to confirm they are operating within clear guardrails.
So the controls exist. The problem is not a missing feature. The problem is that a control nobody has configured is a default, and the default is almost always broader than anyone intended. In the orgs we look at, guardrails are untouched, approval requirements are unset, and the agent runs under whichever account happened to authorize the connection — usually the person who set it up, who is usually an admin, because an admin is who gets asked to set things up.
Gartner put a number on where this goes. In June 2025 it predicted that over 40% of agentic AI projects will be canceled by the end of 2027, “due to escalating costs, unclear business value or inadequate risk controls.” The third reason is the one nobody budgets for. Projects do not usually die because the agent was stupid. They die because the agent was capable, unsupervised, and nobody could say afterwards what it had done.
We have written before about what happens when agents run unsupervised in deployment pipelines — the DevOps version of this problem, where the discipline shifts from automating steps to governing what an agent may deploy without asking. Business systems are the harder case. A bad deploy is loud and gets rolled back. An agent quietly emailing the wrong customer segment, or amending pricing on live opportunities, produces no stack trace at all.
You do not need a policy document. You need answers to four questions, written down, for each agent you run.
Not what it is supposed to do — what it can do if it interprets an instruction generously. Because agent reach is inherited from a user account, this is a question about your existing access model, not about AI.
That makes it tractable. The distinction between what roles control and what profiles control is the same distinction that governs agent reach: roles set which records it sees, profiles set which actions it can take. If your role hierarchy has drifted, the agent inherits the drift. If sensitive fields are protected by field-level security rather than by data sharing rules, the agent's visibility depends on which of those two layers you actually used.
The practical move is to give each agent its own service user with a purpose-built profile, rather than connecting it as a person. It costs a licence. It buys you a reach you can describe in a sentence, revoke in one action, and read in a log without untangling it from a human's activity.
Every agent should have a named business owner who signed off on what it may do, and a named technical owner accountable for how it is configured. Not a committee. Two names.
This is the control that stops shadow agents. A prebuilt agent from a marketplace is one click for a department head and a permanent change to your operating risk. If nobody owns the decision, the answer to “who decided this agent could issue credits?” is that nobody did, and it happened anyway.
Sort every action an agent can take into three buckets:
Read and draft. Summarising, retrieving, preparing something for a person to send. Low consequence, reversible, no approval needed.
Write with a human check. Changing a record, sending an external message, moving a deal stage. This is what Agent Studio's approval requirement is for — use it here rather than saving it for emergencies.
Never autonomous. Anything touching money, contractual terms, customer-facing commitments, or personal data leaving the system. Financial approvals, pricing changes, refunds, mass communication.
Most teams put nothing in the third bucket because they never made the buckets. The exercise takes an hour and is the single highest-value thing in this article.
Assume an agent does something wrong. How long until someone notices, and what evidence exists?
Agent activity has to be attributable and reviewable. If your agent runs under a shared admin account, its actions are indistinguishable from a person's, and your audit trail is worthless for the one question you will actually ask. Running it as a dedicated user makes the audit log answer who changed what and when for agents as cleanly as it does for staff.
Then somebody has to look. An audit trail nobody reads is not a control; it is an artifact you produce for an auditor later. Put a recurring review on a calendar with a named owner, and treat an agent's log the way you would treat a new hire's first month — not because you distrust it, but because that is how you find out what it actually does versus what you assumed.
Agent governance fails when it is treated as a policy exercise. It is a configuration state that drifts: new modules get added, permissions get widened for a quarter-end push and never narrowed, someone connects a second agent, a marketplace agent updates its capabilities.
That makes it continuous work, which is why it sits with Managed Technical Operations rather than with a one-time implementation. Someone has to re-certify agent access on a schedule, review the logs, and catch the agent that quietly acquired a new permission when a profile was edited for an unrelated reason. Integration work and implementation work put the estate together; managed operations is what keeps its access model true to what the business actually approved.
This is also where the accountability framing matters commercially. It is easy to hand a client a governance framework and call it delivered. Harder, and more useful, is committing to the operating state: agents run under named service users, high-consequence actions require approval, logs get reviewed on a schedule, and if the configuration drifts on our watch, that is ours to fix.
You do not need a programme. You need an inventory.
List every agent running in your estate, prebuilt and custom, including anything connected through an outside MCP client.
For each one, write down the account it authenticates as, and what that account can reach. If the answer is “everything,” that is the finding.
Sort its actions into the three buckets and turn on approval for the middle one.
Give the high-consequence agents their own service users, then check the audit log actually distinguishes them.
Put a monthly review on someone's calendar with their name on it.
Most mid-market companies can finish that in a week. The alternative is not that nothing happens. The alternative is that the governance model gets written after an incident, by people who are annoyed, under conditions where every option is expensive.
The agents are already useful. Deciding what they may reach, who approved it, what they may do alone, and how you would know afterwards is what turns them from an interesting capability into a part of the business you can stand behind.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Four answers, written down per agent. What the agent can reach, meaning the records and actions its account allows, not what it is supposed to do. Who approved it, as two named people: a business owner and a technical owner. What it may do without a person, sorted into read and draft, write with a human check, and never autonomous. And how you would know afterwards: an audit log that distinguishes the agent from people, and a named person who reads it on a schedule.
An agent acts through the identity it is connected under, and if that identity is an administrator, the agent is an administrator with the same reach. A dedicated service user with a purpose-built profile gives the agent exactly the modules, records and actions its job needs and nothing more. It also makes the audit log useful: actions by the agent are attributable to it rather than mixed in with a person's activity, and the whole grant can be described in a sentence and revoked in one action.
Anything touching money, contractual terms, customer-facing commitments or personal data leaving the system. That includes financial approvals, pricing and discount changes, refunds, credits, closing or reopening deals, bulk reassignment of records, and any mass communication to customers. Changing a record, sending an external message or moving a deal stage sits in the middle bucket, where approval is appropriate for most companies. Summarizing, retrieving and drafting for a person to send can run without approval.
Run the agent under its own identity so the system's audit log attributes each change to it. Then review the log on a fixed schedule with a named owner, the way a manager reviews a new hire's first month. Look for actions outside the agent's stated purpose, records it touched that its job should not involve, and approvals that were granted reflexively. Re-certify the agent's permissions whenever a profile or role is edited, since a change made for an unrelated reason can widen what the agent can reach.
Shadow agents are agents switched on without a governance decision: a prebuilt agent a department head enabled from a marketplace, a small triage agent an operations manager built, or an outside tool connected through an integration under someone's personal credentials. Find them by inventory: list every agent in the estate, including external connections, and record which account each authenticates as and what that account can reach. The ones nobody can name an owner for are the finding, and the first step is assigning one.
Operations, not a working group. Agent governance is a configuration state that drifts: permissions widened for a quarter-end push and never narrowed, a new module added, a marketplace agent that updates its own capabilities. That makes it continuous work rather than a policy exercise. The practical owner is whoever already runs the business systems day to day, with a monthly review on the calendar, and the same person should re-certify agent access whenever the access model changes.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
