You Can't Govern the AI You Can't See. You Can't Trust the AI You Can't Stop.

You cannot govern the AI you cannot see, or trust the AI you cannot stop. Both halves of that problem are solvable now. Most organisations have solved neither.

On 21 June 2026, Cyber Impact was on the front page of The Age and The Sydney Morning Herald. The feature was titled "ChatGPT's evil twin: how criminals and extremists are using AI to lay traps". It was about AI turned outward, weaponised against people.

There is a quieter version of the same problem, and it sits inside your own organisation.

You have AI running in places you have not counted, doing work you have not mapped, reaching data you never sanctioned. And once you put an agentic AI to work, one that reads, decides, and acts on its own, what actually stops it doing something you never approved? For most deployments the answer is uncomfortable. You cannot see all of it, and nothing reliably stops the part you can.

That is the whole governance problem in two lines. You cannot govern the AI you cannot see. You cannot trust the AI you cannot stop.

Governance that actually works has to answer both.

What actually changed

The industry has spent two years arguing about how to govern AI. I have written before about why the frameworks describe the destination but never deliver the mechanism. NIST, ISO 42001, the EU AI Act. Every one asks how you keep an AI system inside acceptable boundaries. None of them answer it technically.

Governance, in practice, comes down to two questions a board can act on. What AI is running, and what is it allowed to do. Answer neither and you are governing on faith.

So the work has two halves. The first sees it. The second controls it.

One half builds the picture. The other half holds the line. The control layer is the harder of the two, and I will come to why. But it only means something once you can see what you are controlling.

What you cannot see, you cannot govern

Most organisations cannot see their AI. It arrives through a dozen doors at once, sanctioned tools, shadow subscriptions, agents embedded in products the business already bought, and no single register keeps up.

The first half of the work fixes that. We find what AI is already running across your organisation, what it can access, what it is doing, and who is using it, and we build your AI asset register automatically.

Not a survey. Not a point-in-time spreadsheet that is stale the day it is signed off. A live register, maintained by software, of the AI you actually have.

This matters more than it sounds. Most boards I speak to are working from an inventory that misses the majority of their real surface. You cannot put a control around an agent you did not know existed, you cannot price a risk you have not counted, and you cannot attest to an estate you cannot see. Discovery is what turns AI governance from an assertion into a fact base.

What a control layer actually does

Seeing the estate tells you what is running. It does not stop any of it. That is the second half, and it is the half almost nobody has.

A deterministic control layer does something structurally different from every "control" that came before it. It brokers the connection between your agentic AI of choice and the role you need it to perform.

The agent does not get to decide what it is allowed to do. The control layer decides. Deterministically.

What can the agent do? What can it access? Where is it allowed to act?

In most deployments the answers live inside the model, in weights nobody can inspect and behaviour nobody can prove. Deterministic control pulls those answers out of the model and into an enforcement layer you define and own. The agent proposes. The enforcement layer disposes.

This is not monitoring. Monitoring tells you an agent stepped out of bounds after it already has. That is surveillance with a lag, and by the time the alert fires the data has been touched, the transaction sent, the decision made. Enforcement sits in front of the action, not behind it.

The market's usual answers do not do this. Human oversight at every decision point feels safe and collapses the moment you scale.

Put one agent on real work and a human can shadow it. Put a hundred agents across operations, compliance, and customer service, and 1:1 oversight becomes the most expensive rubber stamp in the organisation. You either drown your people in approvals, or you quietly stop reading them. Either way, the control is gone. And the other reflex, trusting the model's own alignment with better training and a tighter system prompt, is not a control at all. It is a hope, dressed as one.

Why "deterministic" is the whole point

The word doing the heavy lifting is deterministic.

A probabilistic control gives you a different answer depending on how the agent was prompted, what context it was carrying, and whether an adversary managed to talk it into something. A deterministic control gives you the same answer every time, because the boundary is not a judgement the model makes. It is a rule the model cannot reach.

That distinction is the entire argument of my earlier piece on provable enforcement. This is where that abstract case turns into an engineering requirement you can hold a vendor to. When a director asks management "could you have stopped it?", the answer stops being a policy document or a vendor assurance letter. It becomes a property of the system.

Swap the underlying model from one vendor to another and the boundary holds, because it never depended on the model. Point a prompt-injection attack at the agent and the boundary holds, because the agent was never the thing enforcing it. That independence from the model is not a feature bolted on the side. It is the design.

It also directly answers a failure mode I documented separately. AI agents degrade over sustained operation, and they do it silently, without ever flagging that their own judgement has slipped. If the only thing standing between a degraded agent and a consequential action is that same agent's judgement, you have no control at all. An external, deterministic boundary does not degrade with the agent. It holds at hour eight exactly as it held at hour one.

