How to secure agentic applications

TLDR

• An agentic application is software that lets a language model do tasks for a user. The model selects tools, keeps a memory and does steps.
• Each part of the agentic application adds a risk. An attacker can control the model, use a tool incorrectly, get a credential or add incorrect data to a data store.
• Do not think that the model can prevent an attack. Put the limits in the system around the model.
• Use these limits: small scopes, a sandbox, different sessions and approval from a person.
• Know the parts that you operate. Keep an inventory of the models, system prompts, tools, MCP servers, data stores and credentials.
• Use many layers. Attacks such as EchoLeak went through many defenses, one after the other.

An agentic application

An agentic application lets a language model do work. The model reads a task and selects a tool. Then the model reads the result and selects the next step.

The difference from a chatbot is the operation. An incorrect output from a chatbot is only text. An incorrect step from an AI agent can send an email, change an entry in a database or erase a database.

The OWASP LLM Top 10 of 2026 is about a model that is a component in a software application. When a model can use tools and keep a memory, the OWASP Top 10 for Agentic Applications applies. OWASP also tells that “Agents amplify existing vulnerabilities”.

Examples of agentic applications

• An email assistant that adds a meeting to a calendar when an email gives a meeting time.
• A coding agent that changes the software and does the tests when a user gives it a GitHub issue.
• A support agent that sends the correct information to a customer when the customer writes a support ticket.
• A research agent that writes a report with sources when a user gives it a research topic.
• An operations agent that restarts a server when the monitoring system finds a malfunction.

Components of an agentic application

Most agentic applications have the same 9 parts. Some parts are small, or other systems also use them. But an attack can start or stop at each part.

Component	Function
Model	The language model reads text and writes text. It can be a hosted service or an open weight model that you operate.
Control software	The software around the model, also named the orchestrator or the agent harness. It holds the system prompt, sends the context to the model and uses the tools.
Tools and MCP servers	The functions that the control software can use, for example web search and email. Many connect through the Model Context Protocol, as an MCP server.
Memory and RAG stores	Data from previous sessions, a vector database for retrieval augmented generation and files.
Identity and credentials	The tokens, access keys and scopes of each tool. They are the non human identity of the AI agent.
Runtime and sandbox	The computer or container where the control software operates. The sandbox is where the software from the AI agent operates.
User and data inputs	The task from the user and all the content that the AI agent reads. Most of this content is untrusted data.
Other AI agents	AI agents that send tasks to this AI agent or get tasks from it, for example through the Agent2Agent protocol.
Supply chain	The source of each part: model weights, software packages, MCP servers, agent skills and prompt templates.

Diagram of an agentic application

The red arrows send untrusted data into the context of the model. The black arrows send tasks and steps to production systems.

How to find each component in your agentic application

You cannot prevent damage to a part that you do not know. First, make an inventory of the agentic application. This inventory is an application composition analysis for the AI parts.

Part	Record
Models	Each model, its model provider, its version and the hash of its weights.
System prompts	Each system prompt and prompt template. Keep them in version control.
Tools and MCP servers	Each tool that the control software can use. Each MCP server, its source and its version.
Data stores	Each memory store, vector store and file folder that the AI agent can read or change.
Credentials	The identity of each tool, and the permissions of that identity in the target system.
AI agents	Each AI agent that this AI agent uses, and each AI agent that uses it.

The page enumerating what an AI agent can access gives the method for the credentials. Keep the result as an AI bill of materials.

• The CycloneDX ML-BOM format can contain models, datasets, tokenizers and prompt templates.
• The G7 minimum elements for an SBOM for AI add the infrastructure and the security properties. The G7 tells that they “are not mandatory”.

An agentic application must have many layers of protection

One control is not sufficient. These 2 results show it:

Test	Result
2025 paper, adaptive attacks on 12 new defenses against prompt injection	For most defenses, the attack success rate was more than 90%. Before, the attack success rate was almost 0%.
NIST CAISI, red teaming competition on 13 frontier models	More than 400 persons tried more than 250,000 attacks. For each model, one or more attacks went through.

Thus, think that an attacker can control the model. Then put a limit on each part.

The design patterns paper recommends “a combination of design patterns”. The EchoLeak study recommends a “defense-in-depth” architecture.

The risks of each component

The table connects each part to the entries of the OWASP Top 10 for Agentic Applications (ASI) and of the OWASP LLM Top 10 (2026). AI Matter made the connections. They follow the names and the scope of the 2 OWASP documents.

