ISO/IEC 27090:2026 gives security teams a new reference for assessing AI systems. It covers attacks on data, models and the software around them, and explicitly includes agent operations in its discussion of zero trust. For a company connecting agents to email, source code or production systems, the practical question is which requests those agents can make and who decides whether they may proceed.
The guidance can help structure a supplier review, a security assessment or a discussion with an auditor. It does not create a new certification badge. The work is to identify the relevant threats, test the controls and retain evidence of what those controls actually cover.
What was published
ISO/IEC 27090:2026 was published on October 14, 2026. The first edition has 56 pages and was developed by ISO/IEC JTC 1/SC 27. It addresses security threats specific to AI throughout its life cycle and applies to organizations of any size that develop or use AI, including companies, public bodies and nonprofits.
It complements the security practices already used under ISO/IEC 27001 and 27002. An exposed API, a stolen deployment credential or an unprotected development environment remains a problem when the application contains a model. AI introduces additional ways to compromise the system.
The OWASP AI Exchange reports contributing about 70 pages of material to the standard’s development.
Management, controls and AI threats
Manage information security risk.
Manage AI responsibilities and processes.
Organizations can seek certification of these management systems within a defined scope.
Select and implement information security controls.
Examine AI threats and choose relevant mitigations.
Guidance supports risk treatment. It is not a separate management-system certification.
What it covers
The publisher’s preview organizes the technical material into three parts. Clause 5 connects AI security with governance, zero trust, secure development, supply chain review, threat modelling and red teaming. Clause 6 examines forms of compromise. Clause 7 addresses mitigations, including their interaction, continuity and deterioration over time.
Its annexes map attacks to life-cycle stages and assets, discuss AI variants of conventional attacks and address federated learning. The table below summarizes the threat categories. The review questions are Oktsec’s application of them.
Swipe or scroll horizontally to compare all columns.
| Threat | What can go wrong | A useful review question |
|---|---|---|
| Data poisoning | Manipulated data changes learned behavior. | Who can change training data or feedback that later enters retraining? |
| Evasion | Crafted inputs cause incorrect decisions at inference. | Do evaluations include adversarial inputs relevant to the application? |
| Membership inference | Responses reveal whether a record was in the training set. | Could confirming inclusion expose private information? |
| Model exfiltration | Queries help an attacker approximate a model’s behavior. | Can monitoring identify systematic extraction through valid API access? |
| Model inversion | Outputs help reconstruct information about training data. | Which sensitive attributes could an attacker infer? |
| Direct model poisoning | An attacker modifies the model itself. | Who can replace model artifacts or change the deployment? |
| Sensitive output | Responses expose information that should remain private. | Can one user retrieve another user’s data or context? |
| Prompt injection | Untrusted instructions redirect the system. | Can a document or tool response change an agent’s intended task? |
| Injection in output | Generated content becomes an attack on a downstream consumer. | Is model output treated as untrusted before rendering or execution? |
Not every threat has the same relevance to every deployment. A company training a model on confidential records needs a different review from a company using a hosted assistant to update customer records. Document that difference rather than marking every row applicable.
For the first company, access to training data and model artifacts may be the immediate concern. For the second, tool permissions and the handling of external content may dominate. Both still need conventional application security.
How it fits with 27001, 27002 and 42001
ISO/IEC 27001 specifies requirements for an information security management system. ISO/IEC 27002 provides control guidance. ISO/IEC 42001 specifies requirements for an AI management system. Certification applies to 27001 and 42001 management systems within the certification scope, not to all three standards interchangeably.
27090 supplies technical context for AI security risk. An organization already using 27001 can incorporate relevant AI threats into its existing assessment and treatment process. An organization implementing 42001 can use that analysis to inform its AI security work. Neither exercise establishes that every deployed agent is secure.
The published bibliography also references ISO/IEC 23894, ETSI EN 304 223 and NIST’s Secure Software Development Framework. These are complementary references, not additional certifications automatically required by reading 27090.
For companies serving European customers, avoid turning a standards mapping into a claim of AI Act compliance. The European Commission explains that presumption of conformity depends on the relevant harmonised standards and their publication in the Official Journal, within the requirements they cover. An international ISO publication alone does not confer that status. The same caution applies to a European draft such as prEN 18282 before the applicable adoption and citation steps are complete.
What it means for AI agents
Clause 5.3 explicitly extends zero trust through to agent operations
. The published sample text discusses verifying requests, authentication, authorization and least privilege. The contents do not present a standalone agent-security chapter.
Applying that guidance to a deployed agent requires decisions about the application. An agent may use its own identity to call a tool, while the tool uses a shared service account to access a database. Checking the first identity does not establish that the second account has appropriate privileges.
Our implementation reading has four parts:
- Inventory the workflow. Record the agent’s owner, purpose, clients, tools, data sources and execution accounts. A list of model subscriptions will miss much of this.
- Authorize the requested action. Check the caller, operation, arguments, destination and relevant approval. An authenticated user can still request an unauthorized export.
- Limit the available authority. Restrict the resources, tools and credentials the workflow can use. Apply expiration where appropriate and test alternative access paths.
- Treat inputs and outputs as untrusted. A document can contain instructions aimed at the agent. A generated response can contain code or content that attacks the next application. Check both handoffs.
MCP servers, skills, plugins and hooks belong in this review because they introduce code, instructions or access. That is our application of the supply chain guidance. It is not a claim that the standard names each of those technologies or mandates a particular gateway.
A ticket cannot authorize a customer-data export
A message asks the assistant to send customer records to an external address.
The tool call identifies the dataset, destination and execution account.
Check identity, action, resource, account and destination against policy.
No transmission. Record the attempted action and reason.
Use the authorized account and retain the downstream result.
Policy version · actor · requested resource · decision · execution result, if any
What you still have to design
A general security standard cannot choose your payment limits, define who may approve a production deployment or decide how long an incident-response exception should last. Those rules depend on the workflow and the consequences of a mistake.
Do not limit the review to malicious prompts. A legitimate task can still cause harm when an agent uses an overly privileged account, changes the wrong resource or repeats an operation. Test ordinary mistakes, excessive permissions and insider misuse alongside deliberate attacks. The absence of an obvious attacker does not make an action authorized.
Logging also needs an explicit scope. A signed decision can show what an enforcement point decided. It does not, on its own, prove that the downstream application executed the action, that all requests passed through that point or that an export contains every record. Collect the execution result and check for missing events.
Finally, deterministic policy still needs maintenance. Given the same request, policy version and relevant state, a deterministic engine can produce a reproducible decision. That is useful for review. It does not mean the policy remains adequate as tools, models and attack techniques change. Counters, time limits and revocation state also affect decisions.
Where to start
Choose one workflow with access to sensitive information or a consequential action. Use it to establish a repeatable review before expanding across the organization.
- Build a usable inventory. Identify the business owner, model, runtime, tools, accounts and data. Include hosted services and locally configured clients. Record what you have not yet discovered.
- Review the surrounding stack. Check deployment credentials, exposed APIs, model storage, secrets and development environments. Restrict access to model artifacts before relying on defenses against query-based extraction.
- Select relevant threats. Explain which Clause 6 scenarios apply, what an attacker would need and what business outcome is at risk. Record why a threat is out of scope.
- Test authorization. Try a permitted operation and a prohibited variation. Change the resource, account or destination. Check that the restriction holds at execution, including fallback paths.
- Review dependencies and changes. Capture the source and version of models, datasets, packages, MCP servers and skills. Decide which changes need review before rollout.
- Run scoped adversarial tests. Exercise prompt injection, data exposure and tool misuse where relevant. Retain reproducible evidence, remediation owners and retest results.
- Repeat after meaningful changes. A model upgrade, new tool, broader credential or different data source can invalidate the original assessment. Define the events that trigger another review.
A startup can begin with one owner and a short record for each production workflow. A larger organization needs consistent records across teams, a process for exceptions and a way to identify systems outside the inventory. The useful measure is coverage of actual deployments, not the number of completed questionnaires.
Putting 27090 into practice with Oktsec
We use the standard as a reference for a scoped security review. The mapping below connects selected clause topics to implementation work and evidence. It is Oktsec’s analysis, not an ISO endorsement or a complete conformity assessment.
Discover the agents and their dependencies
Oktsec Control discovers supported local client configurations, including MCP servers and configured skills, hooks or subagents. It helps establish what is installed by user and machine. Configuration discovery is a starting point; it does not prove that every AI service or runtime in an organization has been found.
Signal, powered by the open source Aguara scanner, supports reviews of the components agents depend on. Findings help prioritize investigation. A scan result is not a guarantee that a component is trustworthy, and ongoing monitoring should be agreed against the integration coverage available for the environment.
Test the systems in use
Oktsec Assessment provides AI red teaming and pentesting under an agreed scope. Relevant exercises include prompt injection, data extraction, tool misuse and escalation paths. Findings include evidence and reproduction steps appropriate to the system and permitted testing. The report should also state what was not tested.
Apply policy before a routed action executes
Control applies deterministic checks at configured enforcement points. Depending on the integration and policy, those checks include agent identity, tool access, parameter restrictions and content findings. Decisions can allow, flag, quarantine or block. A flagged request still proceeds; a quarantine holds it for review.
Signing and enforcement must be configured and tested. The mere presence of an Ed25519 key does not ensure that unsigned requests are rejected. Likewise, an allowlist on one gateway does not restrict an agent’s separate shell, direct network access or credentials stored elsewhere. The deployment review needs to cover those paths.
Retain evidence and review its limits
With node signing configured, Control can provide signed decision evidence. Oktsec Cloud supports central policy oversight and evidence review across environments. Verification checks should cover the expected signer, included records and required lifecycle events. Protect signing keys and retain records outside the execution environment where appropriate.
These controls can support governance and audit work. They do not turn a partial inventory, an untested integration or an incomplete record into proof that all AI activity is controlled.
What a reviewer should be able to inspect
- 5.2 · GovernanceWhich systems are in scope?
- Owned inventory, intended use, data and execution accounts. Include discovery gaps.
- 5.5 · Supply chainWhat changed in a dependency?
- Source, version, review result and approval for the installed component.
- 5.7 · Red teamingWhat was tested?
- Agreed scope, test conditions, reproducible findings and remediation retests.
- 5.3 · Zero trustWhy was an action permitted?
- Authenticated actor, applicable policy and the resource, account and destination checked.
- 6.9–6.10 · InjectionWhat happened to malicious content?
- Test input, observed behavior, control decision and downstream effect.
- 7.5 · MonitoringCan the record be trusted?
- Integrity verification, signer identity, collection coverage and any missing events.
Training and the first review
Teams need to recognize the failure modes behind the terminology. A useful workshop follows an actual workflow: identify its accounts, introduce an untrusted instruction, observe the requested action and inspect the decision. Developers, security staff and governance owners should be able to explain the same result.
Oktsec offers talks and practical training for companies, public institutions and universities in Spanish and English. A session on 27090 can connect the guidance with the systems a team operates and the evidence it needs to retain.
For an assessment, start with the systems and business actions in scope. Agree which threats matter, what can be tested safely and what evidence the review should deliver. That produces a more useful result than a general claim of being “27090 ready.”
Sources and scope
Reviewed October 19, 2026. Publication details were checked against ISO and IEC. Clause references were checked against the publisher’s public contents and the published sample. The analysis uses these public materials; it is not a review of the complete paid standard. Examples, evidence suggestions and product mappings are Oktsec’s analysis.
- ISO: ISO/IEC 27090:2026. Scope, edition, committee and publication history.
- IEC: ISO/IEC 27090:2026 and public preview. Publication date, contents and bibliography.
- ISO/IEC 27090 sample distributed by iTeh. Public text of Clauses 5.2 and 5.3.
- OWASP AI Exchange: project and standards contributions.
- ISO: ISO/IEC 27001 and ISO: ISO/IEC 42001. Management-system scope and certification.
- European Commission: Understanding the standardisation of the AI Act.