What is ISO/IEC 27090:2026?

ISO/IEC 27090:2026 is an international standard addressing security threats and compromises specific to AI systems. IEC's public summary says it helps organizations understand the consequences of AI-specific security threats throughout the AI system life cycle and describes ways to detect and mitigate them. IEC published the first edition on 14 October 2026.

Does ISO 27090 publish a free control checklist?

The public IEC and ISO catalog records provide the standard's title, publication facts and broad scope. A clause-level checklist or threat catalogue requires the licensed standard and its exact terms. Any local threat register, field list or test pattern should be labelled as an implementation artifact and mapped back to that licensed copy.

Which AI threats can an LLM gateway detect?

A gateway can detect signals visible in deliberately routed HTTP prompts and responses, plus identity and route context supplied by the application. Examples include restricted data sent to an unapproved model, a caller using a route outside its assigned policy and response content matching a protected class. Detection quality depends on the supplied context, classification method, rule and retained evidence.

Which ISO 27090 threats sit outside an LLM gateway?

Training-data compromise, model-weight theft and local code execution sit outside an authenticated LLM HTTP proxy when their attack paths bypass that traffic. Data pipeline controls own training integrity. Model weights belong with registry, storage, IAM and host controls, while endpoint and workload security cover local processes, plugins, shells, containers and STDIO tools. The threat record should name those owners rather than assigning universal coverage to the gateway.

How should a team test detection and mitigation?

Create versioned fixtures for the approved event and representative prohibited events. Define the expected detection and mitigation before the run. Execute each fixture through the real control point, then retain the event ID, rule or policy version, actual action, timestamp and reviewer. Re-run the set after a model route, identity mapping, classifier or policy changes. Add a failed-control exercise so the team can verify escalation and recovery.

ISO/IEC 27090: Build an AI Threat Detection and Mitigation Record

ISO/IEC 27090:2026 gives security teams a standard focused on threats and compromises specific to AI systems. The public record sets the subject and life-cycle scope. Operational work still needs a threat record that connects an observable event to detection logic, a mitigation decision, an owner and evidence.

I would reject a map that assigns every AI threat to an LLM gateway. A gateway sees one narrow surface: authenticated HTTP requests and responses deliberately routed through it. Training compromise, stolen model weights and code executing beside the model need different controls and different owners.

TL;DR

ISO/IEC 27090:2026 addresses AI-specific security threats, their consequences across the AI system life cycle, and approaches for detection and mitigation.
For each relevant threat, record the asset and attack path, observable signal, detection logic, mitigation action, owner, test and retained evidence.
An authenticated LLM HTTP gateway can inspect and enforce policy on routed prompts, responses, caller context, model destinations and request outcomes.
Training compromise, model-weight theft and local execution sit outside that proxy boundary and belong with data, model, endpoint and runtime security owners.

The ISO 27090 public scope

The official IEC publication page for ISO/IEC 27090:2026 describes a standard for security threats and compromises specific to AI systems. Its stated aim is to help organizations understand the consequences of those threats throughout the AI system life cycle, with descriptions of detection and mitigation. The page says the standard applies to organizations of every type and size that develop or use AI systems, including public and private companies, government bodies and not-for-profit organizations.

IEC lists publication on 14 October 2026, edition 1.0, under ISO/IEC JTC 1/SC 27. The official ISO Online Browsing Platform record identifies the same first edition, while the IEC catalog search for 27090 provides the publication discovery route.

Those public pages support the title, date, edition and broad scope. Claims about clause numbers, mandatory fields or a hidden threat catalogue would exceed the visible record. The operating record below is an editorial implementation pattern. Teams should align its labels with their licensed copy.

A threat record connects detection to mitigation

Start with one AI system and one credible attack path. Name the affected asset, the point where the threat can be observed, and the team that can change the relevant control. The ISO/IEC 23894 controls mapping is the nearest governance owner for the broader chain from risk scenario to selected treatment, accountable owner, test evidence and residual-risk decision. ISO 27090 adds a tighter security question: what compromise are you trying to detect, and what mitigation runs when the signal fires?

A working record can use these fields:

Threat ID and scenario: Describe the actor or failure condition, entry point, action and affected AI asset.
Life-cycle stage: Identify the development, deployment, operation or retirement activity where the exposure exists, using the exact terminology adopted from the licensed standard.
Observable signal: Name the log field, artifact, event or state change that detection logic can inspect.
Detection rule: Record the query, threshold, correlation or test case, including exclusions and the rule version.
Mitigation decision: Specify block, redact, isolate, revoke, roll back, quarantine, escalate or investigate, as applicable to that control point.
Owner and authority: Identify the team that operates the control and the person authorized to accept residual risk.
Evidence: Preserve the event, rule version, action, timestamp, reviewer and linked incident or change record.

Put the threat ID, request ID and policy version beside one another in an incident packet. A reviewer should be able to follow the detection and see the resulting action without opening six dashboards.

The HTTP request boundary defines gateway coverage

