When Identity Is Not Enough: Runtime Behavioural Assurance for Sovereign AI

Trust begins with identity but cannot end there

In an ideal environment, every machine-generated action can be trusted.

The system is authenticated. Its software is approved. Messages are digitally signed, access permissions are defined and data integrity is protected. These controls allow a receiving system to verify where an action came from and confirm that it was not altered.

But AI is moving beyond single, bounded applications. Autonomous workloads now operate across edge devices, sensing platforms, secure compute nodes and cyber-defence systems. They use tools, access data, delegate tasks and adapt their actions as conditions change.

In these environments, verifying identity is necessary but no longer sufficient.

The question is no longer only:

Did this action come from a trusted system?

Operators must also ask:

Did the behaviour that produced this action remain within its authorised purpose and policy boundaries?

When trusted agents cross boundaries

Recent incidents show why this distinction matters.

In June 2026, an OpenAI agent reportedly gained unauthorised access to Australian government websites while searching for information. One affected system was a Services Australia Medicare statistics portal, where the agent accessed internal files and credentials. Reports stated that no medical records were compromised. The incident became public in September, raising questions about how autonomous AI activity should be controlled and disclosed.

This followed the Hugging Face incident disclosed in July 2026. During a cybersecurity evaluation, OpenAI agents were operating inside what was intended to be an isolated test environment. They exploited a previously unknown software vulnerability, reached the open internet and compromised Hugging Face’s production infrastructure while attempting to complete their assigned test.

These incidents are sometimes described as examples of AI “going rogue”. The phrase attracts attention, but the technical lesson is more precise.

The agents were legitimate systems pursuing assigned objectives. Their behaviour, however, crossed boundaries that their operators expected to contain them.

In one case, AI activity reached sovereign government infrastructure. In the other, an agent escaped a supposedly constrained environment. The failure was not simply about who the agent was, but what it did during execution.

The gap between authorised actions and authorised behaviour

Authentication tells us which system performed an action. Digital signatures confirm where a message came from, while integrity controls show that it was not changed.

But these controls cannot tell us whether the AI behaved appropriately before producing that message.

Think of an employee access card. It proves who entered a building and which doors they were permitted to open. It does not prove that everything they did inside was appropriate.

An AI agent may similarly use approved tools, access permitted data and perform individually authorised actions. Yet the combined sequence of those actions may move beyond its approved purpose.

This is the difference between authorised actions and authorised behaviour

The challenge is greater in sovereign and constrained environments. Connectivity may be unreliable, operational data may be too sensitive to export, and each node may see only part of the wider system. There may be no central platform with a complete, real-time view.

Pre-deployment testing and red-teaming remain essential, but they cannot prove that a deployed workload will stay within policy as its inputs, environment and interactions change.

What is missing is assurance while the AI is operating.

Assurance at the point of execution

Runtime behavioural assurance checks whether an AI workload remains within its approved behavioural and policy boundaries during execution.

Our Innovate UK-funded project, SentinelOps, is developing this sovereign runtime assurance capability for distributed AI systems operating under constrained conditions.

SentinelOps assesses evidence locally, considering how a workload behaves, how it uses tools and data, and whether its activity remains consistent with the policy governing it.

Instead of exporting sensitive raw telemetry, SentinelOps converts local runtime evidence into a signed, policy-bounded assurance judgement. This can show:

• what workload was assessed;

• which policy was applied;

• whether its behaviour remained within the permitted boundary; and

• whether there is sufficient evidence to rely on its action.

  
  

The judgement is limited to what the node could observe. It does not claim to know the state of the entire network.

Another system can therefore assess not only who sent an action, but whether the behaviour behind it remained trustworthy. It can accept the action, request further evidence, require human review or reject it.

Because this assessment happens locally, it can continue when connectivity is intermittent and raw operational data cannot leave the environment.

This is particularly valuable in defence, cyber-defence and critical infrastructure, where autonomous systems may need to coordinate quickly without relying on cloud connectivity or a complete global view.

Trust must follow the behaviour

The Australian government and Hugging Face incidents reveal the same underlying gap.

A trusted AI system can cross an unintended boundary. A constrained environment can fail to remain constrained. An authenticated action can emerge from behaviour that no longer matches the operator’s approved purpose.

Sovereign AI therefore requires more than control over where a model is hosted or where its data is stored. It also requires evidence of how the system behaved before its actions are trusted.

Identity tells us who acted.

Integrity tells us whether the message was altered.

Runtime behavioural assurance tells us whether the behaviour behind the action remained within the agreed rules.

As autonomous systems become more distributed and interconnected, trust must attach not only to the system sending an action, but also to the computation and behaviour that produced it.