Securing Enterprise AI Agents with ISO/IEC 42001 and NIST AI RMF

As companies deploy more AI agents, they're creating a massive digital workforce with access to sensitive data, critical systems, and the ability to act independently. Now imagine thousands, or even millions, of these agents operating without proper supervision. A single mistake or security breach could potentially disrupt operations across an entire company.

Clearly, security isn't keeping pace with AI adoption. Gartner expects 40% of enterprise applications to include AI agents by the end of 2026, while IBM's 2026 Cost of a Data Breach Report found that roughly one in five organizations experienced an AI-related breach, and the vast majority (92%) was lacking proper AI access controls.

To enforce security at scale, organizations are now adopting AI agent security: the practice of protecting the identities, tools, data, and actions an AI agent can use across systems. Keep in mind that AI agents receive goals, decide how to achieve them, and take actions on their own, often times, completely unsupervised and unauthorized. Given how much autonomy these agents have, the risks are high. These agents could expose sensitive data, delete important records (or possibly wipe out entire databases), take unauthorized actions, or disrupt critical business operations.

So, in this guide, Uriel Bekerman explains how companies can secure their AI agents following the best practices and guidelines of ISO/IEC 42001 and NIST AI Risk Management Framework (RMF). Uriel is a GRC expert with over 10 years of experience, an MSc in Cybersecurity, and ISO/IEC 42001 and 27001 credentials. To explore the topic in more detail, we will cover a key set of questions: Who owns each agent? What can each agent access? And which actions require human approval?

AI agents introduce vendor and identity risks

First, we want to know what each AI agent can actually do inside the organization. When we think about AI agents, we need to consider that:

• They can take actions. When an agent has access to tools, an incorrect output can lead to a sent email, a changed record, or a deleted resource. The consequences depend on the permissions it has.

• They use non-human identities. Agents may access systems through API keys, OAuth tokens, or service accounts. Those credentials need owners, limited permissions, and a process for rotation and revocation.

• They process untrusted input. Agentic systems can scan through and process billions of web pages, documents, emails, pull requests from code repositories, and even tool outputs that may contain instructions that attempt to redirect an agent. To enforce security, there should be certain guardrails that limit what the agent can do when it encounters that content.

Let's start with third-party AI models and agent platforms, which introduce their own vendor risks. Just like with any other software provider, companies need to understand what these vendors can access, how they handle sensitive company data, and what security measures they have in place. 

In a well-known access-related incident, the Salesloft Drift in August 2025, attackers used stolen OAuth tokens from Salesforce, Google Workspace, and some Slack integrations to access customer environments, affecting more than 700 organizations. The key takeaway is that even trusted integrations can become security risks if their credentials are compromised. Therefore, companies need to understand which systems their agents connect to, limit those integrations' permissions, and regularly review and rotate credentials to reduce potential security risks.

"Whether it is Anthropic with Claude, Microsoft with Copilot or Google with Gemini, an AI service is one more vendor. It needs all the same security measures, administrative and technical, that any other vendor and any other asset needs. The difference is that with AI, people seem to have blind trust. They upload sensitive information with much less awareness of what they are loading.” — Uriel Bekerman

Build an AI agent inventory before assessing risk

The next step in the AI security journey is to assess the AI agents themselves. Even if the underlying provider is secure, an AI agent can still introduce risks depending on how it is configured. Overall, we need to know who is responsible for each agent, which systems it can access, what permissions it has, and what actions it can perform. No matter how a company uses AI agents, someone must be accountable for their security.

• If you're developing an AI agent: You're responsible for building it securely, managing its permissions, and making sure it behaves as expected.

• If you're selling AI agents to customers: You need to make sure your product is secure, while also clarifying which security responsibilities belong to your customers.

• If you're using a third-party AI agent: You need to understand what the provider is responsible for versus what your company needs to manage, such as access to internal systems and sensitive data.