For DeepInspect, the relevant boundary is HTTP AI traffic between an authenticated user or agent and an LLM endpoint. The application deliberately routes the call through the proxy and supplies identity context. At that point, a gateway can inspect the prompt and response content allowed by policy. It can also evaluate the caller role, route, model destination, data classification and active policy.

This boundary supports detection and mitigation for threats expressed in that traffic. A prompt may carry an instruction intended to override application rules, or a user may send a restricted data class to an unapproved model. Agents can call a model route outside their delegated scope. Protected fields and system instructions may also appear in a response. These are implementation examples, rather than a claim about the standard's licensed threat taxonomy.

The prompt injection monitoring guide covers the difference between spotting suspicious prompt patterns and proving a control acted. ISO 27090 implementation should preserve that distinction. A detector raises a signal for review, while proof of enforcement comes from an explicit policy action and its retained decision record.

Detection for routed LLM traffic

Detection starts with fields that survive the event. For an authenticated HTTP LLM call, record the application-supplied identity and role, route and model destination, request and response classifications, policy version, matched rule, decision, enforcement action and timestamp. Retain content only under the organization's evidence and data-minimization policy. A full prompt copied into every alert can create a second sensitive-data store.

Test the detector with versioned fixtures. One fixture can send an approved support case to the approved model. A second can place a restricted customer field in the same route. A third can use an authenticated test role that lacks permission for that destination. Add expected permit, redact, deny or escalation outcomes before running the test. Preserve the actual event IDs and compare them with the expected decisions.

The record needs failure handling as well. Missing identity, an unavailable classifier or an unknown model route should reach a declared policy outcome. Security and the route owner must approve that outcome. A green detector dashboard says very little if the production path permits the request whenever context disappears.

Mitigation belongs at the control point

Each ISO 27090 threat record should assign mitigation where the organization can change the outcome. At the HTTP request boundary, inline actions can deny a prohibited route, redact a detected data class, require an approved model destination or escalate an ambiguous request before forwarding. Response policy can withhold protected content before it reaches the authenticated caller. Rate and route controls can constrain an agent that suddenly departs from its approved call pattern.

Other mitigations happen elsewhere. A model evaluation team tests behavior against adversarial inputs. IAM owners revoke credentials and correct role assignments. Endpoint security isolates a compromised workstation. A model registry can quarantine an unapproved artifact. Data engineering restores a trusted training dataset. Incident response coordinates the investigation and recovery sequence.

The control point should appear in the threat record. So should the rollback path and the person who can authorize it. This prevents a familiar audit failure: the mitigation says "block" while the named product only produces an alert after the model has answered.

Training, model weights and local execution need separate owners

Training-data compromise sits with the systems that ingest, approve, transform and version data. Detection may depend on source provenance, dataset hashes, lineage checks, distribution changes, review results and pipeline events. Mitigation can quarantine a source, restore a trusted version and retrain or re-evaluate the affected model. A proxy inspecting production HTTP calls might observe odd outputs later. Training-pipeline evidence is what establishes where the compromise occurred.

Model-weight theft belongs with model registry, storage, IAM, secrets, host and network controls. Relevant evidence may include artifact access logs, integrity checks, download events, key use and registry changes. A stolen weight file bypasses the HTTP request boundary.

Local execution also needs endpoint, workload and runtime security. Malicious code may run through a local tool, plugin, shell, notebook, container or STDIO-connected process without crossing the routed LLM HTTP boundary. EDR, sandboxing, workload isolation, tool permissions and process telemetry own that path. If the same workflow also makes an authenticated LLM HTTP call, the gateway controls that call only. Local security retains control over the process.

ISO 27090 and ISO 23894 should share identifiers

Use the same AI system ID, asset name and owner in the ISO 27090 threat record and the ISO 23894 risk record. Link the detected compromise to its treatment, test and residual-risk decision. The AI risk register template provides a practical place to retain that relationship.

Keep the security and risk artifacts distinct in the review packet. Use the threat record for the security scenario, observable signals, detection and mitigation. The organization's risk method evaluates impact and likelihood in the risk register, then tracks treatment and acceptance authority. An HTTP route denial may provide strong evidence that one treatment operated. Broader business impact and life-cycle coverage require their own decisions and evidence.

I prefer a narrow coverage statement that names three enforceable routes over a claim of complete AI security. The narrow statement survives incident review. It also shows the CISO exactly where another owner and evidence source are required.

DeepInspect

For the authenticated HTTP request and response slice, the application deliberately routes LLM traffic through DeepInspect and supplies caller identity. The stateless proxy can evaluate that context with the route, model destination, data classification and active policy before permitted traffic proceeds.

For each routed event, the enforcement point can record the policy version, decision, action, destination and timestamp under the organization's evidence policy. That supports detection tests and mitigation evidence for threats expressed in routed LLM traffic. Training pipelines, model-weight storage and local execution remain with their designated security owners.

Book a technical deep dive at deepinspect.ai.