Nobody Has Solved AI Governance. Here’s Why That Just Changed.

Capability or control. That’s the trade-off most organisations accept when they deploy AI.

I’ve watched an entire industry argue about what AI governance should look like. Competing frameworks. Overlapping regulations. No agreed accountability model. Meanwhile, agents are already running inside enterprises, making decisions, processing transactions, accessing sensitive data. Without boundaries anyone can prove are enforced.

Organisations spend millions on AI capability, then govern it into the safest, smallest, least valuable work possible. Not because they’re doing governance wrong. Because the governance they need hasn’t existed.

That just changed. A different class of control is now reaching the Australian market, and it comes at the problem from the opposite end. One built on mathematics, not monitoring. Cyber Impact deploys it.

The governance gap is real, and it’s widening.

The frameworks are multiplying. NIST AI Risk Management Framework. ISO 42001. The EU AI Act, which begins enforcement in August 2026. Australia’s own voluntary AI Ethics Principles are under review, with mandatory guardrails expected to follow. Every one of these frameworks asks the same question: how do you ensure your AI systems stay within acceptable boundaries?

None of them answer it technically.

They describe what good governance looks like. They don’t deliver the mechanism that enforces it. That gap was manageable when AI was a chatbot answering customer queries. It is not manageable when you have autonomous agents executing transactions, triaging security incidents, or managing compliance workflows with real authority and real consequences.

The market’s latest attempt to close the gap? Use AI to watch AI. Monitoring layers, observability platforms, anomaly detection. That’s not governance. That’s surveillance with a lag. By the time the monitoring system flags a boundary violation, the action has already been taken. The data has already been accessed. The decision has already been made.

Or you add human oversight at every decision point, which kills the speed and autonomy you invested in AI to achieve. You end up with the most expensive rubber stamp in the organisation.

Adversarial testing matters. But it’s periodic.

I spent over 15 hours adversarially testing a live AI system earlier this year. The results made international news. I’ve since conducted 20 additional structured test sessions documenting more than 50 distinct failure modes. I’ve also built my own Agentic AI running production work inside Cyber Impact, which is how I know exactly how much value sits behind this governance gap. I believe in adversarial testing and red teaming. It exposes real weaknesses that no amount of policy documentation will find.

But testing is episodic. You run a red team exercise, document the findings, remediate, and move on. Between assessments, nothing enforces the boundaries. Nothing stops an agent from stepping outside the policy your board approved, because the enforcement mechanism doesn’t exist. The policy is a document. The agent is software. Documents don’t constrain software.

What deterministic enforcement actually does.

Deterministic agent control works differently from anything the monitoring vendors are selling. It is not a monitoring tool. It is not AI watching AI. It is a mathematical enforcement layer that sits between your AI agents and your operational environment.

When an agent attempts an action that falls outside your defined boundary, it doesn’t get flagged. It doesn’t generate an alert for a human to review. It gets stopped. Before it acts. The AI doesn’t decide whether to comply. It cannot proceed.

Inside that boundary, full autonomy. Real decisions. Real operations. The value you actually invested in AI to deliver.

This is not heuristic. It is not machine learning classifying behaviour after the fact. It is a provable mathematical boundary. The enforcement is deterministic, auditable, and independent of the model powering the agent. Swap your model from one vendor to another. The boundary still holds. Deploy a new agent framework. The boundary still holds. An adversary attempts to manipulate the agent through prompt injection. The boundary still holds.

That distinction matters for boards. When a director asks management “could you have stopped it?”, the answer is not a promise, not a policy document, not a vendor assurance letter. It is immutable, cryptographically auditable proof that the boundary was enforced, or that it was not.

How it works

Before an agent does anything, it has to ask. A separate system, which is not itself AI, checks the request against your policy and answers yes or no. The answer is recorded. The check happens before the action runs.

This is a recognised product category with a number of vendors selling into it. The checking component is commonly called a policy enforcement point, and what it does goes by runtime enforcement, pre-execution checks, or guardrails outside the model. Cyber Impact selects, deploys and operates the one that fits your obligations.

It does not reduce your agent to a yes or no switch. Your policy sets how far the agent may go on its own, and inside those limits it plans, chooses and acts at machine speed with nobody in the way. What it cannot do is act outside them, because it does not execute anything at all. It proposes, and the enforcement layer acts for it once the request is approved. The credentials that reach your systems sit with the enforcement layer, never with the agent, which is least privilege applied to software that acts on its own, and the component doing the deciding is not itself a model, so it cannot be prompted or talked around.

