AI adoption is accelerating. The directive from boards and the C-suite is clear: adopt AI, show ROI, move fast. But for security and GRC teams, that creates a harder question. How do you govern something that moves this fast?
We brought together two people with very different vantage points for a conversation to answer that question. Brad Thies, CEO of BARR Advisory, brought the auditor's perspective from years of helping companies navigate compliance, risk, and emerging technology. Will Bengston, CISO at C1, brought the practitioner side, building governance programs in real time as AI reshapes how teams work.
Here's what they covered.
The governance conversation has finally started#
Six months ago, most companies were stuck in pilot purgatory. That's changed. Brad noted that businesses are moving from AI as an advisor to AI as a decision-maker, with agents approving invoices, triaging workflows, and taking actions across systems. At the same time, the regulatory landscape is shifting fast. The EU AI Act, Colorado's AI law, ISO 42001, and executive orders are all sending different signals.
Will's take was blunter. The models got good enough that people stopped waiting for permission. Companies that locked down AI usage entirely are finding that employees use it anyway, just outside the governed path. "People are using AI whether you like it or not," Will said. The organizations defaulting to "no" aren't eliminating risk. They're just losing visibility into it.
That tracks with what we found in the C1 Future of Identity Report: 95% of organizations surveyed have agents performing tasks autonomously. The gap between adoption and governance is real, and it's growing.
Human in the loop isn't a compliance requirement. Risk thinking is.#
One of the most common questions GRC teams are asking right now: does compliance require human in the loop?
Brad's answer was direct. No. The requirement is that you've thought through the risks and built guardrails around them. The framing he uses with clients is simple: can this agent do something that cannot be undone? If yes, that's higher risk. What's the blast radius? How many things can go wrong at once? That's where you start scoping controls.
He also pointed out that human in the loop can serve as a training mechanism for agents, similar to onboarding a new hire. One of his clients treated their agent deployment like a 90 to 180 day ramp period, coaching the agent through edge cases before letting it run independently. "You wouldn't give somebody just hired onto the company on the first day say, good luck with that client interaction," Brad said.
The takeaway: auditors aren't looking for a checkbox that says "human reviewed this." They're looking for evidence that you understood the risk, scoped the access, and built mechanisms to catch problems.
Access management is the foundation#
Before you can govern what an agent does, you have to govern what it can access. Brad started there for a reason. Giving agents broad, standing access to everything is the same mistake companies made 20 years ago with excessive service accounts. The blast radius just gets bigger when an agent can move across systems at machine speed.
Will broke down how C1 approaches this internally. Agents inherit user-level permissions rather than operating in "God mode." The question is always: who is this agent, what is it doing, and who owns it? A personal assistant agent that surfaces your calendar doesn't need production access. A security triage agent that touches your alert inbox has a very different risk profile.
The principle is least privilege, applied the same way you'd apply it to a human. If an agent needs elevated access for a specific task, it requests it, uses it, and drops it when the task is done. Will compared it to how he'd approach his own work: "I need to go operate in AWS now. Let me go get a permission I don't normally carry to go do the task. And then most importantly, when I'm done with that task, how do I drop off that access?"
The alternative is what happens in practice when teams don't plan for this. Agents accumulate permissions because someone couldn't get things working, gave it broad access as a workaround, and never went back to right-size it.
Tooling without strategy is just noise#
Brad made a point worth repeating: tool adoption that isn't linked to business strategy is noise. Before evaluating any AI tool, companies need a data foundation and clear workflows. Otherwise you end up layering AI on top of broken processes and calling it transformation.
His framework for evaluating what to green-light is a simple quadrant: business impact against feasibility. High impact and high feasibility goes first. Low impact and expensive doesn't get built. But none of that evaluation is possible without linking it back to the business plan. Experimentation is fine. Green-lighting production deployments without that connection is not.
The compliance bar is rising. Start with risk, not frameworks.#
The EU AI Act, ISO 42001, NIST AI Risk Management Framework, CIS companion guides: there's no shortage of new frameworks, and more are coming. Both Brad and Will cautioned against letting that list become overwhelming.
Brad's guidance: treat these as companions to your existing control sets, not replacements. SOC 2 alone isn't the right mechanism for auditing AI. These newer frameworks are management systems that help you think through the nuances AI introduces, like a confused deputy attack that doesn't show up in a traditional vulnerability scan but absolutely belongs in your risk assessment.
Will's emphasis was on speed. If your process for approving a new frontier model takes three to six months, your teams will go around it. Governance has to move at a pace that doesn't stifle the business. That means having a policy and process in place, but keeping it light enough that it doesn't become the bottleneck it was designed to prevent.
What to do first if your governance isn't where it needs to be#
Both Brad and Will landed in the same place on this one:
Start with visibility. Figure out what agents you have in production, what they can access, and who owns them. That inventory is the foundation for every decision that follows, from scoping risk to building controls to knowing whether something needs to be shut down immediately or just brought into a governed path.
Then document it. Brad was emphatic here. Documentation is the thing practitioners always push to the bottom of the list, but auditors need a reference point. If you can't explain what an agent does and why it has the access it has, that's a gap an auditor will find. As Brad put it: prompts are code now. They're configurable items that drive business processes. They need to be documented like code.
Then build from your risk assessment. Don't start with 200 controls. Start with a clear-eyed evaluation of what could go wrong. Brad would rather see a company that did a well-executed risk assessment and explained why they didn't need certain controls than one that checked every box without understanding why.
The bottom line#
AI governance isn't a solved problem. The technology moves first and governance follows. That's not new. What is new is the speed, the blast radius when things go wrong, and the fact that agents are making real decisions with real consequences across production systems.
The companies that get this right won't be the ones with the most controls. They'll be the ones that understood their risks, scoped their access, documented their decisions, and built governance that moves at the speed of the business.
Want to see how C1 approaches identity governance for AI agents? Check out a demo. And for the full data behind the trends we discussed, the 2026 C1 Future of Identity Report is available on our site.
