Agentic AI Governance: Running AI Agents Like Employees

TL;DR

Two enterprise Chief Data and Analytics Officers, one at a professional services firm and one running industrial facilities, explain how they govern agentic AI in production. Every agent runs in its own compute, carries its own identity tied to a named owner, inherits role-based access controls, and gets audited like a person. Autonomy is earned through checkpoints, not configured at deployment. Projects that cannot show a 20% return do not proceed. The recap video is below, the full transcript is at the end of this page.

What is agentic AI governance?

Agentic AI governance is the set of policies, controls and operating rules that let an enterprise grant autonomy to AI agents incrementally while keeping a named human accountable for each one. In practice it has four parts: (1) identity, so every agent has its own ID, its own compute, and an owner; (2) earned autonomy, so agents start with a human approving every action and gain independence as approvals outweigh corrections; (3) data thresholds, so an agent only acts on data certified as good enough for that decision; (4) economics, so every agent has a business case, a token budget and a return it can be measured against. Model choice barely features. Governance is what separates the demo from the deployment..

Agentic AI governance: the 14-minute recap of our panel with the Chief Data and Analytics Officers of Wipfli and Reworld. Full 53-minute session and transcript at the end of this page.

In this recap:

• 0:00 Where agentic systems deliver value today 
• 1:13 Digital employees: own compute, own identity, named owner
• 3:19 Beyond RPA: the intern-to-apprentice trust model
• 4:14 How clean does the data need to be? The lumber analogy
• 7:51 Why agentic AI fails to reach production: token costs and the 20% ROI rule
• 8:48 Sensitive data: RBAC and auditing agents like employees
• 11:44 Where to draw the line on autonomy
• 12:48 Connecting agents: MCP servers and orchestration

Most enterprise AI projects die somewhere between the demo and the deployment. The model worked and the POC impressed the right people. Then it hit real data, real workflows and the kind of organizational messiness no sandbox prepares anyone for, and it fell apart. You hear the same postmortem from different people at different companies. The technology is not the problem. Everything around it is.

That gap is what our panel set out to close. Brett Berhoff, Founder and CEO of Strategy.xyz and a BairesDev Fellow, moderated. The two practitioners are well past the pilot stage: Charlie Boyle, Chief Data and Analytics Officer at Wipfli, a professional services firm, and Charles Link, Chief Data and Analytics Officer and AI Evangelist at Reworld, which runs waste-to-energy facilities. Neither is running experiments any more. They are running systems.

When we polled the audience on where they are, the spread was telling:

• Not using AI with the data platform yet: 10%
• Experimenting with AI: 28%
• AI embedded in some workflows or analytics use cases: 42%
• AI used in core production decision-making: 20%

Asked about their priority for the next six to twelve months, 22% said moving AI into production workflows, 19% scaling AI across teams, and 28% embedding AI into core systems and decision-making. In other words, most of the audience is about to need exactly the governance model this panel describes. That matches the wider picture: McKinsey finds that only 1% of leaders describe their company’s AI rollout as mature, and the gap is rarely the models.

What Is Agentic AI Governance, and How Is It Different From Traditional AI Governance?

Traditional AI governance covers models: how they are trained, what training data they use, how they are validated, monitored for drift and bias, and documented for regulators. Agentic AI governance has to cover actions. An agent does not just produce a prediction; it applies context, makes a judgment call and takes a step in a live workflow, often through tool calls that reach external tools and business systems. Because agentic AI systems operate across multiple systems with delegated authority, the organizational risk compounds in ways a single model never created, and the existing AI governance frameworks most enterprises adopted for responsible AI were not written for agents that act.

Why agentic AI governance matters now: AI agents act autonomously across data systems and intelligent systems that were never designed for non-human users. From a governance perspective, the moment autonomous AI systems operate independently, three questions need an owner: who carries organizational accountability for what the agent did, what data the agents process and how you protect data they can reach, and how autonomous systems get stopped. Effective agentic AI governance answers those before the first agent ships. Agent governance, in other words, is less about the model and more about the operating rules around it.

Charles Link draws the line against robotic process automation. RPA automates a process with a scripted response to a set of criteria. The agentic part is “taking the step beyond the traditional RPA, not just automation of a process, but rather being able to apply context,” so the outcome of the action can vary and the system starts to make judgment calls. “That’s where the intelligence comes in. But that also is what stresses the criticality of keeping human in the loop for some period of time.”

