ISO/IEC 27090: putting AI security guidance into operation

The standard has arrived

On 14 October 2026, ISO and IEC published ISO/IEC 27090:2026, Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. The project was approved in September 2022 by ISO/IEC JTC 1/SC 27, the subcommittee responsible for ISO/IEC 27001 and ISO/IEC 27002. Four years later, the first edition is an international standard dedicated to the security threats that are specific to AI systems.

Its scope is deliberately broad. The document applies to organisations of every type and size that develop or use AI systems, across the whole AI life cycle. It catalogues the compromises that distinguish AI from conventional software — data poisoning, evasion, membership inference, model exfiltration and inversion, direct model poisoning, sensitive model output, prompt injection and injected output — and for each one describes the failures that follow, how the compromise can be detected and how it can be mitigated.

It is explicit about where it sits. Conventional information security controls, as described in ISO/IEC 27002, continue to apply; the standard adds the AI-specific threats they do not cover. Its governance clause points to ISO/IEC 42001 for the management system and to ISO/IEC 23894 for AI risk management. ISO/IEC 27090 is not a certification in its own right. It is a useful new reference an auditor, a regulator or a board may cite when an organisation is asked how its ISO/IEC 27001 or ISO/IEC 42001 programme addresses the threats that are particular to AI.

Across 2026, national cyber agencies have published guidance on agentic AI with a consistent message: least privilege, monitoring, human oversight and restrictions enforced outside the model. That argument is made in The Layer Above Every Harness, and in TomorrowX’s own piece from NVIDIA GTC Berlin this week, Unlocking AI at scale: Give Risk and Cyber the power to say yes ↗. ISO/IEC 27090 gives that guidance an international standard behind it.

What the standard asks of the organisation that uses AI

Much of ISO/IEC 27090 addresses those who build models: the integrity of training data, the protection of model parameters, the supply chain of pre-trained models and development tooling. But a substantial part of it is written for the operation stage — the stage at which an enterprise or public-sector agency connects models it did not train to data and systems it is accountable for. Those clauses are especially relevant to organisations deploying models they did not build.

Zero trust, applied to the AI life cycle. The standard carries the zero trust principles of ISO/IEC 27002 into AI and makes them concrete. Each inference request is to be authenticated and authorised for the specific model capability being used, whether it arrives through an API call, an application integration or a retrieval-augmented generation system. Strict isolation is to be enforced between AI applications and their data sources. For agents that can trigger actions, each action is to be verified and authorised independently, with just-in-time access that expires when the task completes. Behavioural monitoring is to establish baselines for query patterns, response characteristics and resource use, so that deviation signals compromise even when authentication appears valid. And prompt boundary enforcement is to validate and sanitise inputs before they reach the model, regardless of authentication status or apparent source.

Governing unwanted behaviour in operation. Clause 6.11.3 sets out how the effects of unwanted model behaviour are to be controlled and governed once a system is live. Oversight may be human or may be “business logic in the form of rules or guardrails” able to detect unwanted behaviour and correct or halt the execution of a decision. Least privilege is to be applied not to the model but to the agents, services and applications that use it: privileges task-specific, time-bound and contextually appropriate. The standard then states the pattern directly — “API-integrated agents should use mediated access with pre-execution verification” — and calls for verifiable agent identities, dynamic authorisation, monitoring with robust audit trails and graduated intervention that restricts privileges when anomalous behaviour is detected.

Limiting the data. Impact is reduced by limiting the data attack surface: minimisation, minimal retention, encryption and obfuscation, including masking and tokenisation, and the minimisation of technical details that would help an attacker.

Treating output as untrusted. Model output may contain sensitive data from training or earlier input, and may contain conventional injection payloads. The standard asks that output be filtered where sensitive data can be recognised by structure or content, and that textual output be regarded as untrusted whenever its training data could be.

Recording everything that would be needed to reconstruct an incident. Clause 7.5 asks that the use of a model be logged and monitored “so that incidents can be reconstructed”, and recommends recording the input, the date and time, the user identifier, the output and the version of the model. Clause 6.11.4 adds provenance: the history of AI assets including, where applicable, user prompts; immutable logs covering versions, deployments and security events; provenance metadata protected by cryptographic means; and records retained for audit, compliance assessment and post-incident review.

Bounding consumption. Throttling model use is described as a mitigation in its own right, intended to hinder the experimentation behind extraction, inversion and evasion rather than merely to prevent overload. For AI-specific denial of service, the standard notes that queries which overflow a time or energy budget can, in some circumstances, be aborted.

Finally, the standard is candid about the limits of controls that live inside the model. Mitigations that involve training can interfere with one another and deteriorate over time. Prompt validation by blocklist is of limited effectiveness. Open text prompts and outputs are, in its words, “difficult to monitor and control”, and for generative AI hosted in cloud environments the attack surface is changed and, in its words, “challenges can arise for visibility and control performance”. The standard asks for continuity of mitigation across the life cycle, with input and output filtering during inference as one of the stages at which it should hold.