To understand the risks associated with each AI agent, companies should create a dependency map showing how the agent operates and what it connects to: who is the owner, what are all the AI models being used, which tools are connected, as well as notes on credentials, data sources, memory, external services, and third-party providers. When creating this dependency map, we also suggest documenting what actions the agent can perform and who can change its permissions.

"The differentiator with AI is that you do not go straight to the vulnerabilities. First you understand everything you have, what you use it for, what assets you are consuming and what resources you need. After that deep understanding, which is what we call governance, you move on to the risks." — Uriel Bekerman

Establishing the governance layer with ISO/IEC 42001

Now, let’s look at the security and compliance frameworks out there. One key framework here is ISO/IEC 42001:2023, which specifies requirements for an artificial intelligence management system (AIMS). Specifically, it gives organizations a way to define policies, assign responsibilities, identify AI-related risks, and establish processes for managing AI systems.  

That said, ISO 42001 isn't a replacement for technical security and privacy controls. Organizations still need to implement the right safeguards for their specific AI systems, often combining the framework with other security standards and engineering best practices.

"If you do not have a framework, you do not know where to start. In the end, the framework is a checklist: if you take it as a reference, the controls are recommendations; if you want to certify, they are mandatory. The first control is that you need a policy. Another is that every model has to have an owner." — Uriel Bekerman

While this blog isn't meant to get too technical, we’d still like to break down Annex A in detail, as it outlines practical controls organizations can consider to address AI-agent-related risks:

• A.2 AI policy. Define the scope of the program, principles, commitments, the approval process for new agents, and the policy review schedule, among others.

• A.3.2 Roles and responsibilities. Assign an accountable owner for each agent and define who approves permissions, reviews changes, and handles incidents.

• A.4.3 to A.4.5 Data, tooling, and system resources. Document the data sources, tools, APIs, and computing resources involved in each agent’s operation.

• A.5 Impact assessment. Assess how the agent’s intended use and potential failures could affect individuals, groups, and society. Document the findings and the resulting decisions.

• A.6.2.6 and A.6.2.8 Operation, monitoring, and event logging. Define operational monitoring and the records needed to investigate actions, while protecting sensitive information in logs.

• A.9.2 to A.9.4 Responsible and intended use. Document the agent’s intended use, operating limits, and appropriate human oversight.

• A.10.3 Suppliers. Assess the risks associated with model providers, MCP servers, and tool vendors. Define supplier requirements according to the access and responsibilities involved.

Note that you don't necessarily need to pursue ISO/IEC 42001 certification to benefit from the framework. Your organization can use it as a practical reference to improve how it manages AI risks, establishes internal policies, and implements appropriate security and governance controls. For example, an organization that is already working toward SOC 2 compliance or ISO/IEC 27001 certification can incorporate relevant AI governance practices into its existing security and compliance programs. Just keep in mind that using ISO/IEC 42001 as a reference is not the same as being certified against it. Formal certification requires a separate assessment against the standard's requirements.

Understanding AI Risks with NIST AI RMF

The NIST AI Risk Management Framework is another useful resource for organizations looking to manage AI risks. Unlike a certification standard, it provides a voluntary, practical approach built around four key functions:

• Govern: Establish policies, responsibilities, and accountability for managing AI risks.

• Map: Identify how AI systems are used, their operating context, and the potential risks involved.

• Measure: Assess and evaluate those risks to understand their likelihood and potential impact.

• Manage: Prioritize risks and implement appropriate measures to address them.

Organizations can apply these four functions throughout an AI agent's lifecycle, from initial development to deployment and ongoing monitoring. For teams working specifically with generative AI, NIST also provides the Generative AI Profile (NIST AI 600-1), which offers additional guidance on identifying and managing risks associated with generative AI systems.

NIST has also launched work focused directly on agents. Its AI Agent Standards Initiative, announced in February 2026, addresses standards, interoperability, security, and identity. This work provides additional context for teams applying the broader AI RMF to systems that can take actions across connected tools and services.