So governing AI agents means governing three things a model-centric governance framework never had to: who the agent is (agent identity), what it is allowed to do on its own (defined authority and human oversight thresholds), and what data it is allowed to access and act on (data governance and data protection). Regulatory compliance is moving the same way. The EU AI Act requires human oversight measures and automatic event logging for high-risk AI systems, the NIST AI Risk Management Framework organizes governance practices into govern, map, measure and manage functions, and ISO/IEC 42001 turns them into an auditable AI management system. The panel’s model maps onto all three, but it was built from agent operations, not from a compliance checklist.

Give Every AI Agent an Identity: Own Compute, Own ID, Named Owner

Most governance conversations focus on what agents can do. Fewer focus on who is accountable when something goes wrong. That accountability gap closes only with architecture.

Link’s team found this out early. After more than a year of experimenting with autonomous agents, including playing out scenarios of what could genuinely go wrong, they wrote an agentic governance rule into policy: “Each digital employee has to run in their own instance of compute. Each one has to have its own ID tied to an owner.” If an agent goes rogue, you know whose problem it is, and you can see what it was actually allowed to do.

The implications go beyond containment. Once an agent has an identity, it can be governed the same way a human employee is: role-based access controls, permission scopes, and behavioral auditing all apply. “That ID is just like any other employee. You apply the roles and the security to them as an individual as well.” Link’s team monitors agents for unusual patterns the same way they audit a person querying a database: are they looking at too many things, are they doing things outside their job description? “It’s really no different than you would do with a human employee.”

Charlie Boyle approaches the same problem from the data side. Every dataset and data product at Wipfli carries role-based access controls, and the AI solutions built on top inherit that structure. Certified data products are designed to be reused across personas, from Power BI users to teams querying with large language models, without bypassing the governance layer underneath.

The lesson both practitioners have internalized: an agent without an identity is an agent without accountability.

Autonomy Is Earned: Human Oversight Thresholds and the Intern-to-Apprentice Model

Ask most organizations how they plan to govern autonomous AI agents and you get a policy document. What you rarely get is an answer to the operational question: how does an agent earn the right to act on its own?

Link’s mental model, which he gives his whole company, is an employee lifecycle. “Think of it as an intern, then an apprentice, and someday, after enough practice, trusted to operate on its own. But even a brand new human employee coming into the organization may make completely wrong decisions without the right context and guidance.” The bar for an agent should not be lower than the bar for a person.

The mechanism is measurable. Right now Link’s team grants very little autonomy. A human in the loop sees the agent’s proposed action, presses agree or disagree, and only then is the action taken. “As we start to see that the agrees outweigh the disagrees or the corrections, more autonomy will be granted.” The checkpoint is built into the agentic flow itself, not bolted on as a review step afterwards.

Boyle’s version is crawl-walk-run with a QA engineer paired to every automated data pipeline until the agent has demonstrated it does not need one. “At some point in time, the agent’s going to learn and be trained well enough that we could remove that QA engineer and have them reassigned in other areas.” He frames that transition as a productivity unlock earned through demonstrated reliability, not as a cost cut.

Trust is not a setting you configure at deployment. It accumulates action by action, checkpoint by checkpoint. In governance terms, both teams define human oversight thresholds up front: which agent actions need human approval, which can run with human operators reviewing after the fact, and which the agent can execute independently. Autonomous execution is the last stage of that ladder, not the starting point.

Where to Draw the Line: When Agents Act Alone and When Human Authority Stays

Both leaders keep a firm human line around high-consequence decisions, and both describe it in terms of trust in observed agent behavior rather than in the technology. Autonomous agents earn scope the way people do.

For Boyle the line sits at anything that touches firm growth, compliance, or client data security. Professional services firms hold very sensitive client and account-level data, and “we need to make sure that we manage our clients’ data and we secure it appropriately.”

Link does not name a hard line. “It’s going to all be about the trust. Trust is earned, not given.” People stop wanting to be in the loop when they are comfortable enough to turn it over. “Almost anything can ultimately be autonomous, but it definitely needs time to learn what the values of the population that it’s serving and operating within.”

