AI agent governance is how a GTM team keeps control of agents once they're live. The bar is higher in GTM than in internal AI use, because AI sales agents route leads, update the CRM and email buyers. Marketing agents work from the same records, so a bad decision can reach a prospect within hours.
Building agents is now the easy part. Any GTM team can stand up a lead router or an enrichment agent in a week, often without engineering. The advantage goes to teams that turn that work into automation people can own, audit and trust in production.
We run agents across ZoomInfo's own go-to-market process, from inbound lead handling to renewals. This guide shares how we govern them, how one company runs 200 digital workers alongside its people, how to decide which actions need a person, and how to trace an agent error to its cause.
What AI Agent Governance Covers
Traditional AI governance asks whether a model's output is accurate, fair and compliant. Agent governance adds a second question: what is the agent allowed to do, and who answers for it? The risk moves from what a model says to what an agent changes, such as a CRM field, a routed lead or an email in a buyer's inbox.
AI agent governance spans five controls. Each one answers a question someone will ask the first time an agent gets something wrong in front of a buyer.
Control | The question it answers | What it looks like in a GTM fleet |
Ownership | Who is accountable for this agent today? | A named owner per agent, separate from the builder, with authority to pause it and a backup who can step in |
Access | What can this agent read and change? | Scopes that match the job, so a routing agent can reassign leads but can’t edit opportunity amounts or send email |
Traceability | Why did it do that? | A record linking each action to the trigger that fired it, the data it used and the field or message it changed |
Cost | What will this run cost, and who can launch it? | An estimate before the run, usage tracked per agent and limits on who can launch jobs across large account lists |
Containment | How far can one mistake travel? | Verification before agents act on a record, so a stale contact gets caught before the next agent reads it |
Ownership and access are set before an agent goes live. Traceability and cost are monitored while it runs. Containment depends on the data layer underneath every agent, which is why the fleets that stay governed treat data checks as part of the agent design.
Why Control Slips After the Tenth Agent
AI made agents cheap to build, and teams quietly assumed that also made them cheap to own. Mollie Bodensteiner, VP of Revenue Operations at ZoomInfo, sees that assumption behind fleets that grow fast while ownership and governance lag. “The build and the ownership are very different,” she said on our Revenue Architects podcast.
Three things break as the fleet grows, and together they’re what teams call agent sprawl.
Ownership drifts. The person who built an agent changes roles, and the agent keeps running with nobody accountable for its errors or the decision to retire it.
Visibility drops. When agents trigger other agents, a bad CRM value can take an afternoon of Slack archaeology to trace back to its source. In TDWI’s 2026 survey of data and AI leaders, only about 25% of organizations used monitoring or observability tools for their AI environments. Mollie’s test for any agent is who notices when it breaks, and how fast. If nobody can answer, the team assembled the agent without really owning it.
Blast radius grows. Downstream agents treat an upstream agent’s output as fact, so one stale record can shape every action that follows it.
Adding more point tools makes this worse, because each one brings its own systems, owners and data paths for the team to track. It’s the same point-solution problem that already strains GTM data foundations, now with agents that can act on fragmented data before anyone catches the error.
Here’s how one stale record moves through three agents on a single account in one week:
Enrichment. An enrichment agent refreshes a contact from a stale feed. The contact left two months ago and nothing flags the record as unverified, though job change alerts would have caught the move.
Routing. A lead routing agent reads the record and sends a new inbound lead to an owner who no longer covers the account.
Call prep. A summarization agent drafts call prep around the wrong contact and the wrong owner.
The meeting. The prospect corrects the rep mid-meeting. Three agents acted on the bad record, and none of their logs point to where it started.
Every agent did what it was built to do. The fleet had no shared check on the data and no owner positioned to catch the error early. AI data enrichment that re-verifies records before agents act would have stopped it at the first step.
Three Practices for Governing Agents at Scale
Each failure mode has a matching practice, and none of them adds an approval queue for every new workflow.
Treat provenance as non-negotiable. Every agent action should be traceable to its trigger, the data it acted on and the change it made. That record is what lets a team fix the root cause of a bad outcome, beyond the symptom it left in the CRM. It’s the same discipline behind our GTM Context Graph, which captures why something happened along with what happened.
Name an owner for every agent. The builder and the owner are often the same person at launch and rarely the same person a year later. The owner is accountable for the agent’s output and has the authority to pause it when the data, the process or the business need changes.
Govern from one layer. Let teams build fast, and route what agents can access and change through one governed layer. Auditing each agent individually after the fact stops working once the fleet passes a handful. It’s the agent version of data orchestration, where data moves through one controlled path before anything uses it.
How ZoomInfo Governs Its Own Agents
Four design choices put those practices to work across our own agents.
Every agent starts from a defined trigger
Each agent fires on a specific, repeatable event. Brendan Powers, Principal GTM Operations and Engineering Manager at ZoomInfo, builds the agents that run autonomously across our go-to-market process. His usual triggers, which generally fire in Salesforce, are:
An inbound lead
A demo being booked
A demo that just finished
An account reaching 90 days from renewal
Each trigger maps to a play with a clear owner. An inbound lead belongs to the team responsible for accelerating inbound leads. A renewal trigger belongs to the account team watching the customer health score. A booked demo, for example, is a natural trigger for an account research agent that preps the rep. If you can’t name the event that should fire an agent, it isn’t ready for production.
Ownership is a name with a backup
Mollie adds two rules to ownership. The owner can turn down new scope as well as pause the agent, and ownership can’t sit with a department. “It’s a name and then it’s a continuity of a backup person,” supported by clear documentation. Her check is whether the backup could fix the agent while the owner is on vacation.
Ownership extends to what agents produce. Our closed-won agent reviews every deal closed that day, analyzes why we won and uses the ZoomInfo MCP server to find the new customer’s competitors. Owned accounts go to their owner with the reasons we won, and unowned ones go back to the rep who closed the first deal. Dennis Sevilla, ZoomInfo’s Chief Strategy Officer, described the split of responsibilities in GTM Exclusives: “The agent gets the context to the right people, and senior operators decide what gets built and acted on.”
Field-built agents get scaled with governance
Some of our best agents were built by people in the field. Mollie’s approach is to take those builds, scale them and add governance, so the people doing the job still shape the agent and nothing runs unseen on one rep’s laptop.
Scaling also means removing duplicates. Mollie estimates that agents built for similar GTM jobs overlap by about 90%, with the rest tailored to the team. Derek Osgood, who leads agentic orchestration strategy at ZoomInfo, made the same point in TDWI’s 2026 report on agentic AI: “You don’t want ten different agents analyzing the same data ten different times.”
Long-lived agents are run like products
An agent that will still be running in 18 months is infrastructure, and Mollie treats it as a product. That means it gets:
A roadmap
A release schedule
Versioning
Someone committed to maintaining it
When we built our own platform for post-sales workflows, it got a product manager, a roadmap and a release schedule, because a failure there costs the business money. Her advice for every agent is to stop treating “we built it and it works” as the finish line. “That’s honestly just where you’re starting.”
Manage Agents the Way You Manage People
Asymbl, a workforce orchestration company, runs about 120 employees alongside 200 digital workers. Greg Symons, its Founder, President and COO, walked through on Revenue Architects how they govern those agents with the same structure they use for people.
Teddy, Asymbl’s AI SDR, qualifies inbound leads, researches each company and persona, and books meetings for a human BDR named Jordan. Teddy has his own email account, his own Salesforce user record and a presence in Slack, so every conversation is visible to the team. He also reports to Jordan, a split our guide to AI SDRs and BDRs covers in more detail.
That identity is what makes Teddy governable. Because he has his own user record, his access can be scoped like a new hire's, every change he makes traces back to him and his permissions can be revoked in one place. An agent that runs under a shared admin login or a rep's personal credentials has none of that.
Every week, Jordan reviews Teddy’s work the way a sales leader reviews a rep’s numbers. His dashboards show:
Emails sent
Where each prospect sits in the cadence
Meetings booked
Meetings converted to opportunities
The team also exports every email Teddy sent and runs it through a separate AI tool to check the messaging, which Greg calls “a trust but verify mechanism.” The findings feed back into Teddy’s training each week.
The first version struggled because Asymbl treated Teddy as a software rollout. The fix didn’t touch Teddy. It changed how the team managed and coached him.
Set Oversight by Risk: When Agents Act Alone
Requiring approval for every agent action defeats the point of agents, and requiring it for none puts buyers at risk. Mature teams set oversight per action, based on what happens if the agent gets it wrong. Four tiers cover the common GTM actions.
Oversight tier | What the agent does | GTM examples |
Acts on its own | Completes the action and logs it | Enriching a record, logging meeting notes, updating a lead score |
Acts and notifies | Completes the action and tells the owner, who can reverse it | Routing an inbound lead, creating a follow-up task, adding a contact to a buying group |
Drafts for approval | Prepares the action, and a person approves before it runs | First outreach to a new executive, changes to opportunity amount, stage or close date |
Human only | Briefs the person and takes no action | Pricing and discounts, contract terms, replies to an escalated customer, deleting records |
Three questions place any action in a tier:
Can it be undone? A wrong lead score can be fixed in seconds. A sent email can't be unsent.
Will a buyer or customer see it? Anything that reaches someone outside the company moves up a tier.
Does it change revenue numbers? Amounts, stages and close dates feed the forecast, so a person should confirm them.
A yes to any of them moves the action up a tier. The tiers combine two oversight models: human-in-the-loop, where a person approves before the agent acts, and human-on-the-loop, where the agent acts and a person monitors with the power to step in. A safe default is to start a new agent one tier stricter than it needs, then relax the tier once the owner has reviewed enough runs to trust the output. Our guide to AI agents in CRM covers how much autonomy to allow on CRM records specifically.
When an Agent Gets It Wrong
A good response has two parts: a plan for the first hour and a diagnosis that finds the cause.
Plan for incidents before the first one
Every fleet eventually sends a wrong email or overwrites a good record. The teams that recover fast decided in advance who acts and how. A GTM incident plan covers five steps:
Pause. The owner or backup can stop the agent mid-play, without waiting on engineering or the vendor.
Scope. The action log shows every record and message the agent touched since the bad input, so the team knows the size of the problem within minutes.
Contain. Revert or flag the affected CRM fields, and pull any queued emails or sequence enrollments.
Tell the people affected. Account owners hear first. If a buyer received something wrong, a person follows up directly.
Fix the cause and retest. Trace the failure to the data, the prompt or a permission, fix it and rerun the agent on test accounts before it goes live again. The next part shows how to tell which one failed.
Write up what triggered the incident and what now prevents a repeat. Over time, those write-ups become one of the most useful governance documents a RevOps team owns.
Data or prompt? Diagnosing the failure
When an agent gets something wrong, the instinct is to blame the model. Brendan’s experience points elsewhere: “the odds are, if you have issues, it’s something in either the prompting or likely the underlying data layer.” Moving an agent from Haiku to Sonnet can help, but check the prompt and the data first.
Use the symptom to find the layer.
Symptom | Likely cause | What to check |
Output is generic for some accounts | Missing fields the agent depends on | Fill rate for the fields that drive personalization |
Agent acts on the wrong person or owner | Stale contact or ownership data | When the record was last verified |
Agent emails the wrong version of a contact | Duplicate records | Entity resolution on the records the agent reads |
Output contains gibberish in one field | A CRM field changed meaning | Recent changes to fields the agent uses |
Agent ignores an instruction | Overloaded prompt | Whether the task can be split into smaller steps |
Numbers vary between runs on the same data | Calculations left to the model | Whether the step can run as fixed logic |
Output changes with no edits | Underlying model changed | Which model version the agent runs on |
Check field coverage first, starting with the firmographic data your plays segment on. Brendan’s example is an agent that tailors its output by industry when only half the accounts have an industry value, so half its output can’t be tailored at all. Duplicates fail the same way. If the CRM holds 12 records for one person, an automated email has to pick one, and it may pick wrong. Regular data quality checks catch both gaps before an agent reads the record.
Field changes are harder to spot. When a Salesforce admin repurposes a field, an attribute an agent depends on can turn to gibberish inside a customer-facing email, and nothing alerts anyone.
Calculations belong in deterministic steps. Asymbl first built Stanley, an agent that analyzes sales data and coaches reps, entirely on an LLM. Runs took four hours to two days, and the numbers changed from run to run. “We can’t have mostly right sales data,” Greg said. Rebuilt with fixed logic that produces structured output for other agents to read, Stanley now runs in five minutes. Well-built workflow automation follows the same rule, leaving judgment to the model and calculation to code.
Governance Across the Agent Life Cycle
Everything so far applies at some point in an agent’s life, from design to retirement. Here’s what each stage needs.
Stage | Controls to put in place |
Design | Named trigger, defined outcome, named owner and backup, split between LLM decisions and deterministic steps, oversight tier for each action |
Before launch | Field coverage and duplicate checks, role-based access on the agent's own credentials, cost estimate, test runs on real accounts |
In production | Monitoring, a record of every action, weekly review of outputs, a way to stop a running process |
After changes | Retest after model upgrades, prompt edits, CRM field changes or new data sources |
Ongoing | Quarterly review of owners, access, cost and usage, with duplicate and unused agents retired |
Retirement | Turn off triggers, revoke the agent's credentials and connections, hand open work to a person and keep the action log for audit |
Access needs tighter control as agents act across more systems. Prasanna Krishnan, who leads product management for data and AI initiatives at Snowflake, put it this way in TDWI’s report: “You want to make sure the right people, and now also the right agents, have access to the right data.” An agent should never see more than the person it works for.
Three risks that grow with the fleet
Ownership, access and logging cover the basics. These three need an owner watching for them as the fleet grows.
Model changes. Agents run on models that get upgraded and retired, and outputs can shift with no edit to the agent. Brendan counts this among the core skills of a strong GTM engineer: checking whether an agent’s output changed after a model update and adjusting the prompt if it did. Every agent should have a recorded model version and an owner responsible for retesting it after a change.
Shadow agents. Reps build their own agents and sign up for AI tools RevOps never bought. Mollie’s example is an AE who leaves with automations running on his own machine that break the day he’s gone, and she expects a wave of shelfware and sprawl companies don’t know is running. Greg has seen the time cost too, with employees building agents when they should be doing their jobs. Brendan reads unapproved tools as a signal first, of an enablement gap or a feature the stack already covers. To bring shadow agents into the fleet:
Ask reps which agents and AI tools they use.
Bring the useful builds under governance on approved GTM engineering tools, with an owner and a backup.
Move account context out of personal documents and into the CRM, where fixing CRM data quality gives every agent the same starting point.
Over-permissioned connections. Every API key, MCP connection and integration an agent holds is access someone has to account for. Give each agent its own credentials, scoped to the job, so revoking one agent never breaks another. OWASP's term for the failure is "excessive agency": an agent with more permissions than its task needs.
Inbound agents carry an extra risk, because they read content written by people outside the company. A form fill or reply email can contain instructions aimed at the agent, a technique called prompt injection. Treat everything an agent reads as data, keep its send and edit permissions narrow and route anything unusual to a person.
Frameworks and Standards for AI Agent Governance
Once the controls are in place, a recognized framework makes them easier to explain to security teams, auditors and enterprise buyers. No standard was written for GTM agents, but a handful fit well.
Framework | What it is | What it means for a GTM agent fleet |
NIST AI Risk Management Framework | Voluntary US framework built on four functions: Govern, Map, Measure and Manage | Govern sets owners and policy, Map records each agent's scope and oversight tier, Measure covers output reviews and Manage covers incidents and retirement |
ISO/IEC 42001 | Certifiable standard for an AI management system | Formalizes roles, risk assessment and documentation, useful when enterprise customers ask how you run AI |
EU AI Act | EU law with risk-based obligations for AI systems | Transparency duties apply from August 2026, for example when people interact with an AI system. High-risk rules, moved to December 2027 under the 2026 omnibus agreement, mainly target uses such as hiring and credit decisions |
OWASP Top 10 for LLM Applications | Security risks for applications built on language models | A checklist for prompt injection and excessive agency, especially for agents that read inbound content or write to the CRM |
GDPR and CCPA | Privacy laws for personal data | Agents that enrich and email contacts inherit your obligations on lawful basis, opt-outs and data subject requests |
SOC 2, ISO 27001 and ISO 27701 | Security and privacy controls for service providers | The baseline to ask of any platform your agents run on |
If you need one structure to organize everything in this guide, start with the NIST AI RMF, which enterprise security teams already know.
Start With a Governed Data Layer
Governance can’t make up for bad inputs, any more than sales workflow automation can. Every control above assumes agents are reading accurate, current records, so a data foundation for agentic AI comes before the agents.
The cost of skipping it lands on the buyer. Mollie’s concern is teams that automate for productivity at the expense of the customer experience. One bad email built on stale data can lose a prospect for good, however many activities the agent logged, and B2B data decay means yesterday’s accurate record can be today’s stale one.
Keep CRM data enrichment running on verified sources. Then have every agent read from and write to the same resolved records through one shared context layer for AI agents. For Salesforce teams, that starts with Salesforce data enrichment. HubSpot teams can follow our guide to HubSpot data enrichment.
Momentive shows what consolidation does. Its Salesforce environment was split across several point-solution data vendors, with no single system of record. Its business systems team moved matching, deduplication and the rest of its CRM hygiene onto one governed layer, along with enrichment, scoring and routing. Lead enrichment and validation dropped from 20 minutes to under 60 seconds, on one auditable path from raw record to routed lead.
"Thanks to ZoomInfo, we no longer have to question the source or reliability of the data in our systems."
How Agent Teams Builds Governance Into Every Play
ZoomInfo is an all-in-one AI GTM Platform and the number one place for sales, marketing and RevOps to run agentic workflows. It applies the same governance model to the plays customers run, across three layers:
Data. Verified data on 500M contacts and 100M companies. The GTM Context Graph, part of that foundation, joins it with your CRM records, calls, emails and signals, so every agent works from the full account history.
Agent Orchestration. Agents read that context, act on it and write the results back, with governance and audit logging applied throughout.
Universal Access. GTM Workspace for sellers, GTM Studio for marketers, RevOps and GTM engineers, and GTM.AI as the core route for any tool or agent.
Agent Teams, the flagship multi-agent product in GTM Studio, is where those layers run as complete plays. It comes with no new SKU or contract and is built on technology from DoubleO.ai, now part of ZoomInfo. Give your agents an outcome, not a task: specialist agents carry the play toward it, and a supervisor agent checks each step against the rules you set.
Each play works from an account’s current state. When a new buying signal arrives, such as a job change or a pricing-page visit, the play resumes with everything it already knows. Customers can run the same pattern as our closed-won agent with the Closed/Won Competitor Acceleration template, a variation on the closed-won lookalikes play that finds a new customer’s competitors and alerts the rep. The inbound and renewal triggers our own agents fire on map to the inbound lead activation and renewal at risk plays. Agents act natively in Salesforce, HubSpot, Slack and Gmail, and in sales engagement platforms Salesloft and Outreach.
Every play runs inside guardrails your admins set, so you hand over the work and keep the control:
Monitoring. Every play is monitored, so mistakes are found and fixed before they affect the business.
Cost controls. AI credit usage is estimated before a play is activated and tracked for each Agent Team.
Admin oversight. Organization-wide dashboards show what every Agent Team is doing.
Access control. Role management decides who builds and runs Agent Teams.
Grounding. Organization-level knowledge bases keep agents aligned with your ICPs, brand and SOPs.
Real-time evaluations. Each step is checked, so a play runs the same way every time.
Audit trail. Every step is written back to Salesforce or HubSpot, with every decision recorded in one place.
ZoomInfo maintains SOC 2 controls and is ISO 27001 and ISO 27701 certified.
Teams building their own agents get the same foundation through GTM.AI, ZoomInfo's headless option. Our own agents run through it, and your team can connect from a partner platform or a custom pipeline using the API, CLI or MCP. GTM.AI is free to start, with consumption-based credits. Each route draws on the same data foundation.
Our guide to MCP vs API for data enrichment covers which connection fits which agent.
Build Governance In From the First Agent
Governing agents at scale depends on a few decisions made before each agent ships. Name an owner and a backup, scope what the agent can touch, set the oversight tier for each action, decide which steps the model handles and which run as fixed logic, and set up a way to catch output that changes.
The teams that scale agents well build governance in from the first agent, whatever their AI budget or agent count. Teams that make those calls early can keep the field building, because every new agent joins a fleet with owners, reviews and shared data underneath it. Teams that wait end up auditing agents that are already emailing buyers. Agent Teams puts those controls in one place for RevOps, with monitoring, access control and a credit estimate before every play.
See how Agent Teams governs every play
Frequently Asked Questions
What is AI agent governance?
AI agent governance is the set of controls that keeps AI agents accountable after deployment. It covers who owns each agent, what it can access, how its actions are recorded, what it costs to run and how its errors are contained.
How is AI agent governance different from AI governance?
AI governance focuses on model outputs, such as whether an answer is accurate, fair and compliant. AI agent governance also covers actions, because agents update records, route leads and send messages on their own. It adds ownership, scoped access, oversight thresholds and an action log to the usual model controls.
How do you govern AI agents in production?
Give every agent a named owner and a backup, scope its access to the records and actions it needs, and keep a record of every action. Review outputs on a schedule, track cost per run and keep a way to stop a running process. Running every agent on one governed data layer means they all start from the same verified records.
What is human-in-the-loop for AI agents?
Human-in-the-loop means a person approves an agent's action before it runs. Human-on-the-loop means the agent acts and a person monitors with the power to step in. GTM teams usually keep a person in the loop for anything a buyer sees or that changes revenue numbers, and use on-the-loop monitoring for internal updates such as enrichment and logging.
Why is AI agent governance harder for GTM teams?
GTM agents act on customer-facing data. They send email, route leads and update CRM records, so a bad decision can reach a buyer quickly and spread to other agents that read the same records.
How do you get visibility across a fleet of AI agents?
Log every agent action back to the trigger that fired it, the data it read and the change it made. That provenance trail lets the team trace a bad output to its source, and monitoring shows which agents and plays are running at any time.
Who should own an AI agent after it ships?
Every agent needs a named owner with the authority to pause it and to turn down new scope, plus a backup who can fix it when the owner is away. The owner is often someone other than the builder, and ownership should be documented. At the program level, RevOps usually owns the fleet, with security setting access rules and legal or compliance setting oversight thresholds for customer-facing actions.
How do you review an AI agent’s work?
Review agents on a schedule, the way you would review a rep. Track output metrics such as emails sent, meetings booked and conversions, and audit a sample or export of the agent’s messages against what they should say.
How is AI agent governance different from data governance?
Data governance controls how data is defined, stored, accessed and kept accurate. AI agent governance controls what agents do with that data, including who owns each agent, what it can change, how its actions are recorded and what it costs. Agent governance depends on data governance, because agents act on whatever records they read.
How do you tell whether an agent failure is a data problem or a prompt problem?
Start with the data the failing step received. Missing fields, duplicates and stale records produce generic or misdirected outputs, while ignored instructions point to a prompt that’s doing too much. Splitting large agents into smaller, deterministic steps makes the cause easier to isolate.
What are shadow agents, and why do they matter for governance?
Shadow agents are agents and AI tools employees build or adopt without RevOps oversight. They can break silently when their builder leaves, expose sensitive data and keep account context outside your systems, where other agents and future account owners can’t use it.
Which frameworks apply to AI agent governance?
The NIST AI Risk Management Framework gives a practical structure, with four functions: Govern, Map, Measure and Manage. ISO/IEC 42001 is the certifiable standard for an AI management system, the EU AI Act sets risk-based obligations in the EU, and the OWASP Top 10 for LLM Applications covers security risks such as prompt injection and excessive agency. Privacy laws such as GDPR and CCPA apply to any agent that processes contact data.
How do you control the cost of AI agents?
Use platforms that show a cost estimate before work runs, monitor usage during runs and limit who can launch large jobs. Agent Teams, for example, shows an AI Credit estimate before every play. ZoomInfo offers flexible packages built around your needs, and GTM.AI is free to start, with consumption-based credits.
What security certifications should an AI agent platform have?
Look for SOC 2 for security controls, ISO 27001 for information security management and ISO 27701 for privacy information management. ISO/IEC 42001 shows a vendor runs a certified AI management system. Also check how the platform handles role-based access and data residency.
