By David Whitelegg, Deputy CISO – Compliance, Compass Group
AI adoption is moving quickly. In some organisations, probably much more quickly than anyone really knows.
Employees can access powerful AI tools directly through a browser. AI is appearing inside applications organisations already use, developers can add AI capabilities through APIs very quickly, and we are now moving beyond AI that simply generates content towards agents that can access data, interact with systems and take actions.
At the same time, the security conversation around AI is changing. We are moving beyond concerns about what somebody might type into a chatbot or whether a model might produce an inaccurate answer. The bigger question is increasingly what happens when we connect AI to real data, real systems and real business processes, and then give it some level of autonomy.
The opportunity is huge, but from a security and risk perspective it raises a fairly obvious question:
Are we moving faster than our ability to govern it?
I don’t think the answer is to slow everything down. That isn’t realistic and, in most organisations, probably wouldn’t work anyway. The challenge is how we allow the business to move quickly without losing control of the risk.
Do we actually know where AI is being used?
Before talking about governance frameworks, there is a more basic question. Do we actually know where AI is being used across the organisation?
That sounds straightforward, but I’m not convinced it is.
AI adoption isn’t necessarily happening through one big transformation programme with a project team, budget and governance structure around it. It can happen one employee, one application, one development team or one supplier at a time, and increasingly it may arrive through products we already use.
That creates a visibility problem, but simply producing an inventory of AI tools isn’t enough either. Knowing that 50 AI applications are being used tells me very little about the actual risk.
One might be helping someone improve the wording of a presentation. Another could be processing confidential company information. Another might have access to business systems and the ability to take actions. Those are very different things and shouldn’t be governed in the same way.
There is also a danger that we focus too much on discovering standalone AI tools and miss the AI capabilities appearing inside the existing technology estate. The question isn’t simply which AI products are being used. We also need to understand where AI now sits within business processes, what information it can access and, increasingly, what authority it has been given.
Start with what the AI can actually do
For me, this is where the conversation needs to become much more practical. Rather than starting with another policy, start with the capability.
What data can the AI access? What systems can it interact with? What decisions can it make or influence? Can it take an action? What happens if it gets something wrong? And at what point does a human need to get involved?
The answers tell you far more about the risk than simply knowing that something contains AI.
For lower-risk uses, an approved tool, sensible policy and employee awareness might be perfectly adequate. As the capability increases, particularly where AI can access sensitive information or take actions, the controls need to increase with it.
That doesn’t mean putting maximum governance around everything. It means putting the right control around the right risk.
This becomes particularly important with agents. An agent that can read information is one thing. An agent that can modify data, send communications, execute code or interact with production systems is something very different.
The level of autonomy matters.
Having a policy doesn’t mean you have control
We’ve become quite good at writing AI policies. That’s necessary, but it is only part of the answer.
A policy can say employees must not put confidential information into an unapproved AI service. Fine, but how do we know they aren’t?
A policy can say an AI agent requires human approval before taking a sensitive action. Again, fine, but what proves that actually happens?
This is where I think the AI governance conversation needs to move from policy into assurance. It isn’t enough to say what should happen. We need to be able to demonstrate what actually happens.
That might mean access controls, technical configuration, DLP, logs, approval records, monitoring, automated testing or some combination of them. The exact evidence will depend on the risk and the technology, but there should be evidence.
Otherwise, we risk creating something security teams have seen many times before: a control that looks good on paper but doesn’t necessarily operate as intended.
And with AI, there is another complication. The technology isn’t standing still after the initial assessment. Models change, integrations change, data changes and capabilities change. A system assessed six months ago may not present exactly the same risk today.
Governance therefore can’t just be an approval gate at the beginning. We need to know whether the controls continue to work afterwards.
AI agents change the risk
Most of the early discussion around generative AI focused on what went into the model and what came back out. What information are employees entering? Is the answer accurate? Could confidential data leak? Could somebody rely on a hallucinated response?
Those questions haven’t gone away, but agents introduce another question:
What can the AI actually do?
If an agent can access applications, retrieve company information, execute a workflow or make a change, we are no longer just governing what AI can say. We are governing what it can do.
That’s a significant difference.
Recent security guidance around agentic AI is increasingly focused on exactly these issues: excessive permissions, access to connected systems, human oversight, monitoring, containment and what happens when an agent behaves in a way nobody expected.
This isn’t theoretical enough to leave for another year. Organisations are already experimenting with agents and increasingly autonomous workflows.
One principle I’ve used when discussing this is:
AI shifts the work, but it doesn’t shift the responsibility.
If an organisation allows an AI system to act on its behalf, the organisation remains accountable for what it does. So if an AI agent can take meaningful action, I want four fairly simple questions answered:
What can it access? What can it change? Who approved that capability? What evidence shows it stayed inside those boundaries?
None of those questions is particularly revolutionary. We already understand least privilege, segregation of duties, change control, monitoring and accountability.
AI doesn’t suddenly make those principles obsolete. If anything, it makes them more important.
Assume something will eventually go wrong
There is another part of AI governance that I think deserves more attention.
We should stop designing governance on the assumption that AI will always behave exactly as intended.
Recent AI security research and testing has already produced examples of models and agents taking unintended or unsanctioned actions. That doesn’t mean every AI agent is dangerous, but it does reinforce a basic security principle: controls should account for failure.
What happens if an agent misunderstands an instruction? What if it is manipulated? What if it accesses something it shouldn’t? What if a supplier changes an underlying capability? What if it starts taking actions outside the boundaries we thought we’d established?
Can we detect it? Can we contain it? Can we stop it? And afterwards, can we establish exactly what happened?
These are familiar questions in cybersecurity.
We don’t build resilience on the assumption that technology will never fail. We use layers of control, monitoring, incident response and recovery because eventually something will.
AI shouldn’t be treated differently.
For higher-risk agents, that means thinking about blast radius before deployment. Limit access. Limit permissions. Separate environments where appropriate. Monitor behaviour. Protect the evidence needed to reconstruct what happened. And make sure somebody can actually stop the agent if necessary.
That last point sounds obvious, but as autonomy increases it becomes a control requirement in its own right.
Evidence is becoming as important as the control
This is where I think the next stage of AI governance will become particularly interesting.
There is a growing focus across AI security on visibility, traceability and runtime control. That makes sense.
If we say an agent can only access certain systems, can we prove that?
If we say sensitive actions require human approval, where is the approval evidence?
If we say an agent stayed inside an authorised boundary, what telemetry demonstrates that?
And crucially, can we trust that evidence?
For security and assurance teams, these aren’t unfamiliar concepts. We’ve been asking similar questions about identities, privileged access, changes, vulnerabilities and other technology controls for years.
AI introduces different technology and potentially much greater autonomy, but the underlying assurance question remains remarkably similar:
What proves the control actually worked?
Governance shouldn’t become the thing everyone tries to avoid
There is another side to this. Security and risk teams can create their own problems if governance becomes too difficult.
If every experiment involving AI requires weeks of forms, committees and approvals, people will find another route. We’ve seen that before with other technologies.
Good governance should help people use technology safely, not simply make it difficult to use. Give people approved tools, make the rules understandable, provide safe patterns for common use cases, make low-risk experimentation relatively easy, and put the stronger controls around the areas where the consequences justify them.
An employee experimenting with an approved AI tool and non-sensitive information doesn’t need the same governance as an autonomous agent with privileged access to production.
That sounds obvious when written down. Making it work across a large organisation is much harder.
And this is where security needs to be careful not to become the department of “no”. If the safe route takes significantly longer than the unsafe route, we shouldn’t be surprised when people find ways around it.
Good governance should enable speed where the risk allows it.
Speed versus control is probably the wrong choice
This is why I’m not convinced organisations should think about this as a choice between speed and control.
We need both.
Businesses are going to use AI. The potential benefits are too significant to ignore, and the technology is too accessible to assume adoption can simply be centrally controlled.
The role of security and governance shouldn’t be to stand in front of that adoption. It should be to help the organisation understand where the real risks are, put appropriate controls around them and, importantly, be able to prove those controls are working.
We’ve spent a lot of time talking about responsible AI, principles, frameworks and policies. Those things matter, but I think the next question will be harder:
Can you prove it?
Can you show where AI is being used? Can you show what information it can access? Can you show what an agent is allowed to do? Can you show who approved it? Can you show whether the controls operated when they were supposed to? And if something goes wrong, can you show what happened and how you responded?
That is where AI governance starts becoming operational assurance rather than governance on paper.
As AI becomes more capable and more autonomous, that distinction is going to matter. The organisations that get this right won’t necessarily be the ones with the longest AI policies or the most governance committees. They’ll be the ones that can move quickly, understand where the risk is, maintain control and demonstrate that the controls actually work.
Speed with control, rather than speed versus control.
If you’re interested in exploring what Speed vs Control: Are We Moving Too Fast to Govern AI and Risk? means for your organisation – and how cybersecurity leaders can stay ahead of it – we invite you to join the conversation. To learn more or take part, please RSVP below.