Governing the Data Agents Act On: How Clean Is Clean Enough?

Of everything underneath an agent, data readiness is where most agentic initiatives quietly break down, because nobody asked whether the data was good enough for an agent to act on without a human catching the error downstream.

Link’s framing cuts through the usual data quality debate. “Some lumber is good enough to be used for framing a house. Some lumber is good enough to be used for making a fine piece of furniture. But they’re not necessarily interchangeable. It depends on what your use case is.” An agent making operational decisions in a live workflow has a different data threshold than a dashboard or a lead-scoring model, and most organizations have not defined where that line sits. You will never have perfect data, he adds, “but as long as you know if it’s good enough to do something with, then it’s good enough, and as long as you know you have a path to remediate when the data moves.” The prerequisite is a well-managed data supply chain from the point of origin to the point of consumption. Otherwise, “it’s like living on a steady diet of junk food. You’re not going to become an athlete that way.”

Boyle’s answer is infrastructure. Wipfli is working through master data management for every key table and dataset, building mastered golden records that feed semantic models and become certified, reusable data products. His team follows an “eat what we fish” rule: they use the data they curate. The metric he manages to is insights velocity: how quickly a certified data product is developed, reused across the enterprise, and turned into a faster business decision.

His favorite metric is one he cannot measure: how often business partners testify to the value when presenting to the board. “I call that trust.”

Keeping Agents Away From Sensitive Data: Identity and Access Controls

The security question came in two parts: how do you let agents interact with sensitive enterprise data, and how do you keep them from returning things people should not see?

Link’s cautionary example is early Copilot deployments. People asked questions and, because SharePoint sites were not secured, the assistant returned whatever it found, including a bonus spreadsheet someone had uploaded assuming nobody would ever hit their site. “It was bringing all this stuff back, whether you’re allowed to see it or not.” Turning an agent loose on your databases carries the same risk. The fix is to let the agent inherit the security already defined in your data platform, so a user interacting through the agent cannot see anything outside their own scope. Platforms such as Snowflake and Qlik apply that model, and the agent comes back with “I can’t share that with you because you’re not authorized.” That only works if the security model is well defined to begin with. “You don’t want plans for mergers and acquisitions being queried by the general populace.”

Boyle’s control is the same one that governs everything else at Wipfli: role-based access controls on all datasets and data products, with governance protocols to prevent sensitive client and account data from being impacted by AI.

And for autonomous agents specifically, Link brings it back to identity and access: the agent has its own ID, so the roles and security are applied to it as an individual, and the same continuous monitoring that catches a human looking at too many records catches an agent doing the same. Agent activity becomes a human-readable audit trail because the agent is a principal in the identity system, not a service account shared across multiple agents.

Why Agentic AI Projects Fail to Reach Production

Agentic AI does not usually fail because the agent underperformed. It fails because the conditions for it to perform were never built. The panel named four failure modes.

Starting from the wrong end. Boyle’s team designs agentic workflows backward from the use case rather than forward from the data. “We want to spend time in the intake, we want to understand their objectives, we want to ask what problems we’re trying to solve for with the solution, and execute from there.” The mistakes happen when teams assume they know what the end user needs from what they know about the dataset.

Cost blindness. Boyle’s overlooked risk is cost: “You build enough of these agents, you do enough pilots, you’re going to start racking up the costs on tokens.” Link agrees that AI is not always cheaper than a person, and his team applies a hard filter. They know their token burn rate, they run experimental work on open-source models in-house so they are not burning commercial tokens on unproven agents, and every initiative has a business case. “If it’s not greater than 20%, we don’t go forward with it.”

Solutions looking for problems. “A lot of people will go forward because it’s a solution looking for a problem, when it’s all the rage,” Link says, “instead of a problem that could use this as a solution or an accelerator or enabler.”

Prompt illiteracy at workforce scale. Users who are not fluent with AI tools quietly rerun agent queries several times to get a workable output, and token costs compound in ways nobody budgeted. Well-structured semantic models reduce that surface area if the architecture was designed with the risk in mind.

The agent is the easy part. Everything underneath it takes the work.

Connecting Agents: Model Context Protocol, Multi-Agent Systems and Orchestration