At the edge the answers are plain. The request proceeds. Or it is refused and the action does not happen. Or it goes to a person, and on the actions that warrant it to several people, where the approval only counts once a set number have agreed, and an approval nobody gives in time is a refusal. Or it goes ahead with the sensitive parts removed, so the work completes without the material your policy will not let leave. And if the layer cannot establish that a request is inside policy, it refuses by default.

This is what makes human oversight enforceable rather than notional. Oversight does not scale to thousands of agents acting in milliseconds. You are not approving every action an agent takes. You are approving the narrow set your own policy reserves for a person, and enforcement holds the line on everything else at machine speed. Above all of it sits a set of actions no software should approve at any confidence level, deleting a tenancy, disabling multi-factor authentication, destroying a backup. Those have no approval path through the enforcement layer at all. A person performs them at the underlying console or they do not happen.

The rules come from the obligations you already carry, the legislation you operate under, the regulation your sector carries, the policy your board already approved. Those are compiled out of prose into a checkable artefact the layer tests every request against. You are not asked to rewrite your obligations as rules; they go in as they are written. Compiling them before anything runs is why the same request under the same policy returns the same answer, and the translation into rules is the step the frameworks never take. When an obligation changes, you change the policy and recompile. You do not redeploy the agent or retrain the model. Governance stops being a rebuild and becomes an amendment.

Every decision the layer makes is written to an append-only, tamper-evident log, and each entry records the version of the policy in force when the decision was made, so an auditor can replay any action years later and reconstruct why it was approved or refused against the policy that applied at the time.

Why this is a board-level issue.

Directors have a fiduciary duty to oversee material risks. AI is now a material risk. Not because the technology is dangerous, but because the governance gap creates liability that no amount of insurance or policy drafting can close.

Consider the regulatory trajectory. The EU AI Act classifies high-risk AI systems and imposes conformity assessments, transparency requirements, and human oversight obligations. ASIC has already signalled that AI decision-making in financial services falls under existing responsible lending and market conduct obligations. APRA’s CPS 230 operational resilience standard applies to AI-dependent processes whether organisations have classified them that way or not.

When a regulator asks how your organisation governed the AI agent that made a consequential decision, the answer cannot be “we had a policy.” It needs to be “we had an enforcement mechanism, and here is the audit trail proving it worked.”

That is what an enforcement layer of this kind provides, and it is what Cyber Impact deploys. The criteria we insist on are the ones easiest to skip in a procurement process: no vendor lock-in, no offshore data processing, and your rules, defined by your organisation, enforced mathematically on Australian soil.

What this means for your AI strategy.

Most organisations I work with are stuck in one of two positions. Either they’ve deployed AI agents with minimal governance and are hoping nothing goes wrong. Or they’ve locked AI down so tightly that it delivers a fraction of its potential value.

The provable boundary approach resolves that tension. You define the operating envelope, the enforcement layer holds it, and inside that envelope your agents operate with the full autonomy the business case requires. You don’t choose between capability and control. You get both.

For organisations deploying hundreds or thousands of agents across operations, compliance, customer service, and decision support, this is not incremental. It is the difference between an AI program that scales and one that stalls at pilot stage because nobody can answer the governance question.

The bottom line.

Nobody solved AI governance because the solution hadn’t been built yet. The frameworks describe the destination. The regulations mandate the journey. But the enforcement mechanism, the thing that actually makes it work in production, has been missing.

It isn’t missing any more.

Cyber Impact delivers it, as AI Governance as a Service. We find the AI already running across your organisation and build the register. We compile the policy from the obligations you actually carry into rules that can be enforced. We select, deploy and operate the enforcement layer that sits outside your agents and checks what they propose, and we hand your board the decision log that proves what the agents did.

It starts smaller than most executives expect. Discovery across the estate, then the enforcement layer running in shadow mode over the agents that matter most, recording what they propose without blocking a thing. You see the true picture before anything changes. Enforcement goes on one surface at a time, starting where the blast radius is smallest, and inside those limits your agents keep the full autonomy you deployed them for.

If your organisation has already solved this problem with a different approach, I’d genuinely like to know what I’m missing. If it hasn’t, and your board is asking how you govern the AI agents already running inside your operations, that’s a conversation worth having.