One AI system is never the whole estate

The standard describes controls for an AI system. The enterprise must evidence them across every AI system it uses, and it did not build most of them.

A copilot arrives with the office suite. A coding agent arrives with the development toolchain. Models are consumed from several providers through several applications. Agent capabilities appear inside SaaS products already under licence. Each of these is an AI system in the standard’s terms. Each applies some of the standard’s controls inside itself, on its own terms, and reports on them through its own attestation.

That leaves the compliance programme with a familiar problem. Policy is re-implemented per product, so it is inconsistent. Evidence is kept per product, in each product’s format, so it is fragmented. And the layer being governed is the layer producing the assurance, so verification is circular — the point made in The Layer Above Every Harness about harnesses applies equally to the standard’s AI systems. The questions Risk and Cyber ask — where is the data going, what can the agent access, can we independently observe, restrict or stop it — cannot be answered by collecting vendor statements.

Mediated access, verified before execution

The architecture established across this path answers that requirement, and the standard describes the same pattern. The enterprise places a Programmable Data Agent in the data path between its AI applications and agents on one side and the models, data sources and systems they reach on the other. The PDA terminates each interaction at the protocol level, evaluates it against enterprise policy while it is in flight, and re-originates only what is permitted — without changing the applications on one side or the models and systems on the other.

This is Data Mediation™, and in the AI Data Guard solution it is applied to the AI boundary specifically: classify what is crossing, apply masking, minimisation, routing and access policy in motion, inspect responses, and allow, adjust, quarantine or deny before anything creates impact. The standard’s phrase for the pattern — mediated access with pre-execution verification — describes it closely. Because the enforcement point is independent of the models and applications it mediates, it is uniform: one policy and one evidence trail across the mediated estate. Because it operates at the protocol level, it works with AI systems it has never seen before. And because it runs inside an environment the customer governs, the evidence belongs to the enterprise.

The standard’s controls, enforced in the data path

Each of the operation-stage practices ISO/IEC 27090 describes has a concrete expression at an independent enforcement point in the data path. The clause references are to the standard.

What remains inside the model and the application

ISO/IEC 27090 spans the whole life cycle, and a control plane in the data path does not address all of it. The integrity of training data, the provenance and signing of models and datasets, adversarial training, differential privacy and the protection of the development environment belong to whoever builds and trains the model. Tool permissions, sandboxing and approval gates inside an agent belong to the agent. Human oversight remains a human and organisational control, which the data path can route to and evidence but does not replace.

What the data path addresses is the operation-stage subset: the controls the standard asks of every organisation that uses AI, and the subset most directly within reach of an organisation that does not train its own models. The standard calls for defence in depth and for mitigations that hold at every stage of the life cycle. An independent enforcement point at the point of interaction is the stage that the enterprise owns.

Shared responsibility: what the data path covers, and what it does not

The standard helps frame the risks. Implementing the controls remains the organisation’s job, across several layers. The questions below are the ones Risk and Cyber teams ask; each answer names where Data Mediation may help and what still needs other controls.

ISO/IEC 27090 is not a stand-alone certification of TomorrowX or of a customer deployment. Other frameworks, including ISO/IEC 27001, ISO/IEC 42001 and ISO/IEC 23894, serve different purposes, and the standard is best read alongside them.

Giving Risk and Cyber the power to say yes

The TomorrowX piece published this week describes a different conversation inside the enterprise: Risk defines the boundaries, Cyber enforces them through independent technical controls, and the innovation team builds within them. ISO/IEC 27090 supplies the vocabulary for the first two roles. Risk can express its boundaries in the standard’s terms — which data may cross, which actions are acceptable, what must be recorded, what must be bounded. Cyber can enforce them at a point it operates, observes and tests itself.

The compliance consequence follows. Asked how the organisation addresses ISO/IEC 27090, the answer is no longer a folder of vendor attestations, one per product and none verifiable by the others. It is a record: what each AI system was permitted to reach, what was masked before it left, what was withheld on the way back, what was halted and why, and what it cost — produced at a single point, in a single format, across the mediated models and applications, by a layer that none of them can reconfigure.

The principles are the ones financial institutions have applied for decades: separation of duties, least privilege, independent assurance and protected audit trails. The system performing an action should not be the system deciding what gets recorded. The standard makes the same point for AI.

Conclusion

This path began with the observation that the AI era requires one governable control surface across agents, cloud, heritage systems and operational technology. ISO/IEC 27090 describes, clause by clause, what that surface should enforce and record for AI. Its operation-stage controls are not new to readers of this series. What is new is that an international standard now describes them.

The standard helps frame the risks. Organisations still need to implement the controls. Data Mediation contributes where the enterprise can govern an interaction in the data path, without rebuilding the systems on either side. Its value is the ability to apply customer-defined policy and retain operational evidence at those points — alongside the model, harness, application, identity, network and governance controls that remain essential.

Intelligence belongs to the model. Authority belongs to the enterprise. Enforcement must be independent — and, as this series has argued from the beginning, the control plane must be yours.