Once an enterprise has more than a handful of agents, the governance question becomes how they talk to each other and who orchestrates them.

Link’s answer is that MCP servers, built on the Model Context Protocol, are key, and that the real goal is bodies of agents working together. Today his team runs specific agents that each do a plethora of work. Where they are heading is a model where a person states the outcome they want and the AI orchestrates: “We need some time from this guy, this guy and this guy,” meaning agents, “and together they will put together a solution for you to this particular problem, and just spin them up, spin them down as needed.”

Boyle parses it by persona and use case at the highest level, starting from the core productivity use cases where an agent can assist with day-to-day delivery and proposals, so that each deployment maps to a role and a measurable outcome rather than to a technology.

Governance implication: in multi-agent systems the orchestration layer is where identity, permissions and checkpoints have to live, because it is the one place every agent passes through. It is also where agentic AI security has to be enforced, since an agent invoking another agent is a new path into enterprise systems that no single-agent control covers.

Measuring It: The Metrics Executives Actually Care About

Boyle measures adoption, the number of queries and prompts run through the solutions his team has built, and the business outcomes behind them: elimination of day-to-day administration, more billable hours tied to client delivery, more proposals in front of prospects.

Link keeps executives away from AI-specific metrics on purpose. The metrics that matter are the same ones the business has always used, and each initiative carries a business case with a directly attributable return. “If all in you’re not going to get more than 20% at a minimum that we can directly tie, we don’t bother going forward.” AI spend is managed like any other investment, no different than adding staff.

An Agentic AI Governance Framework You Can Copy

Pulling the panel’s practices together, this is the governance framework two production teams actually run:

How to implement agentic AI governance across the agent lifecycle

The framework above is what the two teams run. If you are starting from zero, the order that follows the panel’s own lessons, and lines up with the lifecycle management most AI governance frameworks now describe, is:

1. Define the agent’s scope and authority. Start from the use case, not the data. Write down what the agent is for, what actions it may take, and what operational authority it does not have.
2. Map identity and access boundaries. Give the agent its own identity, its own compute, an owner, and access controls inherited from the data platform. Agents access only the data sources and external tools their role requires: least privilege, applied to a non-human principal.
3. Run a pre-deployment impact assessment. Play out what could go wrong, as Link’s team did for a year before writing policy. Classify the agent by the consequence of a bad action.
4. Set the data threshold. Decide how clean the data must be for this decision, and who signs off that it meets the bar.
5. Define human oversight thresholds. Which actions need human approval before execution, which are reviewed after, which run independently. Start with approval for everything.
6. Implement logging and traceability. Every agent action, tool call and data access recorded against the agent’s identity, in a form a human can read.
7. Plan incident response and shutdown. Know how to revoke an agent’s access and stop it, and who is called when it misbehaves.
8. Establish ongoing evaluation. Track agreements versus corrections, audit agent behavior for drift, and revisit the autonomy level and the business case on a schedule.
9. Decommission deliberately. When an agent is retired, revoke its identity and access, archive its audit trail, and remove its data connections, so a forgotten agent does not become a standing risk.

Conclusion

Boyle and Link are not working with better models than everyone else. They are working with the same technology and getting different results because they built the conditions for it to work: autonomy earned through checkpoints, agents treated as accountable team members rather than black boxes, data validated against the threshold the agent needs, and use cases chosen because they solve a real problem. That is the work that separates a demo from a production system, and based on where most organizations still are, it is the work most worth doing.

