Agent Security › Standards
How OWASP, NIST and ISO guidance applies to AI agents. There isn't one agent security standard, so here is how the main pieces relate, and where our own framework extends beyond them to outcome verification.
AI agents are moving from systems that answer questions to systems that can take action. They can read business data, use software tools, call APIs, send messages, change records, write and deploy code, spend money, work with other agents, and operate without somebody watching every step. That changes the security problem.
Traditional cybersecurity still matters. But organisations deploying AI agents also need to think about identity, authority, permissions, human oversight, tool use, prompt injection, monitoring, observability, containment, and whether the work an agent claims to have completed actually happened. There is no single standard that answers every one of those questions. Instead, several important standards, frameworks and initiatives are beginning to address different parts of the problem. This guide explains where some of the most important work from OWASP, NIST and ISO fits, how the pieces relate, and where organisations still need to make practical decisions of their own.
You may see references to OWASP, NIST, ISO/IEC 42001, ISO/IEC 23894, ISO/IEC TS 8200, the Agent Control Standard, AI risk frameworks and AI governance frameworks. They are not interchangeable. Some deal primarily with security risks, some with governance, some with risk management, some with identity and authorisation, some with controllability, and some with runtime enforcement. A business deploying AI agents may therefore need to draw from several sources rather than looking for one document labelled "how to secure an AI agent".
OWASP is particularly useful for understanding agent-specific threats: prompt injection, tool misuse, privilege abuse, memory and context attacks, inter-agent risks, runtime controls and technical security patterns. NIST is particularly useful for AI risk management, agent identity, authentication, authorisation, accountability, standards and interoperability, and secure adoption. ISO is particularly useful for organisational AI governance, formal management systems, AI risk management, controllability, human oversight and AI-specific cybersecurity. They overlap, but they answer different questions.
OWASP has become an important source of practical security guidance for generative and agentic AI. Its GenAI Security Project now includes work specifically focused on agentic systems. This matters because an AI agent introduces risks that don't exist in the same form when somebody simply types a question into a chatbot. An agent may have tools, credentials, memory, data access, external connections, delegated authority, other agents it can communicate with, and the ability to create consequences in real systems. Security therefore has to consider what happens after the model generates an answer.
OWASP's Agentic Security Initiative has developed a Top 10 specifically for agentic applications. The risks include areas such as agent goal hijacking, tool misuse, identity and privilege abuse, memory and context poisoning, insecure inter-agent communication, cascading failures, and exploitation of trust between components.
The model is no longer the entire security boundary. You also need to consider what the agent can reach, what tools it can invoke, which identities it operates under, what other agents trust it, what authority can move between systems, and what happens when one component produces a bad result. Securing an agent cannot be reduced to "write a better system prompt".
In September 2026, the OWASP GenAI Security Project introduced the Agent Control Standard (ACS). ACS focuses on making agents inspectable, traceable, instrumentable and controllable at runtime. Its approach is based around standardised middleware hooks through which policies can inspect and control agent activity, so security controls can sit between an agent and consequential actions rather than relying entirely on the model to remember a rule.
Imagine an agent told "never send customer data to an unapproved domain". There are two very different ways to implement that. As an instruction, the agent's prompt says not to. As enforcement, the system actually prevents requests to destinations outside the approved list. The first depends heavily on model behaviour; the second creates a boundary outside the model. For important controls, that distinction matters.
The name can be confusing, though. "Agent control" means many things in ordinary conversation. OWASP's Agent Control Standard has a more specific technical purpose centred on runtime visibility and policy enforcement, and should not be read as a complete answer to every operational question about agents. An organisation may still need to determine: did the scheduled agent actually run? Did it process everything expected? Did the expected business outcome occur? Did a file actually get created, an email actually get sent, a database actually get updated, a backup actually exist? Runtime control and outcome verification are related, but not the same problem.
This distinction is worth making explicit. Prevention asks "is the agent allowed to perform this action?" Verification asks "did the expected outcome actually occur?" Consider an agent authorised to publish an approved article. A runtime control may correctly determine that publishing to this domain is permitted. The agent attempts the action. The workflow reports success. But the page never appears. The permission decision was correct; the business outcome still failed. So mature agent operations need to think about both "should this happen?" and "did it happen?"
The US National Institute of Standards and Technology has also begun dedicated work around AI agents. In February 2026, NIST announced an AI Agent Standards Initiative focused on interoperable and secure AI agent adoption, including attention to standards, protocols, security, identity, interoperability and trusted adoption. This is significant because agent identity becomes increasingly important once agents operate across multiple systems.
Consider "the marketing agent changed this record". Which marketing agent? Running under which account? Acting for whom? Using what authority? Was it the same agent authorised for this task? Could another agent have used the same credentials? Can the action be attributed afterwards? These aren't merely logging questions. They are identity and authorisation questions.
NIST's National Cybersecurity Center of Excellence published a concept paper in 2026 specifically addressing software and AI agent identity and authorisation. It considers how established identity standards and security practices might apply to agents, and highlights questions around identification, authorisation, auditing, non-repudiation, prompt injection, and the risks created when agents receive access to tools, applications and data. It is a concept paper rather than a completed agent standard, but it supports two important principles: you cannot authorise an agent you cannot identify, and you cannot secure agents you don't know exist. That is one reason maintaining an agent register matters.
Knowing which agent is acting doesn't automatically tell you what it should be allowed to do. Think of four layers. Capability: what could the agent theoretically do? Access: which systems can it reach? Permission: which technical operations are available? Authority: which actions is it legitimately allowed to perform for this job? A capable coding agent might technically be able to read a repository, modify code, merge branches, deploy production and change infrastructure, while its job only requires read, write, test and open pull request. Capability is not permission.
NIST's broader AI Risk Management Framework is not an agent-specific security standard, but it remains useful when organisations need to think about AI risk systematically. Its core functions are GOVERN, MAP, MEASURE and MANAGE, which create a structure around questions such as what AI systems we are using, who is responsible for them, what risks they create, how those risks are assessed, how controls are selected, and how we monitor whether those controls remain effective. Agent-specific security controls can sit inside that wider risk-management approach.
ISO/IEC 42001:2023 is a published international standard for Artificial Intelligence Management Systems, designed to help organisations establish, implement, maintain and continually improve how AI is governed and managed. It is broader than agent security, dealing with responsibilities, policies, risk management, accountability, transparency, AI governance and continuous improvement. For organisations deploying agents, that management layer matters: someone still needs to decide who owns the agent, why it exists, who approves its use, how often it is reviewed, what happens when its purpose or underlying model changes, and when it should be retired. Security controls without ownership can decay surprisingly quickly.
Agents shouldn't become orphaned infrastructure. Every significant agent should have an identity, a purpose, an owner, an authority profile, a review date and a retirement process. That is where technical agent security meets organisational governance.
ISO/IEC 23894:2023 is published guidance on managing risks associated with AI. Like the NIST AI RMF, it is broader than AI agents, but agents introduce useful questions for risk assessment because their potential impact depends heavily on what they can actually do. Consider two agents using the same model. Agent A reads public webpages and prepares an internal summary. Agent B reads customer data, modifies CRM records, sends external messages and issues refunds. The underlying intelligence might be identical; the operational risk is not, because authority changes consequence. So agent risk assessment should consider not merely model, accuracy and task, but also permissions, tools, data, destinations, financial limits, external communication, reversibility, human approval and containment.
ISO/IEC TS 8200:2024 is published and particularly relevant to organisations thinking about autonomous or semi-autonomous systems. It provides a framework around the controllability of automated AI systems, with a scope including state observability, state transitions, transfer of control, uncertainty during control transfer, and verification and validation. This connects closely with a practical question: can a human regain control when necessary? That doesn't mean a human should supervise every action; useful autonomy requires the opposite. The system should operate independently inside defined boundaries, but when intervention becomes necessary, control needs to be meaningful.
Imagine an agent that requires approval to read a file, open a webpage, analyse information, write a draft, save a draft and check a result. Technically a human is constantly involved; operationally you've largely removed the value of having an agent. A better approach is often to identify where consequences begin. Let the agent operate autonomously before that point, then require human involvement where appropriate: research, analyse, draft and prepare a CMS entry autonomously, but publish publicly with approval and delete existing content with approval or a denial. The correct boundary depends on context. (More on human oversight.)
ISO is also developing ISO/IEC 42105, guidance specifically addressing human oversight of AI systems. At the time of writing it remains under development at Final Draft International Standard stage. Its scope includes human control and monitoring throughout the AI system lifecycle, making it relevant to questions such as who should supervise an AI system, what information the human needs, when intervention should occur, how human-machine interaction should support meaningful oversight, and how organisations can avoid nominal oversight where a person technically approves something without genuinely understanding the decision. Because the document is still under development, organisations should check its publication status before treating it as a final International Standard.
Human approval is an important control, but it doesn't prove the subsequent action worked. Suppose an agent prepares a newsletter, a human approves it, the agent attempts to send it and reports SUCCESS. We know the content was approved. We don't necessarily know the newsletter was sent. So there are two separate questions. Authorisation: was the agent permitted to perform the action? Outcome: did the action produce the expected result? That distinction becomes increasingly important as businesses rely on agents for unattended work.
ISO/IEC 27090 focuses specifically on cybersecurity threats and compromises affecting AI systems. At the time of writing, the first edition is under publication. Its scope includes understanding, detecting and mitigating AI-specific security threats throughout the AI lifecycle, including threats affecting training data, models, AI workflows and the broader AI system. It complements established cybersecurity standards rather than replacing conventional security practices, because agent security is not separate from ordinary cybersecurity. Agents still depend on accounts, credentials, networks, APIs, databases, cloud services, software dependencies and access controls. AI-specific controls sit on top of that foundation.
An agent doesn't make ordinary security principles obsolete. You still need strong authentication, credential management, least privilege, network controls, logging, patching, secrets management, backup, recovery and incident response. Then agentic systems introduce additional questions: what instructions can influence the agent, which tools it can invoke, whether untrusted content can trigger actions, whether it can delegate work, whether another agent can borrow its authority, whether it can change its own permissions, create credentials, disable monitoring, or act outside the purpose for which it was authorised. Agent security extends cybersecurity. It doesn't replace it.
| Layer | Where it sits |
|---|---|
| Governance | ISO/IEC 42001 (managing AI responsibly), NIST AI RMF (identify, assess, manage AI risk), ISO/IEC 23894 (AI risk management) |
| Identity and authorisation | NIST agent identity work (how agents are identified, authenticated, authorised, audited) |
| Agent-specific threats | OWASP Agentic Security Initiative (new attack paths and failure modes when AI can act) |
| Runtime control | OWASP Agent Control Standard (inspect activity and enforce policy while agents operate) |
| Controllability | ISO/IEC TS 8200 (observability, control transfer, controllability) |
| Human oversight | ISO/IEC 42105 (monitor, control and intervene) - under development |
| AI cybersecurity | ISO/IEC 27090 (AI-specific security threats) - under publication |
At Creative Sauce AI, we organise practical agent security around questions businesses can actually answer: identity (what is this agent, who owns it, how is it identified), authority (what job has it been authorised to perform), permissions (which systems, tools, data and actions it can access), boundaries (what it must never do, and how those restrictions are enforced), human control (which actions require human judgement or approval, and where control can be transferred), monitoring (what actions, failures and boundary events should be recorded), observability (can we understand what happened across the workflow), verification (what evidence proves the expected outcome actually occurred), containment (can the agent be stopped, authority revoked, systems recovered), and governance (who owns the overall system, when is it reviewed, what happens when it changes).
No single framework above maps perfectly onto this structure, nor should it. Our framework is a practical way of applying several overlapping security and governance principles to real agent deployments. It is not a certification standard and does not replace OWASP, NIST or ISO guidance, legal obligations or professional security assessment.
| Agent Security area | OWASP | NIST | ISO | Practical question |
|---|---|---|---|---|
| Identity | Identity and privilege risks | Agent identity and authorisation | Governance and security standards | Can we reliably identify the agent? |
| Ownership | Governance-related guidance | GOVERN | ISO/IEC 42001 | Who is responsible for it? |
| Permissions | Tool misuse and privilege risks | Authorisation and least-privilege principles | Risk and security management | What can it access? |
| Authority | Runtime policy and privilege controls | Agent authorisation | Governance and controllability | What is it actually allowed to do? |
| Guardrails | Agentic threat guidance and ACS | Risk controls | Risk/security frameworks | What prevents prohibited behaviour? |
| Prompt injection | GenAI and agentic security guidance | Agent security research | AI cybersecurity | What happens when instructions are hostile? |
| Human approval | Runtime policy controls | Risk-based oversight | TS 8200 and developing 42105 | Where should humans intervene? |
| Monitoring | ACS and agentic guidance | Measurement and monitoring | 42001 / 8200 / security standards | What happened? |
| Observability | ACS | Measurement and auditing | TS 8200 | Can we reconstruct what happened? |
| Multi-agent security | Agentic Top 10 | Emerging agent work | Broader governance/risk controls | Can authority or failure propagate between agents? |
| Incident response | GenAI security guidance | Cybersecurity/risk frameworks | AI and conventional cybersecurity | What happens when something goes wrong? |
| Verification | Partial overlap | Risk measurement | TS 8200 verification/validation | Did the expected outcome actually occur? |
| Governance | Security governance | GOVERN | ISO/IEC 42001 | Who controls the system over time? |
This table is deliberately a practical mapping. It does not imply formal equivalence between controls in the different frameworks. For compliance or certification work, use the original standards and official crosswalks.
In September 2026, OWASP released its GenAI Security Industry Framework Crosswalk, mapping GenAI vulnerabilities against controls from multiple established security, governance and compliance frameworks. That is useful because organisations increasingly face the opposite problem from having too little guidance: there is a lot of guidance. The challenge becomes understanding which framework answers which question, where controls overlap, where gaps remain, and how abstract requirements translate into the way an actual agent operates. A crosswalk helps organisations avoid treating every new framework as an entirely separate security programme.
A team can produce an AI policy, an agent register, a risk assessment, an approval process, a monitoring dashboard and a standards crosswalk, and still have an agent with excessive authority. Documentation is valuable, but documentation is not enforcement. Ask what technically prevents the prohibited action, and then what evidence tells us the control actually worked.
Suppose an organisation deploys an agent that reads supplier invoices, matches them to purchase orders, prepares payments and handles exceptions. Different parts of the standards landscape help with different questions. Governance: who owns the agent, why is it used, how is risk reviewed? Identity: which technical identity performs the actions? Authorisation: which finance systems can it access? Authority: can it prepare a payment, can it execute one, up to what amount? Human oversight: when must a finance employee intervene? Runtime control: what technically prevents the agent from paying an unapproved destination? Monitoring: what actions were attempted? Verification: did every expected invoice receive a valid outcome? Incident response: what happens if the agent behaves incorrectly? That is why agent security needs several layers.
Standards tell you what good control looks like. Your implementation determines whether the control is real.
You can write "the agent cannot transfer more than £500", but if its credentials permit unlimited payments and the only restriction exists in its prompt, the technical reality may not match the policy. You can write "every agent action is monitored", but if nobody can tell that yesterday's scheduled job never ran, the operational reality may not match the policy. You can write "human approval is required", but if the human sees only APPROVE / DENY with no useful context, the control may exist without providing meaningful oversight. Policy and reality need to agree.
You don't need to become a standards expert before using AI agents. Start with practical controls: know what agents you have (maintain an inventory); give each agent an owner (avoid orphan agents); define its job (authority should follow purpose); restrict access (minimum useful permissions); define hard boundaries (especially around money, external communication, sensitive data, publication, deletion and authority changes); decide where humans are required (put humans where consequences begin); monitor meaningful activity (especially failures, denied actions and boundary attempts); define evidence of success (don't rely solely on the agent reporting SUCCESS); prepare containment (know how to pause the agent and revoke access); and review it (agents, models, integrations and business processes change, so your controls need to change with them). (A practical deployment process.)
Agentic AI security is still developing. OWASP's Agent Control Standard arrived in September 2026. NIST's dedicated AI Agent Standards Initiative launched in 2026, and its agent identity and authorisation work is developing. ISO/IEC 27090 is moving through publication. ISO/IEC 42105 remains under development. More agent-specific standards and guidance will follow, so don't treat this page as a static compliance checklist. We will update it as the standards landscape changes.
Last reviewed: October 2026.
Different frameworks use different terminology, but a common direction is emerging. AI systems need identity, governance, risk management, visibility, appropriate authority, human control, security boundaries, monitoring, and the ability to intervene. For agents, there is one more operational question worth asking every time: what proves the job actually happened? Because an agent can stay inside its permissions and still fail. It can be authorised correctly and still make a mistake. It can run successfully and still produce an incomplete outcome.
Security controls reduce what can go wrong. Verification helps you discover what actually did. You need both.
If you're already running AI agents, don't begin with paperwork. Begin with reality: what agents exist, what can they access, what authority do they have, which actions create consequences, how do you know they ran, what proves they completed the job, and how would you stop them if you needed to? That is where agent security becomes operational, and it is the problem we're working on with Agent Control.