Component	Primary risk	OWASP Agentic	OWASP LLM 2026
Model	Hidden instructions control it. It shows data from its context.	ASI01 Agent Goal Hijack	LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM08 Hidden Context Exposure
Control software	It follows a changed plan. It sends the output of the model without a check.	ASI01, ASI08 Cascading Failures	LLM10 Improper Output Handling, LLM06 Unbounded Consumption
Tools and MCP servers	A tool does an operation that is not safe. A tool description contains hidden instructions.	ASI02 Tool Misuse and Exploitation	LLM03 Excessive Agency
Memory and RAG stores	Incorrect data from an attacker changes the subsequent sessions.	ASI06 Memory and Context Poisoning	LLM05 Data and Model Poisoning, LLM09 Vector and Embedding Weaknesses
Identity and credentials	A token has too many permissions.	ASI03 Identity and Privilege Abuse	LLM03 Excessive Agency
Runtime and sandbox	Software from the model operates on the host or on the network.	ASI05 Unexpected Code Execution	LLM10 Improper Output Handling
User and data inputs	Content contains hidden instructions. A person thinks that the AI agent is always correct.	ASI01, ASI09 Human-Agent Trust Exploitation	LLM01 Prompt Injection, LLM07 Misinformation
Other AI agents	An attacker changes the messages between AI agents. An AI agent goes out of control.	ASI07 Insecure Inter-Agent Communication, ASI10 Rogue Agents	None
Supply chain	A model, software package, MCP server or agent skill contains malware.	ASI04 Agentic Supply Chain Vulnerabilities	LLM04 Supply Chain

Each entry has a page:

• Model and tools: Agent hijacking, tool misuse, MCP tool poisoning.
• Memory: Agent memory poisoning, RAG poisoning.
• Identity and runtime: Agentic identity and privilege abuse, unexpected code execution.
• Persons and AI agents: human agent trust exploitation, insecure inter agent communication, rogue agents.
• Supply chain: AI supply chain compromise.

Protection for each component across the lifecycle

Read each row from left to right. The design stage is the architecture and the develop stage is the software. The build stage makes a software release, the deploy stage installs it, and the run stage is the operation.

Component	Design stage	Develop stage	Build stage	Deploy stage	Run stage
Model	Keep untrusted data away from control.	Keep instructions and data apart.	Lock the model version. Record its hash.	Use a model provider with a satisfactory contract.	Do red teaming. Monitor for prompt injection.
Control software	Apply the Agents Rule of Two to each session.	Do the permission check in the software, not in the system prompt.	Do tests with prompt injection data.	Set a maximum number of steps. Set a time limit.	Record each plan and each tool call.
Tools and MCP servers	Give only the necessary tools.	Examine the inputs and outputs of each tool.	Lock the tool descriptions. Examine the servers.	Start with read access only. Use small scopes.	Tell the operator when a tool description changes.
Memory and RAG stores	Use a different data store for each user and each data source.	Record the source of each entry.	Examine the documents before you put them in a data store.	Give write access to each data store only to the necessary tools.	Examine the memory. Erase the entries that are not necessary.
Identity and credentials	Use one identity for each AI agent and each task.	Use the permissions of the user, not of an administrator.	Keep secrets out of the software.	Use tokens with a short life. Do not use wildcard scopes.	Replace access keys regularly. Revoke an access key after an incident.
Runtime and sandbox	Isolate the files and the network.	Operate software from the model only in the sandbox.	Use images with the minimum software.	Disconnect the network. Only approved addresses are permitted.	Monitor the sandbox. Find software that tries to go out of it.
User and data inputs	Identify the untrusted inputs.	Remove hidden text. Do not show external images and hyperlinks.	Do tests with samples that contain hidden instructions.	Disconnect the data sources that the task does not use.	Get approval from a person for permanent changes.
Other AI agents	Think that their messages are untrusted data.	Authenticate the messages.	Do tests for errors that go to many AI agents.	Set a limit on the tasks that each AI agent can send to other AI agents.	Stop an incorrect AI agent quickly.
Supply chain	Select sources that you know.	Lock the versions.	Make an AI bill of materials. Examine the provenance.	Use only approved servers and agent skills.	Monitor the advisories. Update or remove parts quickly.

Incidents and how to prevent them