"These frameworks are all very similar. I’d say that ISO is more organized: it gives you the clean path with all the policies. NIST is more direct, with more domains and controls, a bit more technical and security-oriented. For me, you use both. Where ISO is vague on a control, you check whether NIST complements it, and where NIST is vague, you complement it with ISO." — Uriel Bekerman

To eliminate doubt, when compared against each other, ISO/IEC 42001 and NIST AI RMF take slightly different but complementary approaches to AI security and governance:

• ISO/IEC 42001 focuses on policies, responsibilities, risk management, and continuous improvement.

• NIST AI RMF provides practical guidance for identifying, assessing, and managing AI risks.

Together, they help organizations manage AI risks and implement the right safeguards. Let’s now look at the most important controls that apply regardless of framework.

Ten practical controls for enterprise AI agent security

Once the AI inventory is established, teams can select controls for the agent’s actual permissions, dependencies, and potential impact. Below, we break down 10 of the most important controls as a practical guide to secure AI agents:

1. Data governance and model provider due diligence. Classify the data the agent can bring into its context and restrict sensitive categories to agents with a documented need. Before connecting a model provider, plugin, package, or MCP server, review its data retention, use of inputs for training, processing location, subprocessors, and security commitments, and record the approved configuration. Reassess when the provider changes its terms, or the agent gains access to new data sources. Suggested alignment: ISO/IEC 42001 A.7 and A.10.3, and NIST AI RMF Govern and Map.

2. Least privilege per agent and per task. Limit each agent to the data and actions its task requires. Enforce those limits in the application, API, and identity layer, and use short-lived credentials where supported. A prompt telling the agent what not to do is not an authorization control. Suggested alignment: ISO/IEC 42001 A.4.4 and A.9.4, and NIST AI RMF Manage.

3. Non-human identities you can inventory and revoke. Use distinct agent identities where supported, and avoid shared credentials that prevent attribution. Record each identity, OAuth grant, and API key, assign an owner, and define rotation and revocation procedures. Test whether the team can disable access within the time required by its incident response plan. Suggested alignment: A.3.2 and A.4.4, and NIST AI RMF Govern and Map.

4. Tool access by allowlist. Allow only the tools and operations the agent needs. Validate parameters, separate read and write permissions, and restrict destinations and transaction volumes where relevant. Define approval requirements for consequential actions such as deleting records, sending payments, or deploying code. Assign ownership for MCP servers and review their access before use. Suggested alignment: A.4.4 and A.10.3, and NIST AI RMF Map and Manage.

5. Resource limits and runaway execution. Set limits on how much an agent can consume and how long it can run: caps on calls per task, tokens, spend, and execution time, plus a maximum depth for delegation to other agents or sub-tasks. Configure alerts as usage approaches each limit, and define whether the agent stops, pauses for approval, or degrades gracefully when it reaches one. Test that a loop, a retry storm, or a manipulated task cannot exhaust budgets or downstream systems before someone notices. Suggested alignment: ISO/IEC 42001 A.4.5 and A.6.2.6, and NIST AI RMF Manage.

6. Prompt injection testing and restricted tool execution. Treat retrieved documents, web pages, messages, and tool outputs as untrusted input. Separate instructions from data, restrict what the agent can execute, and control outbound transfers. Test whether embedded instructions can trigger unauthorized tool calls or disclose sensitive information. Use resources such as the OWASP Top 10 for Agentic Applications to inform threat scenarios, and preserve the test results. Suggested alignment: A.6.2.4 and NIST AI RMF Measure.

7. Integrity of memory and persistent context. Treat anything the agent stores for later use, such as conversation memory, vector stores, retrieved knowledge bases, and cached tool outputs, as an attack surface that can carry injected instructions across sessions. Restrict who and what can write to these stores, record the source of each entry, and set expiration and review rules for persisted content. Test whether content planted in one session can influence later actions, and define how to purge and rebuild a store if it is compromised. Suggested alignment: ISO/IEC 42001 A.7 and A.6.2.6, and NIST AI RMF Measure and Manage.

