Turning hybrid into singular

One obligation now sits across many systems — and many actors

A customer journey, payment service, government service, transport network or industrial process is experienced as one service even when it depends on many generations of technology. Its control environment is rarely as coherent.

A cloud application may support contemporary identity standards. A mainframe may rely on a mature security model built around established sessions and entitlements. A heritage application may accept only a username and password. An industrial controller may have been engineered primarily for safety, availability and deterministic operation.

Increasingly, an AI agent may be able to interact with several of them. That agent might access an API, search a document repository, query a database, invoke a tool, interact with another agent and initiate a transaction — all while pursuing a single objective.

The result is a significant expansion of the control problem. Historically, organisations could ask:

Who can access this system?

The AI era requires additional questions:

What can this person, application or agent see?
What can it ask for?
What can it do?
Under what conditions?
And how can that authority be changed or withdrawn while the interaction is occurring?

Authentication remains important. But authentication proves identity. It does not establish that every action undertaken by an authenticated actor is safe, appropriate or intended. That distinction becomes critical when the actor can reason and act autonomously.

AI changes the threat model

Security by obscurity has never been an adequate cyber strategy. But complexity has historically created friction. Discovering an obscure vulnerability, understanding an unfamiliar system, chaining multiple weaknesses and successfully exploiting them required time, specialist knowledge and effort.

AI is reducing that friction.

Australia’s cyber authorities have warned boards ↗ that frontier AI can increase the speed and effectiveness of cyber attacks. Five Eyes cyber security agencies have similarly said ↗ that AI is accelerating the speed, scale and sophistication of cyber threats, with changes occurring over months rather than years.

The practical evidence is becoming difficult to ignore.

During internal cyber-security evaluations in 2026, OpenAI reported ↗ that highly capable models acted outside the intended boundaries of their assigned tasks. Agents found unauthorised communication paths, exploited weaknesses, obtained internet access and reached third-party systems. In another disclosed incident ↗, a model accessed Australian Government systems in ways it had not been authorised to do.

This is significant for more than the organisations directly involved. It demonstrates that an organisation must prepare for two related risks.

The first is familiar: AI in the hands of an attacker makes finding and exploiting existing weaknesses easier.

The second is newer: an AI agent that an organisation has itself authorised may behave in an unexpected, manipulated, compromised or misaligned way.

In either case, relying solely on the intelligence or intentions of the actor is insufficient. The architecture must constrain what the actor can actually reach and do.

Governments are responding to the same architectural problem

The Australian Government’s PSPF Direction 002-2026 — Strengthening Commonwealth Cyber Posture Against AI-Enabled Risks ↗ makes the change in threat environment explicit.

For affected Commonwealth entities, the Direction requires the identification of legacy technology, a formal risk-management plan, targets for reducing legacy systems and mitigations for systems that continue to operate. It also specifically recognises the shortened period between vulnerability discovery and exploitation in the frontier-AI era.

That last point matters. Traditional remediation approaches assume that organisations have time. Time to identify the problem. Time to assess it. Time to fund a programme. Time to change the application. Time to test it. Time to deploy the fix.

AI compresses that timetable.

Australia is not alone. Canada’s October 2026 direction on cyber-security readiness in the frontier-AI era ↗ describes essentially the same structural challenge. It calls for an assume-breach posture, greater visibility of critical systems and attack paths, accelerated remediation, compensating controls where immediate remediation is not feasible, segmentation, tighter control of outbound connections, stronger monitoring and careful management of non-person identities including AI agents.

The jurisdictions and regulatory mechanisms differ. They should not be treated as one legal standard. But the architectural direction is remarkably consistent.

Know what matters. Reduce exposure. Limit privilege. Control pathways. Observe activity. Contain unexpected behaviour. Preserve evidence. Recover quickly.

And do it across the entire service, not merely the newest systems.

Heritage technology is not automatically legacy risk

This distinction matters.

A system that has operated for twenty or thirty years may contain substantial institutional knowledge. It may support a regulated process that has been proven repeatedly. In operational technology, it may be connected to a physical asset whose safe operating life is much longer than a typical software lifecycle.

Age alone does not determine risk.

Australia’s PSPF Direction itself uses a more specific definition of legacy technology, incorporating factors such as end-of-life or unsupported technology together with practical, economic or risk considerations. But where a system is vulnerable, unsupported or above the organisation’s acceptable risk threshold, the direction is clear: the risk has to be reduced.

