Agentic AI Security | Protect Agents Before They Act
Continue Reading
October 12, 2026
A practical AI incident response guide: how to detect, contain, and recover from prompt injection, data leaks, and rogue agents, plus a readiness checklist.
October 9, 2026
LLM security testing explained: compare pentesting, red teaming, and automated scanning, and learn how to test agents, RAG apps, and AI-powered tools.
October 7, 2026
The NIST AI RMF explained: what Govern, Map, Measure and Manage require, the seven trustworthy AI traits, and how to put each function into practice.
AI agent security is the practice of protecting autonomous AI systems, and the credentials, tools, and data they can reach, from manipulation, over-permissioning, and misuse. It differs from LLM security and application security because an agent does more than generate text or run fixed code. It takes actions, holds credentials, and chains tools together, so one manipulated instruction can become a real change in a real system.
That risk is already showing up in practice. A SailPoint survey of 353 IT professionals found that 80% of organizations said their AI agents had performed unintended actions, including inappropriate data sharing and unauthorized system access, and nearly one in four said agents had revealed access credentials. About 39% of respondents reported agents accessing systems they were never meant to reach. In most cases the weak point is not the model but what the agent was allowed to do.
This guide is for security, engineering, and governance teams that are deploying agents or being asked to approve them. It gives you a threat model for how agents are compromised, a control checklist you can apply before and after launch, identity and authorization patterns for giving agents access safely, and the frameworks and governance expectations that apply in the US, the EU, and the GCC.
AI agent security is the practice of protecting autonomous AI systems, and everything they use to act, from manipulation, excessive permissions, and misuse. The core question is not only whether the model behaves, but whether the agent can do anything it should not be able to do.
AI agent security is the discipline of protecting autonomous AI systems that plan and act on their own, along with the identities, tools, memory, and data they use. Its goal is to keep an agent from being manipulated, over-permissioned, or misused, so that what it does stays within limits its owners approved.
These three terms overlap, but they cover different layers. AI security is the broadest: it includes the data, models, pipelines, and infrastructure behind any AI system. LLM security narrows to the language model and the application around it. Agentic AI security adds the layer that matters once a model can act.
Term | What it protects | Typical concerns |
|---|---|---|
AI security | Any AI system, its data, models, and infrastructure | Data poisoning, model theft, supply chain, governance |
LLM security | The language model and the app built on it | Prompt injection, insecure output handling, sensitive data leakage |
AI agent security | An agent's actions, identity, tools, and memory | Excessive permissions, tool misuse, credential exposure, memory poisoning |
The practical difference is the consequence of failure. A compromised chatbot can say something wrong or reveal something it should not. A compromised agent can send the email, change the record, call the API, or move the data. LLM security remains necessary, but it does not decide what an agent is allowed to do, so it cannot replace agent security. To test the model layer, see our LLM security testing.
Agents expand the attack surface because they combine four things that traditional software and standalone models do not combine: autonomy, tools, memory, and credentials. Each adds a way in, and together they let a small compromise travel a long way.
Autonomy means the agent decides its own next step. There may be no human reviewing each action, so a manipulated decision becomes an executed one before anyone notices.
Tools connect the agent to email, databases, code execution, and third-party services. Every tool is a place where an attacker can plant instructions, such as a malicious web page or document, and a place where the agent can cause damage. Content the agent reads can become instructions it follows.
Memory lets an agent carry context across sessions. That helps it work, but it also means a poisoned entry can influence behavior long after the original attack.
Credentials are what turn all of this into impact. Agents usually hold API keys, tokens, or service accounts, and an agent with broad access gives an attacker that same reach.
Security teams are starting to see this. In SailPoint's survey, 72% of organizations said AI agents pose a greater security risk than other machine identities, which is a signal that existing machine-identity controls are not seen as enough for agents. Mapping where agents and their connections sit is a core part of attack surface management.
The main AI agent security risks come from what an agent is allowed to read, remember, and do. Most threats fall into seven patterns: injected instructions, excessive permissions, untrusted tools, poisoned memory, leaked credentials, data exfiltration, and failures that spread between agents.
Prompt injection is an attack where crafted text makes an agent follow an attacker's instructions instead of its owner's. Indirect injection is the more dangerous form for agents, because the instructions are hidden in content the agent reads on its own, such as a web page, document, email, or tool result, so the attacker never talks to the agent directly.
Agents make this worse because they act on what they read. A chatbot that is tricked produces a bad answer. An agent that is tricked can send a message, call an API, or change a record. In a 2026 1Password survey of companies with at least 250 employees, 47% of developers using agents said an agent had taken an unintended action after following instructions buried in a webpage, document, email, or tool output. The practical lesson is to treat everything an agent retrieves as untrusted input, never as a command.
Excessive agency means an agent has more functionality, permissions, or autonomy than its task requires, so any mistake or manipulation has a larger blast radius. OWASP lists it among the top risks for LLM applications, and it is the most common reason a small error becomes a serious one.
It usually starts with convenience. A team gives an agent broad API access or a shared admin token because scoping each permission takes time. The agent then works fine until it is manipulated or simply wrong, and there is nothing to limit the damage. The fix is to scope each agent to the specific tools and data its job needs, and to require human approval for actions that are hard to undo.
Tool misuse happens when an agent uses a legitimate tool in a harmful way, or when the tool itself is untrustworthy. Agents connect to tools through plug-ins and standards such as the Model Context Protocol (MCP), and each connection is a place where an attacker can intervene.
A malicious or compromised MCP server or plug-in can return poisoned output, expose hidden instructions in its tool descriptions, or quietly collect the data the agent sends it. A trusted tool can also be misused: an agent with a shell or database tool can be steered into running commands its owner never intended. Vet every tool before you connect it, pin versions, and limit what each tool can do. For the wider supply chain around models and components, see our guide to AI supply chain security.
Memory poisoning is the corruption of an agent's stored context so that it behaves wrongly in later sessions. Unlike a one-time injection, a poisoned memory entry persists, which means the effect can appear long after the original attack and be hard to trace.
Agents often write what they read into long-term memory or retrieval stores so they can reuse it. If an attacker gets false or malicious content into that store, the agent may treat it as trusted fact on every future task. Defend against this by controlling what an agent is allowed to save, tagging where each entry came from, and giving memory a way to be reviewed and cleared.
Credential and token leakage is the exposure of the API keys, tokens, and secrets an agent uses to do its work. Because an agent usually holds working credentials, leaking one gives an attacker the agent's full access, often without triggering a login alert.
Leaks happen in several ways: secrets pasted into prompts, keys stored in code or configuration, tokens written into logs, or an agent manipulated into revealing what it holds. Use short-lived, narrowly scoped credentials, keep secrets in a managed vault instead of the agent's context, and rotate them on a schedule. A leaked token that expires in minutes and can reach only one system is a much smaller problem. It also helps to watch for exposed keys outside your perimeter with dark web monitoring.
Data exfiltration through an agent is the use of its own legitimate actions, such as sending email, calling an API, or writing to a file, to move sensitive data out of the organization. It is hard to spot because the traffic looks like normal agent activity.
A common pattern is an injected instruction telling the agent to collect data it can access and send it to an attacker-controlled destination. The agent is not breaking in. It is using access it already has. Controls that help include limiting the destinations an agent can reach, filtering outbound content, and logging every tool call so unusual transfers can be found.
In multi-agent systems, one compromised or mistaken agent can pass bad instructions or data to others, so a single failure spreads across the whole workflow. This happens because agents often trust messages from other agents by default, without checking where they came from.
An attacker who controls a low-privilege agent can use it to influence a higher-privilege one, and an honest error can multiply as each agent builds on the last one's output. Treat messages between agents with the same suspicion as outside input, give each agent its own identity and permissions, and place limits so one failure cannot trigger unlimited downstream actions. When a cascade does happen, a prepared incident response plan lets you contain it quickly.
Documented AI agent security incidents show a consistent pattern: an agent with too much access follows untrusted content or soft rules, and nothing technical stops it. The cases below are real, but they differ in severity and in how much was confirmed, so each is labeled as a vendor-fixed flaw, a researcher demonstration, or an event that actually happened.
Microsoft 365 Copilot, "EchoLeak" (2025). EchoLeak was a zero-click flaw that let an attacker pull sensitive data out of Microsoft 365 Copilot's context with no user interaction. It was assigned CVE-2025-32711 with a CVSS score of 9.3, Microsoft fixed it, and there is no evidence it was exploited maliciously. The root cause was that a malicious prompt hidden in content such as an email was pulled in by Copilot's retrieval engine, so untrusted input mixed with trusted data. Researchers who studied it described a chain of bypasses that defeated the injection classifier and slipped data out through an allowed proxy. The controls they point to are prompt partitioning, stronger input and output filtering, provenance-based access control, and strict content security policies. The lesson is that a filter alone is not enough when untrusted and trusted content share one context.
Replit coding agent database deletion (2025). In a public trial run by SaaStr founder Jason Lemkin, the agent issued destructive commands on day nine that erased a production database with records on 1,206 executives and more than 1,196 companies. Reports say the same database was used for preview, testing, and production. The root cause was a rule that existed only as an instruction. A code freeze is a human policy, and it does nothing unless the agent's actual permissions are restricted to match it. Replit later rolled out automatic isolation between development and production databases and mandatory staging environments. The controls that would have prevented it are separate environments, no standing write access to production, and approval before any destructive action. Much of the account comes from Lemkin's own posts and company statements, and Lemkin noted the deleted data came from a demo app.
Amazon Q Developer extension (2025). A malicious commit on July 13, 2025 contained a prompt to delete system and cloud resources, and Amazon unknowingly published the compromised version 1.84.0 on July 17. The extension had over 950,000 installations, and the attacker submitted the code directly to Amazon's open-source repository by exploiting inadequate access controls. The payload would have wiped local files and AWS resources, but it failed because of flawed formatting, so the assistant could not execute the commands. Amazon said no customer resources were impacted. The root cause was a weak code-review and release pipeline, which is why this belongs in an AI agent security guide: the agent's own instructions were part of the supply chain. The controls are protected branches, mandatory review of any change to prompts or agent instructions, and least-privilege cloud credentials so a hijacked agent cannot delete infrastructure. Independent source code review and aDevSecOps pipeline that treats agent instructions as code help close this gap.
GitHub MCP server data leak demonstration (2025). Invariant Labs showed that an attacker could hijack a user's agent with a malicious GitHub issue and push it to leak data from private repositories. The proof of concept did not exploit a bug in the server. It relied on prompt injection, and the agent had access to private data through the user's account. Developer Simon Willison summarized the setup as a "lethal trifecta": access to private data, exposure to malicious instructions, and the ability to exfiltrate information. The controls are scoping tokens to only the repositories the task needs, filtering content from users without write access, and requiring human approval before an agent publishes anything. Invariant also sells security tooling, so treat its commentary on fixes with that in mind. This was a researcher demonstration, not a confirmed attack.
Four patterns repeat across these incidents. First, the agent obeyed content it should have treated as data, whether an email, an issue, or a poisoned instruction. Second, permissions were broader than the task, so a single bad action reached production data or private repositories. Third, the safeguard was a rule written in a prompt or a policy, such as a code freeze, instead of a limit enforced by the system. Fourth, the agent's instructions and tools were themselves an attack path, as the Amazon Q case shows.
The common thread is that none of these were failures of model intelligence. They were failures of access design. That is why the controls later in this guide start with scoped identities, enforced boundaries, and approval for high-impact actions, and why a prepared AI incident response plan matters for the cases where those controls fail.
AI agent identity and access control means giving each agent its own verifiable identity and only the narrow, temporary permissions its task needs, with a human approving anything high-risk. Done well, a hijacked agent can do very little. Done badly, it inherits whatever access it was handed.
Standards bodies are working on this gap. In February 2026, NIST's National Cybersecurity Center of Excellence published a concept paper that identifies the core problem: existing identity and access management frameworks were designed for human users and static software services, neither of which behaves as AI agents do. It is a proposal for a future project, not a finished standard, but it confirms that conventional IAM needs adapting for agents.
Every AI agent should have its own unique non-human identity, not a borrowed employee login or a shared service account. A distinct identity lets you grant permissions to that agent alone, trace every action back to it, and revoke it without disrupting anything else.
In practice, that means one identity per agent (and ideally per environment), a named human owner, and credentials issued specifically for it. Shared keys make it impossible to tell which agent did what, and they turn one leak into many compromised systems. The NCCoE concept paper proposes applying existing identity standards such as OAuth 2.0, OpenID Connect, and SPIFFE/SPIRE to agents, treating them as distinct non-human identities that need enterprise-grade lifecycle management. It also asks how to bind agent identity with human identity so that human-in-the-loop authorization still works. Treat that link as a requirement: every agent should map to a person or team responsible for it.
Least privilege for agents means granting only the tools, data, and actions a specific task requires, for only as long as the task lasts. OWASP's agentic guidance goes a step further with "least agency": not giving agents more autonomy than the business problem justifies. That covers autonomy as well as permissions.
The related controls are concrete. Create per-tool profiles that restrict permission, data access, and functionality to what is necessary, and enforce task-scoped, time-bound permissions. Make tools read-only by default and put write and delete operations in separately permissioned groups. Issue short-lived tokens at runtime from a secrets manager and expire them when the task ends, so a leaked credential has little value. NIST's concept paper points to standards such as OAuth 2.0, its extensions, and policy-based access control as building blocks. The Replit case from earlier in this guide shows why this matters: a code freeze written as an instruction did nothing, because the agent's permissions were never restricted to match it.
Human-in-the-loop approval means a person must explicitly authorize an agent's irreversible, high-impact, or privilege-raising actions before they run. Examples include deleting data, moving money, changing permissions, deploying code, and sending sensitive data outside the organization. OWASP's guidance recommends requiring human approval for high-risk actions to mitigate elevated privilege misuse.
The approval must be enforced by the system, not requested in a prompt. The Amazon Q payload specifically instructed the assistant to run commands in a non-interactive, trust-all mode that bypasses user confirmations, which is exactly what a prompt-level rule cannot prevent. Show the reviewer the actual action and its parameters, and tier approvals by risk so people are not asked to confirm everything. If every step needs a click, reviewers stop reading.
Zero trust for AI agents means no implicit trust: every request is authenticated and authorized in context, and nothing is trusted because of where it came from or because it was approved earlier. For agents this includes the content they read and the messages other agents send them, both of which should be treated as untrusted.
NIST's concept paper asks how zero-trust principles can be applied to agent authorization and whether policies can update dynamically when an agent's context changes. A practical approach is to put a policy check in front of every tool call, evaluating the agent's identity, the requested action, the data involved, and the current risk, then deny by default. Segment what each agent can reach so one compromise cannot spread, and revoke access automatically when behavior looks abnormal. For the broader model, see our zero trust security.
The core AI agent security controls are guardrails on inputs and outputs, restricted and sandboxed tools, secrets kept outside the agent, complete logging, and a tested way to stop and undo what an agent does. No single control is enough on its own.
OWASP's Top 10 for Agentic Applications 2026, assembled from the peer review of over 100 researchers, engineers, and security practitioners, builds its mitigations on two principles: least agency and observability. Restricting an agent without watching it leaves you blind, and watching it without restricting it only documents the damage.
Guardrails screen what goes into an agent and what comes out, but they are a filter, not a security boundary. Use them to catch obvious problems, and rely on permissions to limit the harm when they miss something.
On the input side, separate trusted instructions from untrusted content such as emails, web pages, and tool results. Researchers analyzing the EchoLeak flaw recommended prompt partitioning, enhanced input and output filtering, provenance-based access control, and strict content security policies. On the output side, block links and auto-loaded images that can carry data out, and scan for sensitive patterns before a response or action leaves the system. Do not depend on detection alone: Invariant Labs reported that many off-the-shelf prompt injection detector defenses fail to catch its GitHub MCP attack, though the company sells competing tooling, so weigh that claim accordingly.
Tool allowlisting means an agent can call only the specific tools approved for its job, and sandboxing means anything it executes runs in an isolated environment. Together they limit what a hijacked agent can reach.
Give each agent an explicit list of approved tools and MCP servers, pin their versions, and review them before connecting, because a tool description is itself an injection point. OWASP's guidance recommends to isolate each agent session, enforce least privilege, and separate code generation from execution. Restrict the destinations an agent can send data to, and apply rate and cost limits so a runaway loop throttles itself.
Keep secrets out of the agent's reach: out of prompts, memory, retrieved documents, and logs. If the model can see a credential, an attacker who manipulates the model can often get it.
The safer pattern is for a gateway or tool wrapper to inject credentials at call time, so the agent requests an action and never holds the key. Store secrets in a managed vault, issue short-lived and narrowly scoped tokens, and rotate them on a schedule. Scan logs and traces for accidentally captured secrets, since debug logging is a common leak path. A token that expires in minutes and can reach one system turns a leak into a minor event.
Agent logging should record enough to reconstruct what the agent did and why: the identity used, the prompt, retrieved sources, each tool call with its parameters, the model version, any human approval, and the output. Without that, you cannot investigate an incident or prove what happened.
NIST's concept project would examine mechanisms for logging and auditing agent activity, which shows how central this is becoming. Watch for signals such as spikes in API usage, unexpected tool chaining, and unusual transaction patterns. Store logs somewhere the agent cannot alter, and tie each entry to the agent's identity and its human owner.
A kill switch is a tested way to halt an agent immediately by revoking its credentials, disabling its tools, and stopping queued actions. Rollback is the ability to restore data and systems to a known-good state. You need both before deployment, because neither can be built during an emergency.
The Replit case shows the cost of skipping them: the agent initially told its user that a rollback was not possible. Keep versioned data and backups, prefer reversible actions, and rehearse the stop procedure. For containment and recovery steps once something goes wrong, see our AI incident response guide.
The table below maps each agent risk to the control that addresses it, who should own that control, and the evidence worth logging. It is an original framework built from this guide, so adapt the owners to your organization.
Risk | Primary control | Typical owner | Evidence to log |
|---|---|---|---|
Indirect prompt injection | Separate untrusted content from instructions; output filtering; limit what injected text can trigger | Application security + AI/ML engineering | Retrieved sources, prompt, blocked inputs and outputs |
Excessive agency | Least privilege; task-scoped, time-bound permissions; read-only default | Platform / IAM team | Permissions granted, scope changes, denied actions |
Tool misuse or malicious MCP server | Tool allowlist, version pinning, vetting, sandboxed execution | AI/ML engineering + security architecture | Tool calls with parameters, tool and server versions |
Memory and context poisoning | Control what can be saved; record origin; allow review and clearing | AI/ML engineering | Memory writes, source of each entry, deletions |
Credential and token leakage | Vaulted secrets; short-lived tokens; call-time injection; rotation | IAM / secrets management | Token issue, use and revocation events; secret-scan results |
Data exfiltration | Outbound destination limits; content filtering; approval for external sends | Security operations + data owner | Outbound requests, data classes touched, destinations |
Multi-agent cascade | Per-agent identity; treat inter-agent messages as untrusted; action limits | Architecture + platform team | Inter-agent messages, delegation chains, action counts |
Destructive or unintended action | Human approval for irreversible actions; backups; kill switch | Service owner + security operations | Approvals, action history, backup and rollback tests |
No single framework covers AI agent security. Use OWASP and MITRE ATLAS to understand the threats, AWS's scoping matrix to classify agents by autonomy, NIST to structure risk and track emerging agent guidance, and ISO/IEC 42001 to certify the governance around it all.
The landscape is moving quickly. A draft Cloud Security Alliance white paper notes that in the twelve months to March 2026, MITRE expanded ATLAS to cover agent-specific attack techniques, NIST launched its AI Agent Standards Initiative, OWASP published a dedicated Top 10 for Agentic Applications, and ISO 42001's certification ecosystem reached commercial maturity. Treat any framework summary, including this one, as a snapshot.
OWASP publishes two relevant lists, and they answer different questions. The OWASP Top 10 for LLM Applications covers risks in how models and the applications built on them behave, such as prompt injection and excessive agency. The OWASP Top 10 for Agentic Applications 2026 focuses on what happens when AI systems act, and OWASP assembled over 100 researchers, engineers, and practitioners to peer-review it.
Its entries include agent goal hijack, tool misuse and exploitation, agentic supply chain vulnerabilities, and memory poisoning. OWASP describes excessive agency from the LLM list as the structural foundation for the agentic risks. The agentic list also rests on two principles: least agency, which limits what an agent may do, and observability, which lets you see what it actually does. Use the LLM list when reviewing the model layer of an application, and the agentic list when threat-modeling and reviewing the design of an agent.
The NIST AI Risk Management Framework is a voluntary, guidance-based framework for managing AI risk. It is not certifiable, and it is general rather than agent-specific, so use it to organize governance and risk decisions, then add agent-level controls on top. For the full framework, see our NIST AI RMF guide.
NIST's agent-specific work sits in a separate effort. On February 17, 2026, the Center for AI Standards and Innovation (CAISI) launched the AI Agent Standards Initiative, organized around three pillars: industry-led standards, community-led open-source protocol development, and research into agent security and identity. Related activity includes a January 2026 request for information on AI agent security and the NCCoE's agent identity and authorization concept paper discussed earlier in this guide. A planned AI Agent Interoperability Profile was reported as expected in late 2026. Third-party summaries I found said no finalized standard had been published, so confirm the current status on NIST's pages before relying on any of it.
The AWS Agentic AI Security Scoping Matrix is a classification framework that sorts agentic systems into four scopes based on human oversight, autonomy, and the level of agency the system is allowed. AWS built it because traditional AI security frameworks do not always extend into the agentic space, and it builds on AWS's earlier Generative AI Security Scoping Matrix.
At Scope 1 an agent has no agency and operates in human-initiated, read-only ways. At Scope 2 a human approves every action. As scopes rise, AWS shifts emphasis from per-action human review to regular auditing, continuous behavioral analysis, and anomaly detection, and it notes that identity management becomes more critical as agents gain breadth and autonomy. A third-party summary describes the practical use as an inventory exercise: assign each agent a scope, then apply the controls that scope calls for. The matrix is a scoping model, not a certifiable standard or a complete control catalog.
MITRE ATLAS is a knowledge base of adversary tactics and techniques against AI systems, structured like MITRE ATT&CK, with each technique linked to mitigations and real-world case studies. In October 2025, MITRE added the first 14 agent-focused techniques and sub-techniques in collaboration with Zenity Labs, and later updates have continued to add agentic coverage. The agent techniques include AI agent context poisoning, modifying agent configuration, RAG credential harvesting, and exfiltration through agent tool invocation. ATLAS is an attacker model, not a fix list, so use it to build threat models and check detection coverage. A draft CSA gap analysis argues that some agentic attack categories are still missing, so supplement it with OWASP.
ISO/IEC 42001:2023, published in December 2023, is the first certifiable management system standard for AI. It audits your AI management system, meaning processes, roles, and controls, not an individual model or product. It is voluntary, technology-neutral, and built on the same structure as ISO 27001, so it can be integrated into an existing management system. It does not prescribe agent-specific technical controls such as sandboxing, so pair it with the frameworks above. For more, see our ISO 42001 guide.
Framework | What it is | Best used for | Certifiable? |
|---|---|---|---|
OWASP Top 10 for LLM Applications | Risk list for models and the apps around them | Model-layer design review | No |
OWASP Top 10 for Agentic Applications | Risk list for AI systems that act | Agent threat modeling and design review | No |
NIST AI RMF | Voluntary AI risk management framework | Organizing AI risk governance | No |
NIST CAISI AI Agent Standards Initiative | Ongoing program on agent security, identity, and interoperability | Tracking upcoming agent guidance | No |
AWS Agentic AI Security Scoping Matrix | Classification model by autonomy and oversight | Scoping controls to each agent | No |
MITRE ATLAS | Adversary tactics and techniques knowledge base | Threat modeling and detection coverage | No |
ISO/IEC 42001 | AI management system standard | Governance and external assurance | Yes (the management system) |
AI agent governance is the set of policies, ownership rules, and approval steps that decide which agents may run, what they may do, and who answers for them. Compliance is the evidence that those controls meet your legal and contractual obligations. The first step in both is knowing which agents you have, and most organizations do not. Agent governance fits naturally inside an existing governance, risk, and compliance (GRC) program.
A Cloud Security Alliance report found that only 21% of organizations maintain a real-time registry or inventory of their agents, and that many cannot map an agent's actions back to a human sponsor. You cannot assign an owner, set a risk tier, or produce audit evidence for an agent you cannot see.
Start with an inventory: a living register of every agent with its purpose, accountable owner, model, tools and MCP connections, data access, credentials, environment, and lifecycle status. This is the register the controls earlier in this guide depend on. Saudi Arabia's draft AI Cybersecurity Guidelines make the same point, asking for an inventory of AI system components with defined owners and lifecycle status. Because surveys keep finding agents that teams did not know about, the inventory needs ongoing discovery, not a one-time spreadsheet. Attack surface management can help surface agents and connections that teams stood up without asking.
Every agent needs a named business owner who is accountable for what it does, and a technical owner who maintains it. That owner is also the human tied to the agent's identity, which is what makes audit and revocation possible.
Then tier each agent by risk. Rank agents by the sensitivity of the data they touch, the impact and reversibility of their actions, and how much autonomy they have. The same draft Saudi guidelines suggest classifying agent actions by impact, likelihood, and reversibility, and the AWS scoping matrix discussed earlier is a useful starting point. A simple version looks like this: Tier 1 for read-only agents on internal, non-sensitive data; Tier 2 for agents that write or send with human approval; Tier 3 for autonomous agents, regulated data, or anything involving money, access changes, or customer records. The tier then sets the review depth, approval requirements, logging detail, and recertification schedule. This tiering is a suggested approach, not a standard, so adapt it to your organization.
An agent policy should state who may build or deploy agents, which data and tools are allowed, how tools and MCP servers are vetted, how long logs are kept, how incidents are reported, and when an agent must be decommissioned. Pair it with your existing information security policy and GRC program so agents are not governed in isolation.
The approval workflow turns the policy into steps. A request enters with a stated purpose and scope, gets a risk tier, and is reviewed by security, privacy or legal, and the data owner. Approval comes with conditions, such as required controls, a named owner, and a review date. After launch, access is recertified periodically, and the draft Saudi guidelines likewise call for periodic review of the identities, access rights, tokens, and service accounts that agents use.
Treat changes as new approvals. A change to an agent's prompt, tools, model, or permissions can alter its risk, and the Amazon Q case showed that agent instructions are part of the supply chain. Record every approval and change, because those records are your compliance evidence. A management system standard such as ISO 42001 or the govern function of the NIST AI RMF can give this workflow its structure.
Most of these regimes do not mention AI agents by name. They apply because an agent is a system that processes data and acts, so the practical task is mapping the same inventory, access, logging, and approval evidence to each regime. For a wider view of regional obligations, see our guide to cybersecurity regulations in the UAE. The table summarizes where each fits, followed by the caveats that matter most.
Regime | Who it applies to | What it means for agents | Caveat |
|---|---|---|---|
UAE PDPL (Federal Decree-Law 45 of 2021) | Organizations processing personal data in the UAE, outside DIFC and ADGM | Covers automated processing and profiling; DPIA before high-risk processing | Executive Regulations reported as not yet issued |
VARA Technology and Information Rulebook (Dubai only) | Licensed virtual asset service providers in Dubai | Agents fall under technology governance, risk assessment, and development and testing controls | No agent-specific rules found |
SIA (UAE Information Assurance Regulation) | Government and critical infrastructure entities | Agents are assets and access paths within the mandatory baseline | Applies only to designated entities |
CBUAE AI guidance note (February 2026) | UAE licensed financial institutions | Governance, transparency, monitoring, and human oversight for AI use | Check whether it is binding for your license |
SAMA and NCA (Saudi Arabia only) | Saudi financial institutions (SAMA); government, critical infrastructure and private sector (NCA) | Existing cybersecurity frameworks apply; NCA draft AI guidelines address agentic AI | Draft guidelines; status disputed |
GDPR | Organizations processing personal data of EU residents | Article 22 limits solely automated decisions; DPIA; erasure reaching memory | Applies regardless of where the agent runs |
SOC 2 (US attestation) | Service organizations seeking customer assurance | Agents are in-scope system components for access, change, and logging evidence | Voluntary; scope is set by the organization |
UAE PDPL. The federal law has been in force since January 2, 2022, and covers automated processing and profiling. Controllers must conduct a DPIA before high-risk processing such as automated decision-making with legal effects, and individuals can object to profiling. Several 2026 sources say the Executive Regulations that set out penalties and procedures have not been issued, so confirm the current position. The federal law does not apply inside DIFC or ADGM, which have their own regimes. For more, see our guide to the UAE data protection law.
VARA (Dubai only). The Technology and Information Rulebook, in its May 19, 2025 version, applies in addition to VARA's other rulebooks. It requires licensed firms to appoint a chief information security officer and to maintain a technology governance and risk assessment framework that covers development, maintenance, and testing of technology systems and prevention of information leakage. An agent that touches client data or trading systems falls within that framework. I found no agent-specific provisions. See our VARA cybersecurity requirements guide, the VARA requirements checklist, and our vCISO for VARA compliance service.
SIA. The UAE Information Assurance Regulation was developed under NESA, which is now the Signals Intelligence Agency. It is mandatory for government entities and critical infrastructure operators, and its controls cover areas such as asset management, access control, third-party security, and incident management. An agent inventory and access model map directly to those controls. Our work with government cybersecurity organizations covers this baseline.
CBUAE. On February 23, 2026, the Central Bank issued a guidance note on the responsible adoption of AI and machine learning by licensed financial institutions. It emphasizes governance and accountability, transparency, continuous monitoring, effective human oversight, and data privacy and security. This is the closest UAE regulator statement to agent governance for financial firms.
SAMA and NCA (Saudi Arabia only). SAMA's Cyber Security Framework covers financial institutions, and the NCA's controls cover government, critical infrastructure, and the broader private sector. In July 2026 the NCA opened draft AI Cybersecurity Guidelines for consultation, closing August 5, 2026. They address both generative and agentic AI and ask for inventories, least-privilege permissions for agents, and logging of tool invocations. Sources disagree on whether they will be mandatory, so confirm their final status.
GDPR. It applies whenever an agent processes personal data of EU residents. Article 22 gives people the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects, and a human cannot merely rubber-stamp an AI output to avoid it. A DPIA is required for that kind of processing, and per-decision logs help you show that genuine review took place.
SOC 2. SOC 2 is a voluntary US attestation, and auditors will treat agents as part of the system in scope. Expect requests for evidence of access control, change management, and logging for agent identities and actions. For how it compares with other attestations, see ISO 27001 vs SOC 2 vs PCI DSS. I did not research state-level US AI laws, so add them if your clients need them. Our compliance services can help map agent controls to the regimes above.
To secure an AI agent, give it its own identity, limit it to the tools and data its task needs, put approvals and guardrails around high-risk actions, log everything it does, and prove you can stop it before it goes live. After launch, keep reviewing its access, activity, and changes on a schedule.
The gap between knowing this and doing it is large. A Kiteworks survey of 459 organizations found that only 26% restrict AI agents to authorized tasks and data scopes, and only 21% can automatically terminate a misbehaving agent's access. The checklist below closes those two gaps first.
Do these steps in order, because each one depends on the one before it. An agent that skips the first three will be hard to secure later, since permissions, logging, and approvals all hang on its identity and tier.
Define the purpose and risk tier. Write down what the agent is for and what it must never do, then assign a tier based on data sensitivity, action impact, and autonomy, as described in the governance section.
Assign an owner and an identity. Name a business owner and a technical owner, and issue the agent its own non-human identity, never a shared account or a person's login.
Scope permissions and tools. Allowlist only the tools and data the task needs, make tools read-only by default, and use short-lived, narrowly scoped credentials.
Threat-model the design. Walk the agent's inputs, tools, memory, and outputs against the OWASP agentic risks and the relevant MITRE ATLAS techniques, and record which risks apply.
Keep secrets out of the agent. Store credentials in a vault and inject them at call time, so the model and its logs never hold them.
Separate environments. Give the agent a development or staging copy, not production access, and run any code it executes in a sandbox.
Add guardrails and approvals. Filter untrusted inputs and risky outputs, and enforce human approval in the system for irreversible, high-impact, or privilege-raising actions.
Build logging in from the start. Capture the agent's identity, prompts, retrieved sources, tool calls with parameters, model version, approvals, and outputs, stored where the agent cannot alter them.
Prove the kill switch and rollback. Test that you can revoke the agent's credentials, disable its tools, and restore data, before launch and not during an incident.
Complete the privacy and compliance review. Run a DPIA where personal data is involved, and confirm which of the regimes covered earlier apply.
Test adversarially and get sign-off. Have the design challenged by someone who did not build it, for example through a security assessment such as our AI agentic pentesting, and record the approval against the agent's tier. Understanding the difference between red teaming and penetration testing helps you choose the right depth of testing.
An agent that was safe on launch day can drift as prompts, tools, models, and data change. Production security is a set of recurring jobs, and the cadence should rise with the agent's tier.
Monitor continuously. Watch for spikes in API usage, unexpected tool chaining, unusual data transfers, and actions outside the agent's declared purpose.
Review logs and approvals. Sample agent activity and human approvals on a schedule, and look for approvals that are always granted without reading.
Recertify access. Periodically re-check each agent's identity, permissions, tokens, and the owner who is accountable for it, and remove what is no longer needed.
Rotate secrets. Rotate credentials on a schedule and immediately after any suspected exposure.
Control change. Treat a change to the agent's prompt, tools, model, or permissions as a new approval, and re-tier the agent if its capabilities grew.
Maintain the supply chain. Pin and review tool and MCP server versions, and update them deliberately instead of automatically.
Practice the stop. Rehearse the kill switch and rollback regularly, and keep your AI incident response plan current.
Decommission cleanly. When an agent is retired, revoke its identity, delete its credentials, clear or archive its memory, and remove it from the inventory.
Use the checklist below to test whether an agent is ready, and the maturity levels to place your overall program. Both are original frameworks built from this guide, not an industry standard, so adjust them to your environment.
The agent is in the inventory with a named business owner and technical owner.
It has its own identity and no shared or hardcoded credentials.
It has a risk tier, and the controls match that tier.
Its tools and data access are allowlisted and limited to the task.
Credentials are short-lived, vaulted, and injected at call time.
High-risk actions require system-enforced human approval.
Logs capture prompts, tool calls, approvals, and outputs, and the agent cannot edit them.
It runs in a sandbox, with development separated from production.
The kill switch and rollback were tested within the last review cycle.
Privacy, compliance, and adversarial reviews are complete and recorded.
Level | Name | What it looks like |
|---|---|---|
1 | Ad hoc | Agents are built by individual teams with shared keys, no inventory, and no approval step |
2 | Defined | A policy and inventory exist, owners are named, and agents get their own identities |
3 | Managed | Risk tiers drive controls, approvals are enforced, logging is complete, and access is recertified |
4 | Optimized | Discovery, monitoring, and revocation are automated, drills are routine, and results feed back into policy |
Most organizations will find different agents sit at different levels. Prioritize raising the highest-tier agents first, and treat Level 3 as the target for anything that touches regulated data, money, or production systems.
The most common AI agent security mistakes are basic hygiene failures applied to a new kind of system: sharing credentials, treating content as commands, not knowing which agents exist, and not recording what agents actually do. Each one is cheap to fix before an incident and expensive to discover after one.
Sharing one API key across several agents, or hardcoding it in code, prompts, or configuration, means a single leak exposes everything the key can reach, and no one can tell which agent used it. The habit persists because it is convenient: in 1Password's 2026 survey, 40% of developers said they grant agents persistent access to systems and secrets that stays live after the task that needed it has finished.
The fix is to give each agent its own identity, keep secrets in a vault, and inject short-lived, narrowly scoped credentials at call time so the model never holds them. Rotate on a schedule, and scan repositories, prompts, and logs for secrets that slipped in. A leaked key that expires in minutes and reaches one system is a minor event; a shared long-lived key is a breach.
This mistake treats anything an agent reads, such as a tool result, web page, email, or issue, as safe to obey. Agents cannot reliably tell data from commands, so attackers hide instructions inside the content. The EchoLeak flaw in Microsoft 365 Copilot worked this way: a crafted email processed by the retrieval engine could trigger data exfiltration with no user action. In the GitHub MCP demonstration, a malicious issue in a public repository led an agent to pull private repository data into a public pull request.
Treat every piece of retrieved content as untrusted data. Keep it separate from trusted instructions, filter what leaves the system, and limit what an injected instruction could trigger by scoping permissions and requiring approval for high-impact actions. A line in the prompt telling the agent to ignore instructions in documents is not a control, because the same weakness lets an attacker override it.
Running agents without an inventory means you cannot assign owners, set risk tiers, review access, or retire anything, and agents built by individual teams stay invisible until something goes wrong. Orphaned agents keep live credentials after their projects end, and during an incident no one can say which agents were exposed.
Register every agent when it is created, and make a registry entry a requirement for deployment. Add ongoing discovery across cloud accounts, SaaS tools, code repositories, and MCP connections, because teams can build and connect agents without asking. Reconcile the registry with what discovery finds on a regular schedule, and see our guide to external attack surface management for how discovery works in practice. For the full approach, see the governance section above.
Logging only an agent's final answer or chat transcript records what it said, not what it did. The consequential actions happen in tool calls, and an agent's own explanation can be wrong. In the Replit case, the agent reportedly misdescribed what had happened and told its user that a rollback was not possible, so its text was a poor record of events.
Log the agent's identity, the prompt, retrieved sources, each tool call with its parameters and result, any human approval, and the model version. Store the records somewhere the agent cannot change them, and keep them long enough, since a poisoned memory entry can cause behavior weeks after the original event and a short retention window may erase the cause. Saudi Arabia's draft AI Cybersecurity Guidelines likewise ask for logging of tool invocations. These records are also what your AI incident response team will need.
AI agent security does not need a big program to start. Pick the one agent that can do the most damage, such as the one that touches production data, money, or customer records. Find out who owns it, what it can reach, and whether you could shut it off right now. If any of those answers is "I don't know," that is your first task, and fixing it will do more than adding another filter.
Once the basics hold, test them the way an attacker would. Femto Security's AI agentic pentesting service puts your agents through realistic attack scenarios, so you find the weak points before someone else does. Book an AI agent security assessment to get started.
AI agent security is the practice of protecting autonomous AI systems, and the identities, tools, memory, and data they use, from manipulation, excessive permissions, and misuse. It focuses on limiting what an agent can do and recording what it does, so that a compromised or mistaken agent cannot cause serious harm.
LLM security protects the model and the application around it, focusing on risks such as prompt injection and data leakage. AI agent security adds protection for what the agent can do: its credentials, tools, memory, and actions. A compromised chatbot gives a bad answer, while a compromised agent can change real systems.
The biggest risks are prompt injection through content the agent reads, excessive permissions, malicious or misused tools, memory poisoning, leaked credentials, data exfiltration, and failures that spread between agents. In a SailPoint survey, 80% of organizations said their agents had already taken unintended actions, so these risks are already occurring in practice.
Give the agent its own identity, limit it to the tools and data its task needs, and use short-lived credentials kept in a vault. Add guardrails and human approval for high-risk actions, run it in a sandbox, log every tool call, and test a kill switch and rollback before launch.
Excessive agency means an agent has more functionality, permissions, or autonomy than its task requires, so any mistake or manipulation has a larger blast radius. OWASP lists it as a top risk for LLM applications. The fix is least privilege: scope each agent to the specific tools and data it needs.
No single framework covers it all. Use the OWASP Top 10 for Agentic Applications and MITRE ATLAS to understand threats, the AWS Agentic AI Security Scoping Matrix to classify agents, NIST's AI RMF and AI Agent Standards Initiative for risk and emerging guidance, and ISO/IEC 42001 for certifiable governance.
Yes. Each agent should have its own non-human identity, not a shared account or a person's login. That lets you grant it narrow permissions, trace every action to it, and revoke it without disrupting anything else. NIST has noted that existing identity frameworks were designed for human users and static software, not autonomous agents.