8. Human approval for consequential actions. Decide which actions require approval before execution, which can be monitored and interrupted, and which can run automatically within defined limits. Give reviewers enough context, time, and authority to reject an action. Track overrides alongside review quality, exceptions, and incidents. Suggested alignment: A.5 and A.9.2 to A.9.4, and NIST AI RMF Govern.

9. Audit logging with data minimization. Record the agent identity, tool calls, relevant parameters, approvals, outcomes, timestamps, and model or configuration version needed to reconstruct an action. Redact secrets and minimize personal or confidential content. Define access controls, retention, and incident review procedures for the logs. Suggested alignment: A.6.2.6 and A.6.2.8, and NIST AI RMF Measure.

10. Assessment before deployment and testing after changes. Review the agent against its dependency map and document the risks, decisions, and release criteria. Before deployment, retain an approved inventory, permission matrix, test results, oversight rules, and logging policy. Test the procedures for revoking credentials, isolating the agent, and stopping its actions. Retest affected behaviors after changes to models, tools, prompts, or permissions. Suggested alignment: A.5 and A.6.2.4, and NIST AI RMF Map and Measure.

Now that we’ve covered a list of the most important controls, let’s explore other important risks like shadow AI in more detail.

Shadow AI and the agents nobody approved

Shadow AI is the use of AI tools or agents outside an organization’s approved inventory and controls. For instance, when an employee connects an unapproved tool to company data, the security team may lose visibility into access, retention, and external transfers.

"If an organization bans AI in general, employees will use it anyway, and that is shadow AI: the data left your systems and you did not control it. Scenario two: you allow it, you pay for a subscription managed by the organization with all the security measures in place, you monitor it, you add DLP and you train people on inputs and outputs. There will still be some shadow AI, but you have reduced it." — Uriel Bekerman

The same applies to AI agents, especially when employees connect them to company emails, automate workflows, or use personal MCP servers to access business data. To mitigate risks, our team suggests to?

• Create mechanisms for secure AI use: Provide approved tools, establish a simple process for reviewing new agents, apply data loss prevention (DLP) controls, and train employees on safe AI usage.

• Adopt AI security training programs: According to the World Economic Forum's Global Cybersecurity Outlook 2026, 87% of organizations consider AI vulnerabilities the fastest-growing cyber risk. Interestingly enough, McKinsey also reports that nearly 60% of organizations identify knowledge and training gaps as a major barrier to responsible AI.

• Don’t forget about requirements: US companies serving EU customers should check whether the EU AI Act applies to their AI systems. Depending on the violation, fines can reach €35 million or 7% of global annual revenue. The European Commission's implementation timeline provides more details on how to keep an inventory of AI agents, assign owners, and establish oversight processes, which are good starting points.

Implementing AI agent security and governance with Ewents

If you finish reading this blog, we’d like you to leave with one idea: deploying AI agents securely is critical, because these systems can access sensitive information, connect to business applications, and take actions on their own. Without proper safeguards, a single compromised or misconfigured agent could expose company data, perform unauthorized actions, or disrupt critical operations.

Looking ahead, the biggest barrier organizations will face to scale agentic AI is security risks. In McKinsey's 2026 AI Trust Maturity Survey, nearly two-thirds of respondents identified security and risk concerns as the biggest challenge to adoption AI at scale. As our GRC expert Uriel Bekerman explains:

"Software developers simply push out code, often times without considering the security considerations since that’s not usually a part of their role. If you don't have someone working alongside them to assess risks and think about security and governance, these things can easily get overlooked. You need someone who can step in before production and ask: Have we reviewed the risks? Do we have the right policies? Do users understand how to use this safely? Does management know what could go wrong?"

At Ewents, we help companies address AI security risks by embedding security and compliance experts into nearshore dedicated engineering teams. We can help your company onboard security-focused roles such as:

• GRC and AI Governance specialists to establish policies, assess risks, define responsibilities, and prepare compliance documentation.

• Application Security Engineers to identify vulnerabilities, test for prompt injection, and help protect agents from unauthorized actions.

• Cloud Security Engineers to manage infrastructure security, agent identities, and access permissions.