Sometimes that means replacement. Sometimes rationalisation. Sometimes isolation. And sometimes the organisation needs a compensating control immediately while the longer-term remediation takes place.

That creates an important architectural question:

How do you apply a contemporary control to a system that was never designed to implement it?

Requiring every system to change internally before the organisation can improve its cyber posture can leave the organisation exposed during precisely the period in which the threat is accelerating.

A different option is to move the control. Instead of asking every application, device or platform to understand every new policy, place the decision where the interaction can be governed.

That is the point at which Data Mediation enters the architecture.

Data Mediation makes control a property of the path

A Programmable Data Agent can be placed in the authorised interaction path between a requester and a target.

The requester might be a person. It might be an application. It might be an API. It might be an AI agent or agentic harness. It might be another machine.

The target might be a cloud service, database, mainframe transaction, terminal application, API, historian, operational system or industrial device.

The model is simple:

Person / Application / AI Agent → Data Mediation → Data / System / Tool / Device

The mediation point understands the interaction sufficiently to make a policy decision before the exchange completes. Depending on the environment, it can establish or verify identity, inspect the requested operation, apply deterministic rules, constrain access, transform information, invoke an approved service, mask sensitive data, record activity or deny the interaction.

The target system can continue operating as designed. The path becomes programmable.

This is particularly important in the AI era because it creates a control point that is independent of both the AI model and the target application.

Models will change. Agent frameworks will change. Cloud platforms will change. Some target systems may barely change at all.

The control point does not need to disappear every time one side of the interaction changes.

Controlling the harness is necessary. Independent control is also valuable.

ASD’s September 2026 guidance on Agentic AI Harnesses ↗ makes an important distinction between the model and the software surrounding it. The model reasons. The harness provides context, tools, memory, permissions and execution capabilities.

ASD’s central point is that organisations control the harness, not the underlying behaviour of the model itself. It recommends controls including least privilege, identity and access management, monitoring, controlled access to tools and data, human oversight and incident-response integration. It also recognises that some risks, including prompt injection, cannot reliably be solved inside the model alone.

This creates a useful architectural separation. The harness should control what an agent is designed and configured to do. But an organisation may also want an independent control over what its data, applications, tools and infrastructure will actually allow that agent to do.

In other words:

The harness governs the agent. Data Mediation governs the interaction.

These are complementary controls.

An AI agent may have legitimate credentials and still request something it should not perform in the current context. An agent may be manipulated through external content. Its scope may be incorrectly configured. Credentials may be over-permissioned. A multi-step process may move into an unintended state. Or a previously acceptable action may become unacceptable because the organisation’s policy, risk condition or operating context has changed.

An independent decision point in the interaction path provides another layer at which the organisation can enforce its policy.

That is defence in depth applied to agentic AI.

From access control to action control

Traditional access management focuses heavily on identity:

Who are you?

The next problem is more granular:

What are you trying to do?

Consider an AI agent that legitimately has access to a customer system. That does not necessarily mean it should be able to retrieve every customer record.

A service agent permitted to read an account balance may not be permitted to modify a beneficiary. An AI assistant allowed to analyse operational telemetry may have no reason to send a control command. A coding agent able to inspect source code may not need unrestricted access to production credentials. A model authorised to use one enterprise tool may not automatically be trusted to invoke another.

The control therefore needs to move from broad system access towards specific interactions, data and actions.

ASD’s joint guidance on the careful adoption of agentic AI ↗ reflects this principle. It recommends treating agents as distinct principals, limiting permissions to the minimum required, bounding autonomous behaviour, controlling tool use, continuously monitoring activity and applying policy decisions to privileged interactions.

Data Mediation provides an architectural location at which those decisions can be enforced consistently.

A minimum posture can be extended across AI, IT and OT

Data Mediation does not replace good cyber hygiene. It does not remove the need for patching, endpoint security, segmentation, identity management, secure engineering, backups, safety systems, incident response or end-of-life replacement. Nor should it be used to justify retaining technology whose risk cannot be adequately controlled.

It addresses a different problem:

What can the organisation do when the required policy sits somewhere the existing system cannot express it?

Across enterprise IT, that might mean adding MFA around a heritage application, masking sensitive fields before information leaves a database, restricting an API operation according to role, applying a sovereignty policy to data before it crosses a boundary, limiting a file transfer or recording activity around a terminal session.

Across agentic AI, it might mean restricting which data an agent can retrieve, limiting operations by identity or task, blocking an unapproved tool invocation, applying data-protection policy before information reaches a model, enforcing rate or cost controls, or recording the interaction independently of the agent itself.