If you are ready to put that governance model into practice, our AI software development services team builds and operates production agents under exactly these controls, or reach out to our team (https://www.bairesdev.com/contact-us/) directly. For the engineering side of the same problem, see our companion panel on AI agents in production.

Key Takeaways

1. Govern agents like employees: own compute, own ID, named owner, role-based permissions, behavioral audit.
2. Autonomy is earned, not configured. Start with a human approving every action and expand as approvals outweigh corrections.
3. Keep hard lines around strategy, compliance and client data, however well the agent performs elsewhere.
4. Define the data threshold per use case. Framing lumber and furniture lumber are not interchangeable.
5. Let agents inherit the platform’s security model so they never return data outside the user’s scope.
6. Every agent needs a business case. No 20% directly attributable return, no project.
7. Orchestration is where governance lives once you have more than a few agents.

Watch the Full Session

The full 53-minute session includes both audience polls, the discussion of teaching legacy systems new tricks, and the audience Q&A on early warning signals for an AI initiative that will not be used.

Transcript: Agentic AI Governance Recap (14 min)

Lightly edited for readability. Timestamps match the recap video above. Speakers: Brett Berhoff (host), Charles Link (Reworld), Charlie Boyle (Wipfli). The host addresses Boyle as Charlie.

Where agentic systems deliver value today

[0:00] Brett Berhoff: What we want to unpack is simple. Where are agentic systems actually delivering value today, and what’s getting in the way for everyone else? I’ll start with Charles Link.

[0:18] Charles Link: Where we are seeing immediate impact is in increasing the productivity of our knowledge workers, helping them with tasks where they would normally say, “If I could only get another staff member.” That just never happens in the modern company. This is a force multiplier for them.

[0:41] Brett Berhoff: And what are you seeing, Charlie?

[0:48] Charlie Boyle: The biggest value add for agentic systems is access to faster decision-making. Being able to execute on the data in real time or near real time, driving more operational efficiency at scale, enabling our teams to be more productive, doing more with less.

[1:13] Brett Berhoff: Charlie, how is your organization currently using AI within your data platform or analytics environment?

[1:20] Charlie Boyle: It’s very use-case specific right now. There’s a concerted effort for us to shift from operational, static, diagnostic dashboards to proactive decision intelligence systems.

[1:38] Charles Link: For us, we’ve been working on creating what I would call digital employees that can do a multitude of tasks through a combination of contexts to deliver a better outcome. That model is what we are now leveraging to create autonomous operations for our facilities, the more industrial side of the house.

Digital employees: own compute, own identity, named owner

[2:08] Brett Berhoff: Are you going any further with identifying each digital employee?

[2:19] Charles Link: Yes. We’ve had to be very specific. We’ve been experimenting with this for over a year and have played out the scenarios of what could really go wrong, so we are formulating policies. Each digital employee has to run in its own instance of compute. Each one has to have its own ID tied to an owner. We can see these things go rogue, and we’re monitoring for what they’re actually being allowed to do.

[2:53] Charlie Boyle: In practicality, as we apply more automation of workflows and of the data flow to improve business outcomes, we’re at the convergence of how we bring data, AI and governance together in our Databricks platform.

[3:17] Brett Berhoff: And what are your thoughts on it, Charles?

Beyond RPA: the intern-to-apprentice trust model

[3:19] Charles Link: For us, the agentic part is taking the step beyond traditional RPA: not just automation of a process, but being able to apply context, so you have more flexibility in the outcome of the action, not just a scripted response to a set of criteria, and it actually starts to make some judgment calls. That’s where the intelligence comes in. But that is also what stresses the criticality of keeping a human in the loop for some period of time. I tell everybody in our company: think of it as an intern, then an apprentice, and someday, after enough practice, trusted to operate on its own. Even a brand new human employee coming into the organization may make completely wrong decisions without the right context and guidance.

How clean does the data need to be? The lumber analogy

[4:14] Brett Berhoff: How do you make sure the data is clean enough for all the things you’re talking about doing?

[4:25] Charles Link: The operative word you used was “clean enough.” It depends on the use case. I like the analogy of lumber: some lumber is good enough to be used for framing a house, some is good enough for making a fine piece of furniture, but they’re not necessarily interchangeable. The trick is a well-managed data supply chain from the point of origin to the point of consumption. You’re never going to have perfect data. But as long as you know it’s good enough to do something with, then it’s good enough, and as long as you have a path to remediate when the data moves. Otherwise it’s like living on a steady diet of junk food. You’re not going to become an athlete that way.

[5:20] Brett Berhoff: I like the lumber analogy. Charlie, your thoughts?

[5:22] Charlie Boyle: We’re very focused on the foundational components of AI readiness. We’re actively working through master data management for all of our key tables and datasets, building mastered golden records that we can leverage in semantic models as certified, reusable data products. We have an “eat what we fish” process: we leverage the data that we curate. My biggest performance metric is data velocity, or insights velocity: how quickly am I able to develop a certified data product that’s reused in the business at the enterprise level, and how is that enabling better, faster decisions? But probably the most meaningful metric is one we can’t measure: how many times our business partners testify to the value they’re getting when presenting to our board of directors or executive leadership team. Everything you’ve invested in for the last six years, that actually mattered. I call that trust, and that’s probably the hardest qualitative metric to measure in any organization. For me, making sure the data is AI-ready: we’ve got the architecture in place, we’ve evaluated the tools, we’ve governed them so that we’re protecting the data from an InfoSec perspective. One that gets overlooked but is always in the back of my mind is cost. You build enough of these agents, you do enough pilots, you’re going to start racking up the costs on tokens.

Why agentic AI fails to reach production: token costs and the 20% ROI rule

[7:51] Brett Berhoff: Charles, why does agentic AI fail to reach production?

[7:56] Charles Link: In one case, and Charlie hit on this, cost. AI is not always less expensive than a person. We’ve been doing this for a while, so we have a pretty good idea of the burn rate on tokens. We also have the ability to do some processing in-house, so for things that are more experimental we don’t necessarily have to burn tokens; we use open-source models. But knowing what that total cost is, look at the return on the initiative for this use case. If it’s not greater than 20%, we don’t go forward with it. A lot of people will go forward because it’s a solution looking for a problem, when it’s all the rage, instead of a problem that could use this as a solution, an accelerator or an enabler.

Sensitive data: RBAC and auditing agents like employees

[8:48] Brett Berhoff: What are your thoughts on AI interacting with sensitive enterprise data: how to keep it separate, keep it safe, integrate it or not?

[8:59] Charles Link: When we did our early experiments, there weren’t a lot of providers offering MCP services or data services for AI, and it could be a big risk to just turn it loose on your databases. Even early forays into Copilot: people were asking questions and, without their SharePoint sites being secured, it was returning things. Somebody uploaded a bonus spreadsheet and never thought anybody would hit their site. It was bringing all this back, whether you’re allowed to see it or not. A lot of providers these days can apply the security that is part of your data solution or model. Snowflake can do it, Qlik can do it, so the user interacting with the data can’t see anything outside their scope of security. Then it goes back to making sure your security models are well defined, so it comes back and says, “I can’t share that with you because you’re not authorized.” You don’t want plans for mergers and acquisitions being queried by the general populace.

[10:24] Brett Berhoff: And Charlie?

[10:26] Charlie Boyle: We’ve got role-based access controls on all of our datasets and the data products we develop. All too often we’ve got very sensitive client or account-level data out there that we need to manage effectively, and we make sure we’ve got the right governance protocols in place to prevent it from being impacted by AI.

[10:53] Charles Link: That goes back to what I said: each autonomous agent gets its own ID. That ID is just like any other employee. You apply the roles and the security to them as an individual as well.

[11:07] Brett Berhoff: Now that you’ve got the ID associated with them, are you identifying trustworthiness issues on that particular ID and tracking them as they come up again?

[11:25] Charles Link: Yes. It’s the same way we audit people doing things in the database. Are they looking at too many things? Are they doing unusual patterns outside their job descriptions? It’s really no different than you would do with a human employee.

Where to draw the line on autonomy

[11:44] Brett Berhoff: Charlie, where do you draw the line at autonomy?

[11:46] Charlie Boyle: When it impacts major issues as they relate to firm growth, or compliance. There are areas where we need to stay close: data security, from a professional services perspective, making sure we manage our clients’ data and secure it appropriately.

[12:14] Charles Link: I don’t know that I’d say I draw a hard line. Effectively it’s all going to be about trust. Trust is earned, not given. People stop wanting to be in the loop when they’re comfortable enough to turn it over. Almost anything can ultimately be autonomous, but it definitely needs time to learn the values of the population it’s serving and operating within.

Connecting agents: MCP servers and orchestration

[12:48] Brett Berhoff: What’s the best way to have these systems talk to one another, measure business outcomes, and make sure they’re cohesive, working together or in parallel?

[13:04] Charles Link: MCP servers are key to that. What we’re really needing to do is to be able to say, “This is what I’m trying to do,” and let our AI orchestrate: “We need some time from this guy,” and when I say this guy, I mean the agent, “this guy and this guy,” and together they will put together a solution for you to this particular problem and handle it for you. Spin them up, spin them down as needed to take care of the matter.