I recently attended AI Governance: From Principles to Practice, an Atlanta Intown Alumni Network event hosted at OneTrust. The panel brought together practitioners from OneTrust, Google, EY, and KPMG to discuss how organizations are turning AI governance from principles into practice.
OneTrust co-founder Blake Brannon shared what he has been hearing from CISOs. One concern stood out to me: the sheer complexity of governing so many systems, tools, agents, and connections at once.
That complexity raises three questions:
- What is running?
- Do we trust it?
- What is it doing?
Those sound like questions every security team should be able to answer. But as organizations connect AI models to internal data, external tools, and workflows that can take action, getting a confident answer becomes much harder.
Agents inherit our access, not our trust
Consider a simple example: I might trust Rebecca not to delete a database record. But do I trust Rebecca's agent to make the same judgment?
Giving an agent a person's permissions does not give it that person's context, caution, or accountability. And an agent that can reach one system may be able to interact with several others through connected tools. Each new integration creates another relationship to understand and another path to monitor.
That is why the tooling problem can feel like whack-a-mole. It is not just about reviewing one model or approving one use case. We have to understand what can connect to what, which actions are permitted, and how to contain behavior that goes somewhere we did not intend.
The question I left with was: How do we evaluate risk at agentic speed?
Who grades the homework?
Another challenge raised in the discussion was whether we can rely on the same AI system to assess its own behavior. Nobody grades their own homework.
An LLM can explain why it took an action, but is that explanation enough? What should be independently checked? What can be evaluated within the system, and what needs a separate source of evidence?
This is where the engineering side of governance matters to me. Policies and intended behavior are necessary, but they are not the same thing as observing what actually happened. We need useful records of actions, access, outcomes, and exceptions, along with ways for humans and independent checks to challenge the system's account of itself.
Behavior is evidence. Intent is a claim.
I do not think that means intent is irrelevant. It means we cannot stop at what a model, developer, or vendor says a system is supposed to do. We have to find ways to see what it really does.
November is for AI Governance
These questions are a perfect lead-in to the GRC Engineering Club's November community theme: AI Governance, with the tagline “Govern what is changing.”
The focus is on making governance observable and operational while organizations deploy new systems faster. I want us to spend time on the practical questions: How do we inventory agents and connections? How do we limit what they can do? What should we log? What evidence would convince us that a safeguard works? And how do we make those answers sustainable instead of another spreadsheet that is out of date next week?
If you are new to AI governance, you do not have to arrive with the answers. If you have been building these programs for years, I hope you will bring the hard questions and what you have learned. That is what our community is for.
Keep an eye on the chapter events calendar and community themes as November approaches. We will keep exploring how to turn big governance ideas into things we can actually test, observe, and improve.
Because if AI is moving at agentic speed, our governance practices cannot afford to stand still.