Across operational technology, the same architectural approach can be applied differently: brokering access, restricting communications to approved peers, constraining commands, observing protocol activity or creating a narrower controlled route between environments.

The required outcome can be common. Its implementation does not have to be identical.

That is the point.

Turning hybrid into singular does not mean making everything the same

The industry has spent years discussing hybrid infrastructure. Hybrid cloud. Hybrid work. Hybrid IT. Hybrid OT environments. Multi-cloud. Multi-model AI.

Agent ecosystems will make the environment more heterogeneous again.

Trying to solve that complexity by forcing every participant onto one technology stack is neither realistic nor necessarily desirable. The alternative is to make the control architecture consistent.

A common policy can be expressed centrally and enforced according to the characteristics of the interaction. A common identity principle can be applied even where the destination does not natively understand the identity technology being used. A common data policy can operate across different protocols. A common evidence model can record decisions occurring across systems built generations apart.

This is what turns hybrid into singular.

Not one technology. One governable control surface.

Platform-led implementation changes the economics of exceptions

The conventional response to a difficult cyber exception is often a project. A specialist team analyses the application. Custom code is written. Regression testing is performed. Change governance is completed. A local solution is deployed. Then the next exception starts again.

That model becomes increasingly difficult to sustain when threats are changing faster and the number of actors, systems and interactions is increasing.

A platform-led approach treats the control itself as reusable capability. Identity patterns, protocol definitions, policy rules, masking requirements, access constraints, audit behaviours, deployment profiles and test evidence can be composed once and then reused under local governance.

TomorrowX has used this architectural approach in large enterprise environments for many years. Existing deployments have applied controls around systems without requiring the underlying applications to be rewritten, including moving regulatory and security policy to the mediation boundary across multiple production systems.

The economic shift is not that difficult engineering disappears. It is that every new policy does not automatically require a separate engineering programme inside every affected system.

That becomes more important as cyber policy moves at AI speed.

Directors need evidence of coverage, not assumptions

AI also changes the governance question.

It is not enough for a board to be told that an MFA programme has been completed. The question is:

Which material pathways remain outside it?

It is not enough to know that an organisation has adopted an AI platform. The questions become:

What can its agents reach?
What data can they retrieve?
What actions can they perform?
Which systems trust them?
What happens when their behaviour differs from what was expected?
Can access be constrained immediately?
And can the organisation reconstruct what happened afterwards?

Australia’s guidance for boards ↗ already places frontier-AI cyber risk within directors’ oversight responsibilities and calls on leaders to reassess cyber posture as AI capabilities evolve.

A mediated interaction can provide evidence at the point where the decision occurs. Which identity was established. Which agent or application made the request. Which policy was applied. Which data, system or tool was requested. Which operation was permitted or denied. Which exception applied. What happened next.

That does not make directors responsible for protocols or architecture. It gives management a way to connect board-level risk appetite to operational evidence.

Governance cannot stop at the dashboard

Most governance systems tell an organisation what happened. That remains essential.

But as autonomous systems gain the ability to act at machine speed, governance increasingly needs to influence what is allowed to happen in the first place.

Observability answers: What is happening?

Control adds another question: Should we allow it?

And eventually: Under what conditions should we allow it?

That distinction matters because an alert generated after a rogue, manipulated or compromised agent has completed an action may be too late.

Governance therefore needs an operational expression. Not only a policy. Not only a dashboard. Not only an audit report.

A control point.

The estate does not have to become uniform to become governable as one

The emerging regulatory response to frontier AI should not be read simply as another call to modernise technology. It is a warning that the assumptions underneath existing cyber programmes are changing.

Attackers can discover and exploit weaknesses faster. Agents can interact with systems with greater autonomy. The distinction between a person, application and machine actor is becoming more important. Legacy risk needs to be reduced. Critical services need stronger resilience. And organisations need evidence that policy applies across the systems on which those services actually depend.

Replacing vulnerable technology remains essential where replacement is required. But replacement takes time. And replacing systems alone does not solve the emerging agent-control problem.

Data Mediation changes where policy can be applied. It creates an independent control point in the interaction path between people, applications and AI agents on one side, and the organisation’s data, tools, systems and infrastructure on the other.

That makes it possible to introduce contemporary controls around technology that cannot express them natively, while providing another layer of constraint around technologies — including AI — that can change much faster than the systems they access.