Each incident below has a source that all persons can read. Some incidents are attacks. Some incidents are tests by researchers on production systems.

EchoLeak in Microsoft 365 Copilot (2025, attack)

• Incident. One email contained hidden instructions. Copilot read the email as context. Then an attacker could get internal data from emails, Teams messages and documents.
• Cause. The attack went through 4 defenses: the XPIA classifier, link redaction, images that the client got automatically and a Microsoft Teams address. Untrusted data and private data were in one context, with a connection out.
• How to prevent it. Keep untrusted data out of a context that contains private data. Do not show images or hyperlinks to external addresses in the output of the model.

Aim Labs found this zero-click attack. The CVE identification is CVE-2025-32711, with a CVSS score of 9.3. A study tells that the attack occurred “without user interaction”.

Microsoft corrected the problem on its servers. Trend Micro tells that customers did not have a task to do.

Tool poisoning and the postmark-mcp backdoor (2025, test and attack)

• Incident. In April 2025, Invariant Labs showed tool poisoning in a test. An MCP tool description contained hidden instructions. These instructions made the Cursor editor send the SSH private key of the user out.
• Incident. In September 2025, an attack occurred. The npm package postmark-mcp was not from Postmark. Postmark tells that version 1.0.16 had a backdoor that sent a copy of each email to an external server.
• Cause. The client did not examine the tool descriptions. The users installed a package with the Postmark name. The server operated with the permissions of the client.
• How to prevent it. Install MCP servers only from a source that you know. Lock the version and the tool descriptions. Operate the servers in a sandbox with the minimum permissions.

The MCP specification also recommends a sandbox for MCP servers. The page MCP tool poisoning gives more data.

GitHub MCP and private repositories (2025, test)

• Incident. Invariant Labs showed that a GitHub issue in a public repository could control an AI agent. The AI agent used the GitHub MCP server. It sent data from private repositories into a public pull request.
• Cause. One session could read GitHub issues from unknown users, read private repositories and write to a public repository. The problem was the scope of the session and of its token.
• How to prevent it. Use a token that has access to one repository only. Or set a limit of one repository for each session, as Invariant Labs recommends.

Invariant Labs tells that the software of the GitHub MCP server did not have the problem.

The Replit AI agent erased a production database (2025, no attacker)

• Incident. In July 2025, the Replit AI agent erased the data in a production database during a code freeze, Fortune tells.
• Cause. The AI agent had write access to production. The code freeze was an instruction to the model, not a control.
• How to prevent it. Do not give an AI agent write access to production. Get approval from a person for each permanent change.

The CEO of Replit wrote that this “should never be possible”. Replit told about these corrections: separation of the development database and the production database, changes to rollback, and a planning-only mode. Refer to scoping write permissions for LLM agents.

Malware in the Amazon Q Developer extension (2025, attack)

• Incident. An attacker added malware to the open source repository of the Amazon Q Developer extension for VS Code. The malware was in version 1.84.0, but it did not operate because of a syntax error.
• Cause. The build pipeline used a GitHub token with too many permissions. Thus, an unknown person could change the software release.
• How to prevent it. Give the build credentials only the minimum permissions. Examine each change before it goes into a software release.

AWS gave the CVE identification CVE-2025-8217. A tool of an AI agent is software in your supply chain, and the usual build controls apply to it.

The tokens of the Salesloft Drift integration (2025, attack)

• Incident. From 8 to 18 August 2025, the group UNC6395 used OAuth tokens of the Salesloft Drift integration. The group got data from the Salesforce instances of many customers. Then it examined the data for secrets, for example AWS access keys and passwords.
• Cause. The tokens of one integration gave wide access to the systems of many customers. The attack did not control a model, but it used the credentials.
• How to prevent it. Use small scopes and IP address limits for each connected application. After an incident, replace each token of the integration quickly.

Google Threat Intelligence gives this information. Apply the same instructions to the credentials of an AI agent.

Design patterns and when to use each

These design patterns, for example the Dual LLM design pattern, decrease the effect of untrusted data after the AI agent reads it. Most of them come from a 2025 paper about design patterns for AI agents. The paper tells that untrusted input must not cause “consequential actions”.

