An AI agent that triages a support ticket can be told, by text hidden inside that ticket, to look up a customer’s records and send them somewhere else. OWASP notes that agents and their models cannot reliably tell instructions apart from the content they process, so agentic AI security (agentic security, for short) puts its controls outside the model.
What is agentic AI security?
Agentic AI security is the practice of keeping AI agents, programs that choose their next step and act through tools, within the access and actions their owners intended. It treats every decision the model makes as untrusted and enforces limits outside the model: on the identity the agent runs with, on the tools and data it can reach, and on each request it sends.
Four parts make up an agentic AI system, and each adds attack surface: a model that makes decisions, tools that turn them into actions on external systems (APIs, a shell, MCP servers, a browser), memory that carries context between steps and sessions, and an identity that decides what those actions can reach. Autonomy chains them together without a person approving each step.
Coding and cloud agents act mostly through network requests to LLM providers, code hosts, databases and SaaS APIs. That is why AI agent security for those agents often starts at the egress, where each request can be checked before it lands.
How is agentic AI security different from LLM security?
LLM security is about one model call: what goes into the prompt and what comes out. Agentic AI security adds what happens next, because the output of an agent is an action, such as a SQL query, a git push, an MCP tool call or an email. OWASP maps several agentic threats to its LLM Top 10, for example tool misuse to excessive agency, and adds a principle it calls least agency: don’t give a system autonomy it doesn’t need.
Here’s what changes in practice:
- What goes wrong. A chatbot that fails gives a bad answer. An agent that fails takes unauthorized actions: it deletes rows, pushes a commit or sends a customer list.
- Who writes the input. Anyone whose text the agent reads: a web page, a ticket, a tool result, an MCP tool description, another agent. Attackers use indirect prompt injection to plant malicious instructions there.
- How long the harm lasts. Memory keeps a poisoned instruction across sessions, and a multi-step plan turns one bad decision into many actions.
- Where controls hold. Prompt filters, input validation and model alignment lower the odds of a bad decision. Limits on identity, tools and the network path still hold when one happens.
Traditional application security assumed the code decides what happens next. In an agentic system the model’s outputs do, so treat the agent like an untrusted user with a fast keyboard and put access control where it would sit for that user.
What are the biggest agentic AI security risks?
OWASP’s Gen AI Security Project is the most widely used reference. It publishes a ranked Top 10 for practitioners and, underneath it, the longer threat taxonomy the Top 10 maps to. Both describe the same shift: the risk is no longer a bad output but an autonomous action taken with real permissions.
The OWASP Agentic AI Top 10 (2026)
The OWASP Top 10 for Agentic Applications for 2026, published December 9, 2025, lists these risks:
- ASI01 Agent Goal Hijack. Content the agent reads, usually through indirect prompt injection, changes what it is trying to achieve, and it pursues the attacker’s goal with its own permissions.
- ASI02 Tool Misuse and Exploitation. The agent uses a tool it is allowed to use in a way nobody intended: deleting data, calling a costly API in a loop, sending data out.
- ASI03 Identity and Privilege Abuse. Delegated sessions, cached keys or another agent’s trust let the agent reach more than its task needs.
- ASI04 Agentic Supply Chain Vulnerabilities. A tool, MCP server, prompt template or plugin the agent loads at runtime is malicious or compromised at its source.
- ASI05 Unexpected Code Execution (RCE). Generated or injected code runs on the host, from a shell command to an unsafe eval or a poisoned dependency.
- ASI06 Memory & Context Poisoning. False or malicious data written into memory, a RAG store or shared context steers later sessions.
- ASI07 Insecure Inter-Agent Communication. Agent-to-agent messages are spoofed, replayed or altered in transit.
- ASI08 Cascading Failures. One fault spreads through planners, executors and peer agents faster than a person can step in.
- ASI09 Human-Agent Trust Exploitation. The agent persuades a person to approve or perform the harmful step, so the logs show a human action.
- ASI10 Rogue Agents. An autonomous agent drifts from its intended goal without an active attacker, for example by gaming its objective.
Where can each risk be contained?
Not every risk can be stopped at the same layer. The middle column is our reading of the OWASP mitigations for each entry: the control point outside the agent that does most of the work.
| OWASP risk | Where to contain it (our reading of the OWASP mitigations) | OWASP mitigations it draws on |
|---|---|---|
| ASI01 Agent Goal Hijack | Tool scope and human approval: a hijacked goal still acts through the agent’s permissions | Least privilege for agent tools; human approval for high-impact actions |
| ASI02 Tool Misuse and Exploitation | Network path and a policy point: outbound allowlists, checks on each call, short-lived credentials | Execution Sandboxes and Egress Controls; Policy Enforcement Middleware |
| ASI03 Identity and Privilege Abuse | Identity: a distinct, short-lived identity per agent session, checked again on each privileged step | Task-scoped, time-bound permissions; per-action authorization |
| ASI04 Agentic Supply Chain Vulnerabilities | Tool approval: an allowlist of MCP servers, tools and skills, with pinned versions | Dependency gatekeeping; pinning |
| ASI05 Unexpected Code Execution (RCE) | A host sandbox plus the network path: code may run, but what it reaches stays limited | Execution environment security; access control and approvals |
| ASI06 Memory & Context Poisoning | Mostly inside the agent’s own stack: validate, segment and expire memory. A network control can’t judge whether stored content is true | Content validation; memory segmentation; expiry of unverified memory |
| ASI07 Insecure Inter-Agent Communication | Transport and identity: mutual authentication and signed messages between agents | Secure agent channels; message integrity |
| ASI08 Cascading Failures | A policy point outside the planner, plus rate limits that pause runaway loops | Independent policy enforcement; rate limiting and monitoring |
| ASI09 Human-Agent Trust Exploitation | Mostly the human interface: confirmations, previews without side effects, and logs of what the agent suggested | Explicit confirmations; separate preview from effect; immutable logs |
| ASI10 Rogue Agents | Containment: a per-agent identity you can revoke, a kill switch, signed audit logs | Containment and response; governance and logging |
Read across the rows: eight of the ten risks can be narrowed by controls that never inspect the prompt, namely identity, tool scope, the network path, approvals and logs. Memory poisoning and human trust exploitation mostly need work inside the agent and at the human interface. Be skeptical of any single control presented as covering all ten.
The OWASP agentic AI threat model (T1 to T17)
Agentic AI - Threats and Mitigations was the first guide from the OWASP Agentic Security Initiative, published February 17, 2025, and updated to version 1.1 in December 2025. The Top 10 relies on it (ASI01 corresponds to T6 and T7, ASI02 to T2). Its 17 agentic AI threats, grouped here by what they target:
- The agent’s reasoning and memory: T1 Memory Poisoning, T5 Cascading Hallucination Attacks, T6 Intent Breaking & Goal Manipulation, T7 Misaligned & Deceptive Behaviors.
- Tools, code and resources: T2 Tool Misuse, T4 Resource Overload, T11 Unexpected RCE and Code Attacks.
- Identity and accountability: T3 Privilege Compromise, T8 Repudiation & Untraceability, T9 Identity Spoofing & Impersonation / Agent Identity Compromise.
- The humans in the loop: T10 Overwhelming Human in the Loop, T15 Human Manipulation.
- Multi-agent systems and protocols: T12 Agent Communication Poisoning, T13 Rogue Agents in Multi-Agent Systems, T14 Human Attacks on Multi-Agent Systems, T16 Insecure Inter-Agent Protocol Abuse.
- Supply chain: T17 Supply Chain Compromise.
Use the Top 10 to prioritize and the full list to check coverage. A single coding agent on a laptop can set the multi-agent threats aside until it grows into a system of agents.
What is an agentic AI security framework?
An agentic AI security framework is a structured list of threats and controls that you map your agents against, so coverage doesn’t depend on what one engineer remembers. The OWASP Agentic Security Initiative is the most specific today: besides the two documents above, it publishes a threat modelling guide, guidance on securing agentic applications, and a report on agentic AI security and governance.
NIST covers AI risk more broadly. Its AI Risk Management Framework (January 2023, now under revision) is voluntary and applies to any AI system. On January 12, 2026, NIST’s Center for AI Standards and Innovation (CAISI) published a request for information about securing AI agent systems; its topics include “methods to constrain and monitor the extent of agent access in the deployment environment”, which is where the controls below sit.
To apply a framework to real agents:
- Inventory every agent: who runs it, where (laptop, cloud VM, Kubernetes), with which identity, tools and data.
- Map each agent to the OWASP risks that apply. A read-only reporting agent and a coding agent with shell access have very different lists.
- Assign each risk a control point and an owner, starting from the table above.
- Test and repeat. Red-team for goal hijack and tool misuse, as OWASP recommends, and redo the map whenever an agent gains a tool, a data source or a new workflow.
Securing agentic AI: controls outside the model
These agentic AI security best practices don’t rely on the model behaving. Each one still limits damage after the agent has been steered by content it read, which is the case to design for.
Give each agent its own short-lived identity, tied to a person
Cloud agent platforms issue short-lived OIDC tokens to each agent session. Exchanged for a session at the enforcement point, the token names the agent and the person who started it, so the audit log shows which human each agent action belongs to instead of a shared service account. The OIDC approach for cloud agents also removes the long-lived secret from the agent’s environment.
OWASP calls the alternative an attribution gap: an agent without a governed identity of its own, running on identity and access systems built for people, can’t be held to least privilege.
Grant least privilege, just in time
Start every agent with no standing access to sensitive systems. When a task needs data access, a repository or a cloud role, the agent requests it with a reason and a duration, a person approves, and the grant expires with the session. Just-in-time access works the same way for agents as for engineers, except that the agent can request but never approve.
Scope tool access as tightly: an agent that reads one table doesn’t need a role that can drop it. Per-tool scopes keep a misused tool from becoming a misused account and cap privilege escalation when an agent chains tools.
Keep credentials out of the agent
Credential injection removes the secret from the agent’s environment. The agent sends its request without a key, and a proxy on the path checks the caller’s identity and policy, then adds the real credential before forwarding upstream. A prompt-injected agent can’t leak a key it never received.
OWASP’s tool misuse guidance points the same way: a policy enforcement point in front of tools that issues short-lived credentials. The Stripe API key guide shows the pattern for one API.
Control egress at the request, not just the domain
Domain allowlists for agent egress answer one question, which hosts the agent may open a connection to. The harder question is what it does once connected, because a code host or an LLM provider takes writes as readily as reads. Answering it takes an egress proxy that terminates TLS on the flows you choose, reads the protocol inside (HTTP, MCP, an LLM API, git over SSH) and checks each request.
Here’s the catch with git: it reaches GitHub over HTTPS, over SSH and over SSH on port 443. Block pushes on one transport and the agent can switch the remote URL, so the control has to cover all three.
Check each request against policy
A policy decision point sees who is asking (the agent and its human), which resource, which action and which arguments, and returns allow, deny or ask a person. Checking every request at the trust boundary, not only the first connection, matters for agents: a session that starts with reads can turn to writes ten calls later. On databases and servers, this per-query check is the inner layer of privileged access management.
Keep a human on irreversible actions
Human oversight works when it is rare. OWASP lists Overwhelming Human in the Loop (T10) as a threat of its own: approvers who see a prompt on every step stop reading. Reserve approval for high-risk actions that can’t be undone, such as merging to a protected branch, deleting data, moving money or changing permissions. The approver is the person accountable for the agent, and the agent never approves itself.
Log every action against a person
Repudiation & Untraceability (T8) is the threat that nobody can say which agent did what, on whose behalf. Record each action at the enforcement point with the agent session, the person behind it, the request and the policy decision, not only what the agent reports about itself. The same logs make anomalous agent behavior, such as a read followed by an outbound transfer, visible in real time.
Approve tools and MCP servers before agents use them
Agentic supply chain risk (ASI04) starts with third-party tools nobody reviewed. Keep a list of approved MCP servers, skills and AI tools, decide who can use each, and detect the rest. Shadow AI detection covers how teams find the servers and AI clients already in use.
Agentic security for coding agents
Coding agents run in an engineer’s shell, with that engineer’s tokens, SSH keys and cloud CLI sessions. Allowlisting commands rarely holds: approving a few developer tools can amount to approving any command, because build tools run arbitrary code. Agentic security for coding agents works better at the sandbox and network layer, which is how the Claude Code integration works: it limits where the agent connects, holds API keys away from the machine and logs each request per developer.
Agentic security for MCP servers and tools
The Model Context Protocol (MCP) gives agents a standard way to call tools, and a standard place to attack them: OWASP names MCP in T16 Insecure Inter-Agent Protocol Abuse and notes that tool definitions increasingly arrive through MCP servers. Agentic security for MCP means approved servers, permissions per tool and per user, and a log of every tool call. An MCP gateway enforces that in one place; the permission pitfall of MCP explains why server permissions aren’t enough.
How does Formal approach agentic AI security?
Formal enforces these controls on the network path, outside the agent. Formal Endpoint runs on macOS and Linux laptops and on cloud agent VMs. In Transparent Mode it intercepts selected traffic without client changes, terminates TLS with a Formal local CA, and applies logging and policy. Network rules written in CEL select flows by process, hostname, user, group and protocol, and on macOS they recognize known agents by code signature, including the processes those agents spawn.
When a request needs a secret, a Formal Connector holds it: a Native User injects the credential, so the laptop or agent sandbox never sees it. Cursor and Devin cloud agents authenticate with OIDC tokens that their platform mints per session, exchanged for a Formal machine session, and each action maps to the human who ran the agent. Documented policies stop agents from pushing to sensitive repositories over either SSH or HTTPS, or pause the push for MFA, and stop cloud agents from enabling GitHub auto-merge.
The same platform governs the AI tools themselves: the Catalog lists the MCP servers and skills you approved, Shadow AI surfaces the ones outside it, Guardrails decide what happens to those, and Access Requests handle exceptions. LLM requests go through the AI gateway, where prompts, responses and tool calls are logged against a person.
Cursor applies the same pattern to agents that need sensitive data in its ML environments:
“Without Formal, we couldn’t have agents with access to sensitive data. With Formal, because we are able to inspect all traffic and enforce controls, we are able to provide a safe environment for the agents to get the job done.”
— Travis McPeak, Head of Security @ Cursor
Formal doesn’t detect or prevent prompt injection inside the model. Its job is to narrow what a compromised agent can reach and send, and to keep a record of each attempt. If you want to see these controls on your own agents, request a walkthrough.