How an action actually happens

The agent never executes anything. It proposes. Every tool call, every system it wants to reach and every dollar it wants to move goes to a separate layer as a request, and that layer authorises the action before it happens. That layer is not itself a model, so it cannot be prompted, persuaded or jailbroken.

None of this is exotic. It is a recognised product category with a number of vendors in it, sold under names like policy enforcement point, runtime enforcement, pre-execution checks, or guardrails outside the model. Cyber Impact selects, deploys and operates the one that fits the obligations you carry.

The layer also holds the keys. The credentials that reach your systems sit with it, never with the agent, and it performs the action on the agent's behalf once the request is authorised. An agent talked into a decision it should not make has nothing to carry it out with. That is least privilege applied to software that acts on its own, with one layer brokering every credential.

Your policy sets how far each agent may go on its own. Inside those limits it plans, chooses and acts at machine speed with nobody in the way. The enforcement bites at the edge of what you allowed, and most of an agent's working day never goes near it.

The limits are sized to the risk. An agent answering customer questions gets wide ones. An agent touching payments gets narrow ones. Same enforcement, different limits, and you set both. The check sits in the live path and costs tens of milliseconds, so none of it slows the agent down or shows up as lag to a customer.

Most requests just proceed

Most of what an agent proposes is inside policy, so it runs at machine speed and nobody hears about it. Four other outcomes cover the rest.

A request can be allowed while some of what it would carry is not. That one goes ahead with the material withheld, so the work still completes. Another class is reserved for a person: your policy names who, and on the actions that warrant it names several, with the approval counting only once a set number have agreed. Those approvals are single use and they expire, and one nobody gives in time lapses.

A request outside policy does not run, and the agent is told so and carries on with the rest of its work. And where the layer cannot establish that a request is inside policy, it does not run either. An outage lands the same way on the actions that matter most.

Above all of it sits a set of actions no software should authorise at any confidence level. Deleting a tenancy. Disabling multi-factor authentication. Destroying a backup. Sending mail as somebody else. Those have no approval path through the system at all. A person performs them at the underlying console or they do not happen.

That is what makes human oversight workable. Nobody oversees thousands of agents acting in milliseconds. You stop approving every action an agent takes and start approving the narrow set your own policy reserves for a person, which is a small fraction of the traffic and the fraction you would have chosen anyway.

Where the rules come from

Policy written for humans cannot be enforced by a machine. "Act in the client's best interests" is a real obligation and an unusable rule. The translation is where the work is.

We start from the obligations you already carry. The legislation you sit under, the regulation your sector carries, the internal policy your board already approved, the commitments in your contracts. Those come out of prose and into rules a machine can check. You are not asked to rewrite your obligations as rules. They go in as they are written.

Those rules are then compiled, before anything runs, into the shape of the region each agent is permitted to work in. At run time the layer matches a request against that fixed structure. Nothing is interpreted at the moment of the decision, because the interpreting was done when the policy was compiled, under review, with your people in the room. That compilation is what makes the answer deterministic: the same request under the same policy comes back the same way every time, whatever the agent was told and however it was prompted.

Not every product in the category works that way. It is one of the things we insist on.

The rules come in two kinds. Some hold regardless of context. The rest are contextual, and the most specific rule that fits the situation wins. That is how a policy handles the grey without leaving the grey to the model.

When an obligation changes, and it will, you change the policy and recompile. You do not redeploy the agent and you do not retrain a model. Governance stops being a rebuild and becomes an amendment with a version number.

The decision log

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

That changes what a board can say out loud. Today most directors can attest to what the policy required. With a decision log they can attest to what the agents actually did, action by action. When the regulator, the auditor or the insurer asks, you hand over the record.

The log is retained for the period your sector requires. The agent side of the system can add entries and cannot list, alter or delete them. That separation is what makes the log evidence rather than a report.

Toy versus infrastructure

Here is the practical consequence, and it is a big one.

You can now put agentic AI onto real work, without 1:1 human oversight for every action, and without betting the farm on the model's own guardrails.

That is the line between AI agents as a toy and AI agents as enterprise infrastructure.

Here is the part most people get backwards. Deterministic control is not there to restrain the agent. It is there to let you unleash it. Once the boundary is enforced from outside the model, provably and every time, you can safely hand the agent more agency, more access, and more consequential work, not less. You stop half-deploying. You stop hedging every pilot with a scope so narrow it never earns its keep.

