The control plane: the missing layer in AI security and governance

AI Security & Governance has rapidly become a complex problem.

Frontier AI capability is so rapidly evolving that even AI leaders themselves are openly advocating for slowing down the pace of AI development to ensure the technology gets built in the right way. Simultaneously, the way such technolgy is integrated into the economy requires ensuring adoption doesn’t outpace governance for sustainable value creation.

Identity, data loss prevention, cloud guardrails, SaaS administration and model gateways each protect a boundary. However, none of those components gives the board an overview of where AI is being used, who owns it, what data it can access, what it costs, or whether the associated risk is within appetite.

For example, an employee might use an AI assistant within a productivity suite, while a customer service team uses a separate chatbot and an engineering team experiments with an AI coding tool. Each platform may have its own security settings and reports, but leadership may not have a single, reliable view showing these AI use cases, who is accountable for them, and what information they can access.

That is the gap an AI control plane is intended to close. However, a control plane is not another product to buy, but rather an assembled enterprise capability that connects the AI estate, governance, native controls, telemetry and evidence into a common operating view.

The regulatory floor has moved

For Australian executives, this is not a future-state governance exercise. Existing obligations already create a clear expectation that material technology and operational risks are identified, managed and evidenced. Supervising entities such as APRA and ASIC are now regularly communicating to their regulated organisations to take action.

The regulation isn’t new; AI has just shifted the game for it. For instance, CPS 230 does not designate AI itself as a critical operation. Instead, it requires entities to manage their full range of operational risks, including technology, data and service-provider risk, and to maintain critical operations within approved tolerance levels. Where AI systems, models, or providers support a critical operation or pose material risk, they need to be visible within that operational risk and resilience framework.

In practical terms, if an AI system helps assess loan applications, answers customer questions during a service outage, or prepares information used in a regulated process, the organisation needs to know who owns it, what could go wrong, what fallback exists, and how performance is monitored. The fact that the system is labelled “AI” does not change the need to manage the underlying operational risk.

ASIC Report 798 reached a similar conclusion for financial-services and credit licensees. Its review of 23 licensees found that AI adoption was accelerating while governance and risk-management arrangements did not always keep pace. The message is not that ASIC created a standalone AI law. It is that existing, technology-neutral obligations continue to apply, and governance needs to lead adoption rather than follow it.

Therefore, waiting for new AI laws before taking action is not a control strategy. Boards need enough visibility to demonstrate that AI risk is being managed now, under the obligations that already apply today.

This article focuses specifically on the control plane. For the wider regulatory picture across privacy, prudential, sector and assurance obligations, and the six dimensions that determine whether governance holds under scrutiny, see our executive guide, Building AI governance that bends without breaking.

Why more controls everywhere can still leave you blind

A hyperscaler foundation may provide strong control over the workloads it hosts, while seeing nothing that goes directly to SaaS or another provider. An AI gateway can enforce policy across model traffic, but only when traffic is routed through it. Network-edge tooling can observe prompts crossing the boundary, but may have no in-path enforcement or control over what comes back. Egress analysis can reveal shadow AI usage, but does not prevent it.

The challenge isn’t limited to control effectiveness; it’s also about observability across controls. Without an end-to-end view, risk can remain hidden between otherwise effective controls. 

Consider a simple example. A data-loss-prevention tool may stop an employee from uploading a customer file to one public AI website. It may not know that the same employee is pasting similar information into an approved CRM assistant, or that an internal agent can retrieve the same data through an API. The individual controls may be working as designed, while the underlying exposure persists elsewhere. For security leaders, the critical issue is not only whether a prompt is visible. It is the chain of authority around an AI system: which identity invoked it, what data it can reach, which tools or APIs it can call, what actions it can take, and whether those actions can be stopped and investigated.

An agent can create risk by combining individually legitimate permissions across systems. For example, an agent may be allowed to read a customer record in one system and create a case in another. Neither permission is inherently inappropriate, but together they may allow the agent to make a customer-impacting change without a human checking the result.

The risk therefore accumulates in the spaces between platforms. Gaps in coverage, ownership, telemetry and response stay hidden precisely because each platform can report itself as healthy.

This creates a broader governance challenge. Organisations need to understand not only whether individual controls are operating, but whether the overall AI exposure is understood, owned and within appetite. 

This is becoming harder as AI fragments across the estate. AI is now embedded in SaaS products, cloud services, internal applications, employee tools and low-code platforms. Adoption can outrun classification and ownership, leaving organisations with an uncomfortable choice: restrict experimentation broadly or allow unmanaged growth. Neither option is a sustainable strategy for any regulated organisation.

Assemble, don’t just buy

The market is increasingly positioning the AI control plane as a product category; as something an organisation can procure and install. That framing can be misleading. Controls are enforced inside platforms. Governance lives in processes, roles and decision rights. The control plane is the connective architecture that brings them together into a single enterprise view of AI usage, ownership, risk, performance and cost.

Buying another technology layer before answering those questions adds cost and complexity without necessarily closing the gap.

Enforcement should remain native wherever possible. Identity, data controls, model controls, agent permissions, application guardrails and monitoring work best where they already live. The control plane specifies the policy intent, connects the relevant control points and reads their evidence back into a common portfolio view.

Compliance, plus cost and value

Framing this work purely as risk management undersells its commercial value.

The same view that helps satisfy a regulator also answers questions that matter to technology and business leaders:

• Which use cases are actually being used, and by whom?
• Which experiments have become relied-upon business processes without a deliberate decision?
• Where is model or provider concentration building up?
• What is AI costing, and can that cost be attributed to the teams and products generating it?
• Where are teams duplicating effort or solving the same problem independently?
• Which low-risk assets can be reused safely across the organisation?

For example, two business units may each pay for separate AI summarisation tools even though one approved service could meet both needs. Conversely, a tool that began as a low-risk experiment may become important to daily operations without anyone formally deciding who supports it or what happens if the provider becomes unavailable.

AI spend is also moving from predictable licences to variable consumption. Without shared metering, allocation and cost controls, forecasting becomes difficult and accountability becomes unclear.

Visibility is therefore not separate from value. If an organisation cannot see where AI is running, who owns it, what it costs, which data and tools it can access, and whether it is delivering the intended outcome, it cannot make informed decisions about where to scale, consolidate, constrain or invest. 

What leaders should ask now

The question is not which AI governance product to buy. It is whether the organisation can currently see its AI estate well enough to know what it needs.

Management should be able to answer, with evidence:

• Do we have a reliable inventory of AI systems, embedded capabilities, agents and providers?
• Can we identify the accountable owner, business purpose, data access, model dependencies and tool permissions for material use cases?
• Do our policies reach the places where AI is actually being used?
• Can we demonstrate that controls are operating, not merely documented?
• Can we intervene quickly when an AI system behaves outside its approved purpose or risk appetite?

A useful test is to select one material AI use case and trace it from end to end. Can the organisation explain who requested it, who approved it, what information it can access, which model processes the information, what actions it can take, what is logged, how a human can intervene, and what happens if the service is unavailable? If those answers require several disconnected conversations and spreadsheets, the control-plane gap is already visible.

Closing that gap is an architecture and assessment problem before it is a procurement problem.

Get the view first

The decisions about what to build, buy or leave alone become much easier once leadership can see what is actually there. For organisations assessing where to start, an AI Control Plane diagnostic can provide an enterprise view of AI exposure, a control-gap assessment and a prioritised roadmap for action.