## The Governance Problem Nobody Wants to Talk About
Honestly, the agentic AI conversations in most boardrooms are dominated by the use cases and the demos. The bit that gets glossed over is the question that matters most: what happens when the agent does something you didn't intend? And I don't mean some catastrophic science-fiction scenario. I mean the agent books a £50,000 server upgrade because it interpreted "optimise our cloud costs" too broadly. Or sends an unfinished draft email to a client because a condition in your workflow triggered prematurely.
These aren't theoretical risks. They're the kinds of things happening in early enterprise deployments right now, and they happen because governance was an afterthought rather than a foundation.
## The Four Pillars of Agentic AI Governance
There's a framework that's emerging across well-run enterprise AI deployments, and it rests on four pillars: scope definition, observability, control, and accountability.
Scope definition means being brutally specific about what an agent is and isn't allowed to do before it runs a single task. This isn't just a list of tools — it's a policy document that specifies constraints: this agent may read from these data sources, may write to these systems, may spend up to this amount, may affect these users, and must escalate if any of these conditions are met. Write it down. Version control it. Treat it like code.
Observability means you can see everything the agent is doing, in real time and historically. Every decision, every tool call, every intermediate reasoning step should be logged. Not just for debugging — for compliance. When your CISO asks "did our AI system access that data before the breach?" you need a complete audit trail that answers that question definitively.
Control means humans can intervene at meaningful points in the workflow. This isn't just a kill switch, though you absolutely need one. It means designing checkpoints into your agent workflows for high-impact decisions: "The agent has decided to delete these 40,000 records — approve or reject?" An approval workflow for significant actions is not optional in enterprise deployments.
Accountability means someone in your organisation is responsible for what the agents do. This sounds obvious, but it's often unclear whether it's the IT team, the data science team, the business owner, or the vendor. Make it explicit. The person whose name is on it tends to think much more carefully about governance.
## Designing Safe Action Boundaries
The technical implementation of safe action boundaries is where theory meets code. The cleanest approach is treating agent permissions exactly like you'd treat service account permissions in your IAM system: minimal privilege, explicit grants, regular review.
Create a permissions matrix for each agent that maps from "business task" to "technical permissions required." For each permission, document why the agent needs it, what the worst-case impact of misuse would be, and what compensating controls exist. This exercise alone will surface a surprising number of permissions you thought were necessary but actually aren't.
Rate limits on agent actions are non-negotiable. An agent that can send 1,000 emails per minute without limit is an incident waiting to happen. Build hard limits into your tool implementations, not just your prompt engineering. If the limit is in the prompt, an adversarial input or an edge case in the agent's reasoning can bypass it. If the limit is in the code, it can't.
## Human-in-the-Loop Design Patterns
There's a spectrum of human oversight for agentic AI, and where you sit on that spectrum should vary by the risk level of the task being automated.
At the high-control end: the agent prepares a recommendation and a human approves every action before it's taken. This makes sense for high-value, low-frequency decisions like procurement approvals or infrastructure changes.
In the middle: the agent acts autonomously within defined boundaries, and a human reviews a summary of what it did at the end of each run. This works for medium-risk, medium-frequency workflows like customer communications or data processing.
At the high-autonomy end: the agent acts fully autonomously, humans only see exceptions. This is appropriate only for low-risk, high-frequency tasks like log parsing or routine data cleanup.
The common mistake is defaulting to high autonomy everywhere because it's the most impressive demo. Start at high control, move rightward only as you build confidence in the agent's behaviour in that specific context.
## Compliance and Regulatory Considerations
For UK organisations, GDPR compliance in agentic AI deserves specific attention. When an AI agent accesses personal data, the same rules apply as when a human does: you need a legal basis, you need to stay within the purpose it was collected for, and you need to be able to demonstrate both.
The challenge is that agents can access and process data very quickly across many sources, which makes it easy to accidentally go out of scope. Build GDPR constraints into your tool definitions — if a tool accesses personal data, it should automatically log the access with purpose, data subject, and legal basis.
The ICO is actively developing guidance on AI governance, and organisations that build proper governance frameworks now will be in a much stronger position when that guidance crystallises into enforcement.
AI governance is not a one-time exercise. Schedule quarterly reviews of your agent permissions, decision logs, and incident history. Technology changes quickly; your governance framework needs to evolve with it.
*For AI governance consultancy and implementation support, contact Lara IT Solutions on 0330 043 1930.*