• Secure Software Developers to build security controls directly into applications.

• AI and Data Engineers to support AI models, data pipelines, retrieval systems, and ongoing evaluations.

If you found this blog useful and are thinking about deploying AI agents with proper security controls, get in touch with Ewents.

Frequently Asked Questions

• What is AI agent security?

  The goal of AI agent security is to protect everything an AI agent can access and use within a business, including identities, tools, data, and actions. Unlike a traditional chatbot, which provides answers and leaves the next steps to the user, an AI agent receives an objective and can execute tasks on its own, often without someone reviewing every action. Because of this autonomy, organizations must ensure agents operate securely and perform only authorized actions.

• How is securing an AI agent different from securing a chatbot?

  Unlike chatbots, AI agents often need access to company systems, sensitive data, and credentials to complete their tasks. As a result, if someone manipulates an agent or it has more permissions than necessary, the risks can extend to everything the agent can access, potentially leading to data theft or unauthorized actions. In many ways, AI agents introduce risks similar to those associated with employees who have access to company systems. Just as people can make mistakes, fall for phishing attacks, or accidentally expose information, AI agents can also be manipulated or behave unexpectedly.

  So, our team recommends setting up a baseline of agentic security hygiene, including access restrictions, regular security reviews, and monitoring to reduce these risks.

• Does ISO/IEC 42001 apply to enterprise AI agents?

  Absolutely. Organizations developing or using AI systems, including enterprise AI agents, can apply ISO/IEC 42001. Overall, the goal of this framework is to apply AI responsibly, securely, and in a structured way. Following a framework like ISO/IEC 42001 allows organizations to set clear responsibilities, identify potential risks earlier, and implement measures to prevent those risks from becoming actual security incidents.

• How can ISO/IEC 42001 and NIST AI RMF be used together to secure AI agents?

  Ideally, organizations should use both frameworks together, as they complement each other. ISO/IEC 42001 is a certifiable standard, while NIST AI RMF is a voluntary framework, so they take different approaches and have different requirements. However, both address many of the same challenges from different angles:

  • ISO/IEC 42001 provides the structure for establishing and managing an AI governance program, including policies, responsibilities, and risk management processes.

  • NIST AI RMF helps organizations go deeper into identifying, evaluating, and managing AI-related risks throughout an agent's lifecycle.

• How should we manage AI agent identities and least-privilege access?

  Every organization should treat AI agents like another user within your company's systems. Just as organizations assign roles and permissions to employees, they should do the same for AI agents: giving each agent a clearly defined role, granting access only to the information and tools it needs, and regularly reviewing those permissions.

  Additionally, our team believes that every agent should have its own identity rather than sharing credentials with other agents or employees. Otherwise, it becomes much harder to track who or what performed a particular action, especially when investigating security incidents.

• How can we reduce prompt injection risks in AI agents?

  Based on our experience, one of the best ways to reduce prompt injection risks is to limit what an attacker can actually do, even if they manage to manipulate an AI agent. To achieve this, organizations should limit agent permissions, control which tools they can access, and restrict what information they can share outside the company. At the same time, it's important to remember that external content, such as websites, documents, and emails, can contain malicious instructions, so agents shouldn't automatically trust everything they process.

• When should a human approve an AI agent’s action?

  A human should approve an agent's action every time it is about to perform something difficult to reverse or that could have serious consequences. For example, sending payments, deleting important records, deploying code into production, or sharing sensitive information outside the organization. However, keep in mind that adding an approval step isn't enough. The reviewer needs enough context, time, and authority to reject the action or request changes. Otherwise, the approval process becomes just another formality rather than an effective security control.

• Do we need ISO/IEC 42001 certification to secure AI agents?

  Not necessarily. Many organizations use ISO/IEC 42001 voluntarily as a reference to understand where to start and how to improve their AI security and governance practices. While certification isn't required to implement these measures, it can give customers additional confidence that a company manages AI responsibly and guide senior management in evaluating whether the organization's AI governance program meets the standard's requirements and operates as expected.