That is why this accelerates AI adoption rather than slowing it. The thing that usually stalls a programme is the governance question arriving late, the integration, sovereignty, guardrails and governance work where most efforts die with eight proofs of concept and nothing in production. Legal asks where the data goes, the CISO asks about audit trails, and the pilot that looked brilliant in the workshop quietly stops shipping.

Move that question to the front. You see the estate, you define the operating envelope, the control layer enforces it, and inside that envelope the agent operates with the full autonomy the business case actually required. More pilots reach production. They get there faster. The agents that ship are trusted with work that actually matters. You stop choosing between capability and control. You get both, and you get them sooner.

I am not arguing this from a whiteboard. I run agentic AI in production, doing real work across my own business, and the deterministic boundary is exactly what let me put weight on it rather than what held it back. Agentic AI didn't shrink my company; it grew it, and the control layer is what made that growth safe to reach for.

For an APRA-regulated entity, this is not academic. When the regulator asks how you governed the agent that made a consequential decision, "we had a policy" is not an answer. "Here is every AI we run, and here is the enforcement layer that decided what this one could do" is. The same logic reaches every organisation running AI inside a critical function, regulated or not, and it compounds for anyone weighing AI as a source of concentrated, board-level risk.

What your board should demand

1. Show me the AI asset register, and show me it is live. Not the policy-approved list. What is actually running, what it accesses, and who uses it, maintained automatically. You cannot govern, price, or attest to an estate you cannot see.
2. Show me the enforcement layer, not the policy. Ask to see the mechanism that stops an agent, not the document that says it shouldn't. If the only control is the model's own behaviour, you do not have a control. You have a hope.
3. Prove the boundary is independent of the model. If we swap vendors or a model updates overnight, does the boundary still hold? A control that depends on the specific model is a control that expires without notice.
4. Ask what happens on a prompt-injection attack. An adversary will try to talk the agent into acting outside its role. Deterministic enforcement means the answer does not change no matter how persuasive the input. Confirm that, specifically.
5. Retire 1:1 human oversight as the scaling plan. A human approving every action does not survive contact with a hundred agents. Ask how control scales without a person in every loop, because that is the question that decides whether AI ever leaves pilot.
6. Ask who holds the credentials. If the agent holds the keys to the systems it touches, every other control is advisory. The keys should sit with the layer that approves the action, and the agent should have to ask every time.
7. Ask to see the decision log. Every approval, every refusal, every escalation, append-only and replayable, each one recording the policy version in force when the decision was made. A log you cannot replay is a report.

The bottom line

For two years the choice looked like capability or control. Move fast and hope, or lock it down and get a fraction of the value.

That trade-off was never real. It was just unbuilt.

You govern AI on two things: what you can see, and what you can stop. See the whole estate, then enforce the boundary from outside the model, and an agent stops being a clever demo and becomes infrastructure you can put weight on. Or, to put it the way I usually do, so your AI agent can do useful work without being able to wander off and try to kill you.

This is the commercial case, not the compliance one. The provable boundary is not what slows your AI programme down. It is what finally lets you speed it up, with more agents in production, more real work trusted to them, and a higher share of pilots that actually ship. Control is the accelerator, not the handbrake.

This is work Cyber Impact does, under AI Governance as a Service. Discovery builds your live register. The obligations you already carry become rules a machine can enforce. The control layer runs outside your agents, and your board gets the log that proves what happened.

It starts smaller than most executives expect. Discovery across the estate, then the control layer in shadow mode over the agents that matter most, which is the industry's name for watching and recording without enforcing anything. You see what your agents are really doing for a few weeks before a single action is held back, and that first report is usually the most uncomfortable document a leadership team reads all year. Enforcement then goes on one surface at a time, starting where the blast radius is smallest.

If your board is asking how you govern the agents already running inside your operations, whether you can even see all of them, and whether you could stop one before it acts rather than after, that's a conversation worth having.

Sources

• The Age, "ChatGPT's evil twin: how criminals and extremists are using AI to lay traps", 21 June 2026. https://www.theage.com.au/national/chatgpt-s-evil-twin-how-criminals-and-extremists-are-using-ai-to-lay-traps-20260508-p5zv6x.html
• Cyber Impact, "Nobody Has Solved AI Governance. Here's Why That Just Changed." https://cyberimpact.com.au/ai-governance-executive-insight/
• Cyber Impact, "APRA Called for a Step Change on AI. Most Boards Aren't Ready." https://cyberimpact.com.au/apra-ai-step-change-reflections/
• Cyber Impact, "Agentic AI didn't shrink my company. It grew it." https://cyberimpact.com.au/agentic-ai-executive-productivity/
• Cyber Impact, "When AI Agents Forget How to Think." https://cyberimpact.com.au/ai-agents-forget-to-think/