The next RevOps problem is not Shadow IT. It is Shadow Agents.

Picture a fairly ordinary B2B team a few months from now.

One seller connects ChatGPT to the CRM to prepare for meetings. Another builds an agent that researches accounts and updates fields. Marketing connects an agent to an external tool through MCP. Customer Success experiments with another that summarizes tickets and creates follow-up tasks.

No new CRM was purchased. No formal integration project was opened. In some cases, nobody wrote any code.

Yet the company just added four new actors with access to operational context — and some of them can take action.

At RevOpsHubs, we call these Shadow Agents.

What is a Shadow Agent?

We are not presenting the term as an established industry category. It is a useful name for an operational problem that is starting to emerge.

A Shadow Agent is an AI agent, assistant or app with access to company systems, data or tools that has moved into use without a clear definition of owner, scope, permissions, approvals, monitoring and success criteria.

Importantly, a Shadow Agent does not have to be malicious, secret or even technically unauthorized. It may have been created by someone with completely legitimate access. The problem is the absence of an operating model around it.

Why this becomes a problem now

The boundary between “assistant that answers” and “system that acts” is disappearing quickly.

In April 2026, the remote HubSpot MCP server became generally available with write capabilities across multiple CRM objects. MCP-compatible AI tools can therefore do more than retrieve contacts, companies or deals: within existing user permissions, they can update parts of the CRM.

HubSpot also lets agents created in Agent Builder connect to external systems through the HubSpot MCP Client, giving them access to live business data and actions in supported applications.

On the ChatGPT side, full MCP support for Business and Enterprise/Edu environments includes write and modify actions, with admin, access and approval controls.

None of that is inherently a problem. In fact, those capabilities are exactly what make agents useful.

The problem appears when organizations continue to govern them as if they were just another SaaS seat.

A license grants access. An agent can turn access into action.

The Shadow Agent Risk Model

When you assess an agent, “is it approved?” is too small a question. We propose seven instead.

Together, these seven dimensions form the agent's operational surface. The larger that surface, the stronger the governance needs to be.

The hardest failure is not hallucination. It is plausible action.

Take a simple prospecting agent. It can read the CRM, research accounts on the web, update properties and create tasks for sellers.

It is tempting to assume the primary risk is fabricated information.

But some of the more difficult failures are far less dramatic:

• it classifies an account correctly against an ICP definition that is already outdated;
• it updates a valid property that triggers a workflow nobody considered;
• it creates legitimate tasks for accounts owned by another territory;
• it repeats an action hundreds of times because the trigger is too broad;
• it gains access to a newly exposed MCP tool that was never reviewed by the process owner.

None of these failures requires a rogue AI. A plausible decision inside a poorly bounded system is enough.

This is why AI readiness starts before the AI layer. The agent inherits definitions, ownership, data quality and rules that already exist — or were never formalized.

Useful governance does not mean blocking agents

The wrong response is to turn every AI experiment into a six-week project with five approvals.

That simply pushes useful experimentation back outside the formal process.

The goal is bounded autonomy: teams can experiment and create value, but inside explicit limits.

A 30-minute RevOps audit

If you own CRM, automation or RevOps, start with one sheet. Not a 40-page policy.

1. List the agents and assistants the team uses with company data. Include ChatGPT, HubSpot, internal automations and external tools.
2. Mark which ones are connected to operational systems. CRM, email, Slack, support, ERP, data warehouse.
3. Separate read from write. What only retrieves? What can edit, create, send or delete?
4. Name the owner. A person, not “Sales” or “Marketing”.
5. Mark approval boundaries. Especially external, irreversible or financially material actions.
6. Check logs, limits and revocation. If nobody knows how to stop it quickly, there is work to do.

If an agent fails three or four of these checks, that does not automatically mean it should be switched off. It means it is not production-ready yet.

From agent inventory to an operating contract

Inventory creates visibility. It does not define behavior.

For every agent entering production, one more question matters: under what contract is this agent allowed to operate?

That is the next RevOpsHubs framework: the Agent Operating Contract. Instead of starting with a prompt, it starts with objective, context, tools, permissions, approvals, budget, metrics, escalation and rollback.

A company can have excellent prompts and poor governance.

RevOps will govern actors, not only systems

For years, the stack was relatively static. Companies bought tools, assigned access, created integrations and audited users.

Agents change the geometry. They can combine context across systems, choose tools and execute action sequences that previously required people.

That is precisely why they are valuable.

It also changes the governance question:

Not only “who has access to the CRM?” but “who — human or agent — can do what, with which context, under which limits and with whose accountability?”

That is now a Revenue Operations question.