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, something outside it has to stop it doing what you never approved. For most deployments the position 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 things a board can act on. What AI is running, and what it is allowed to do. Know 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.

Cyber Impact delivers both halves, under AI Governance as a Service. Discovery, to build and maintain the register. An external control layer, to enforce what each agent is allowed to do. And the evidence trail underneath both, so the board is attesting to what the agents actually did rather than what the policy said they should. The rest of this piece is what that control layer does and why it works.

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.

That settles three things before the agent acts. What it can do. What it can access. Where it is 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 the board asks management whether it could 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.

Allow, deny, escalate

Here is the part that makes it survive contact with a real organisation. The control layer does not have two answers. It has three.

Allow. The action sits inside the envelope, so it proceeds at machine speed, with nobody in the way.

Deny. The action sits outside the envelope, so it does not happen. Not flagged, not queued for review next Tuesday. Refused before it executes.

Escalate. The action sits on the edge, high value, unusual, or reserved by policy for a person. It stops and waits for a named human to decide.

That third outcome is what retires 1:1 human oversight. You are no longer approving every action an agent takes. You are approving the narrow set your own policy says a person should approve, and everything else runs unattended. Your people end up on the decisions that genuinely warrant a person, which is where you wanted them before the approvals queue swallowed them.

Above all of it sits a tier you can make absolute. Some actions should never be authorised by software at any confidence level, however good the case looks in the moment. Moving money past a threshold. Writing to a production database. Contacting a regulator. You put those beyond the control layer's authority entirely, so they cannot be approved in band at all and require a separate human path. The agent cannot reach them, and neither can the thing governing the agent.

Governance becomes something you edit

The envelope is not compiled into anything. It is a policy artefact, loaded into the control layer and versioned like any other controlled document.

We write it from your actual obligations. The legislation you sit under, the regulation your sector carries, the internal policy your board already approved. Those get translated out of prose and into rules a machine can enforce. That translation is the step every framework skips, and it is most of the work.

When an obligation changes, and it will, you change the policy. You do not redeploy the agent. You do not retrain a model. You do not reopen a vendor contract. Governance stops being a rebuild and becomes an edit.

Evidence, not assurance

Every decision the control layer makes is written to an immutable, cryptographically verifiable log. Every allow, every deny, every escalation, against the policy version that produced it.

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, and replay any one of them. When the regulator, the auditor or the insurer asks, you are not handing over an assurance letter. You are handing over the record.

Two practical points, because they decide whether this survives contact with production. It is fast enough to sit in the live path, with decision latency in the tens of milliseconds, so it does not slow the agent down or surface as lag to a customer. And it can run in shadow mode first, watching and reporting without enforcing anything, so you see what your agents are really doing for a few weeks before a single action is blocked. That first report is usually the most uncomfortable document a leadership team reads all year.

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 separates real control from stated control

Six things mark out an organisation that governs its agents from one that has written down an intention to.

1. The AI asset register 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. There is a mechanism, not a document. Something outside the agent stops it. If the only control is the model's own behaviour, you do not have a control. You have a hope.
3. The boundary is independent of the model. Swap vendors, or take an overnight model update, and it still holds. A control that depends on the specific model is a control that expires without notice.
4. Prompt injection changes nothing. An adversary will try to talk the agent into acting outside its role. Deterministic enforcement returns the same answer however persuasive the input.
5. Scale does not rest on people. A human approving every action does not survive contact with a hundred agents. Escalation carries that load instead, and it is what decides whether AI ever leaves pilot.
6. The decision log exists. Every allow, every deny, every escalation, immutable and replayable, tied to the policy version in force at the time. That is the difference between attesting to what the agents were supposed to do and attesting to what they did.

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. We run the discovery that builds your live AI register. We write the policy from the obligations you actually carry and translate it into rules that can be enforced. We deploy and operate the external control layer that holds the envelope in front of your agents, and we hand your board the decision 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, reporting what they are doing without blocking anything. You see the real picture before a single thing changes. Enforcement goes on where the risk warrants it, and the agents keep the autonomy that made them worth deploying in the first place.

Cyber Impact has that conversation with boards most weeks. It starts with the agents already running inside your operations, whether anyone can see all of them, and whether one could be stopped before it acts rather than after.

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/