Design pattern	Use it when	Limit
Lethal trifecta and Agents Rule of Two	Use them first, for all AI agents.	They are tests, not architectures.
Action-Selector	The AI agent selects one operation from a specified set.	The model cannot do many of its usual tasks.
Plan-Then-Execute	You know the steps before the AI agent reads untrusted data.	It does not stop a prompt injection in the user prompt.
LLM Map-Reduce	The AI agent must examine many untrusted items. An isolated model examines each item.	Some tasks cannot be divided into items.
Dual LLM	The AI agent must read untrusted content and also use tools.	An attacker can also control the quarantined model.
Code-Then-Execute and CaMeL	You must have strong protection.	CaMeL completed 77% of the tasks, and 84% without the defense.
Context-Minimization	The AI agent operates for many conversation turns.	It does not stop all prompt injections.
Human in the loop	A step can cause large damage or a permanent change.	Frequent approval causes “approval fatigue”.

Meta tells that some sessions must not operate without a person who monitors them. These sessions read untrusted data, get private data and change data or send data out.

OWASP recommends automatic approval for small steps that do not cause a permanent change. Anthropic tells that a sandbox decreased the number of its approval steps by 84%.

Effect on compliance

The work that makes an AI agent safe also gives the data that laws and standards make mandatory. The applicable laws are different for each location, each task and each type of data.

Law or standard	Type	Applies to an AI agent when
EU AI Act	Law. High-risk obligations apply from 2 December 2027 or 2 August 2028.	It is high-risk, for example an AI agent for credit scores or employment decisions.
GDPR	Law. It applies at this time.	It uses personal data.
NIST AI RMF	Not mandatory.	You use the framework for AI risk.
ISO/IEC 42001	Standard for an AI management system.	Your organization uses this standard.
HIPAA Security Rule	US law for health data.	It uses the health data of covered entities or business associates.

EU AI Act

The EU AI Act applies to how you use an AI system. AI in a regulated product can also be high-risk. A high-risk system must have these items:

• “Risk management system” (AI Act Article 9)
• “Record-keeping” (AI Act Article 12)
• Human oversight (AI Act Article 14)
• “Accuracy, robustness and cybersecurity” (AI Act Article 15)

AI Act Article 15 tells that these systems must prevent attacks that change their outputs or their performance. The Digital Omnibus on AI set the dates: 2 December 2027 for the Annex III use cases and 2 August 2028 for regulated products.

A high-risk system that obeys the conditions of the Cyber Resilience Act also obeys the cybersecurity part of AI Act Article 15. The logs, the sandbox, the scopes and the approval steps in this page help to show compliance with AI Act Articles 12, 14 and 15.

GDPR

• GDPR Article 32 tells that the protection must be “appropriate to the risk”.
• GDPR Article 33 tells you to send a report of a data breach in 72 hours, if possible. A data leak from an AI agent starts that period.
• GDPR Article 35 tells you to do a data protection impact assessment before high-risk processing.
• GDPR Article 22 sets limits on decisions that a computer makes without a person.

NIST AI RMF

The NIST AI Risk Management Framework (AI RMF) has 4 functions: “GOVERN, MAP, MEASURE and MANAGE”. The steps in this page agree with these functions:

• The inventory helps the MAP function.
• The red teaming helps the MEASURE function.
• The controls help the MANAGE function.

ISO/IEC 42001

The clauses of ISO/IEC 42001 include AI risk assessment and AI system impact assessment. NIST released a crosswalk from the AI RMF to ISO/IEC 42001. The crosswalk includes suppliers, thus the AI bill of materials also helps here.

Sector laws

For health data in the US, the HIPAA Security Rule tells about “administrative, physical, and technical safeguards”. The page LLMs in regulated industries gives data about contracts with model providers.

Questions and answers

Which step is first when you make an agentic application safe?

Make an inventory of the parts of the agentic application. Then find each session that can read untrusted data, get private data and send data out. Remove one of these 3 properties from each session, or add an approval step for a person.

Can a prompt injection filter stop all attacks on an AI agent?

No, one prompt injection filter is not sufficient. In a 2025 paper, adaptive attacks went through 12 new defenses, most with an attack success rate of more than 90%. Use the prompt injection filter as one layer, and put the strong limits in the permissions and the sandbox.

Does the EU AI Act apply to your AI agent?

The EU AI Act applies to an AI agent when it is high-risk, for example an AI agent for credit scores or employment decisions. For the Annex III use cases, the high-risk obligations apply from 2 December 2027. An AI agent that uses personal data must also obey the GDPR at this time.