AI agent security risks: what to check before you buy

An AI agent does more than answer questions. It reads your email, files or web pages and then acts in your software. It can send, update, delete or buy. That is what makes it useful, and it is also why a mistake stops being a bad sentence on a screen and becomes an action in one of your systems.

Limit what the agent can read and what it can do

Put plainly, two things set your risk. The first is what the agent reads: emails, web pages, shared files, customer messages. Anything in that pile can carry instructions. The second is what it can do: send, delete, pay, change records. The more it can do, the more one bad instruction can cost you.

You cannot fix the model inside a product you buy. You can decide which systems it may reach, which actions it may take on its own, and which ones wait for a person, and those decisions come before launch. Writing them down is a core part of good AI consulting. At Truline we make approvals, sources, limits, privacy and exception handling explicit, so the new tool has a boundary the people responsible can inspect.

The OWASP GenAI Security Project publishes a list of the main security risks in AI applications. Its entry on Excessive Agency describes the core problem: an agent takes a damaging action because its output was unexpected, ambiguous or manipulated, whatever caused the malfunction. OWASP names three usual causes. The agent has more functions than it needs, more permissions than it needs, or more freedom to act on its own than it needs. Most agentic AI security risks you will read about trace back to too much of one of those, or to what the agent reads.

Assume hidden instructions will reach the agent

The best-known risk is prompt injection. OWASP describes it as input that changes the model's behavior or output in ways nobody intended. For agents, the version that matters most is indirect. The instruction is not typed by you. It sits inside something the agent reads, such as a website or a file.

The US National Institute of Standards and Technology (NIST) calls this agent hijacking. An attacker plants malicious instructions in data the agent may take in, and the agent then takes unintended, harmful actions. NIST wrote in January 2025 that many AI agents are vulnerable to it.

OpenAI gives a concrete case in its ChatGPT agent announcement. A malicious prompt hidden in a webpage, in parts of the page a person never sees, could trick the agent into sharing private data from a connected app with the attacker, or into taking a harmful action on a site where you are logged in.

How often do these attacks work? It depends on the product and the test. Anthropic attacked its own agent on purpose, a practice called red-team testing, and measured a 23.6% attack success rate for Claude in Chrome before its new safety measures and 11.2% after them. That is the vendor's own test of its own browser agent, run in an experimental mode where the agent acts on its own, so it says nothing about other products. NIST's researchers saw attack success rise from 11% to 81% when they switched from the strongest existing attack to the strongest new one. That was a simulated test environment and one model released in October 2024, not a count of real incidents.

Read together, the two results point the same way. Better defenses lowered the rate, and stronger attacks raised it. OWASP says plainly that "it is unclear if there are fool-proof methods of prevention" for prompt injection.

So plan as if some hidden instruction will get through, and focus on what the agent could do with it. Ask the seller to show you what happens when a planted instruction reaches the agent, and test the agent before launch with examples from your own work. OWASP's AI Agent Security Cheat Sheet also recommends security testing before an agent goes into production and again after material changes to its prompts, tools, memory, data sources, policies or model provider.

Give the agent only the access the task needs

OWASP's mailbox example makes this concrete. A tool that summarizes your email may only need to read email, so it should not also be able to send or delete messages. If the tool cannot delete, an email telling it to delete messages has nothing to act on. That is the Anthropic example above, defused by access rather than by the model.

The same guidance gives a second example. An agent that uses your product database to recommend purchases might only need read access to the list of products. It should not reach other parts of the database, and it should not be able to add, change or delete records. OWASP says the database's own permissions for the agent's account should enforce that.

My advice is to check OWASP's three causes one at a time when you review an agent. Does it have tools this task never uses? Does its account reach more data than the task needs? Can it carry out a high-impact step without a person? Each yes is something to cut before launch. OWASP's agent guidance puts the same rule in one line: grant agents "the minimum tools required for their specific task."

Keep private data out of tasks that do not need it

OWASP's list of what can leak from AI applications includes personal information, financial details, health records, confidential business data, security credentials and legal documents. With an agent, a leak is not only a bad answer on screen. It can be data sent onward in an action the agent takes, which is exactly the OpenAI example above.

OpenAI's advice to people using its agent is to reduce that exposure by switching off connectors when a task does not need them. A connector is the agent's link to another app, such as your email or calendar.

Apply the same rule when you buy. If the task is drafting quotes from a price list, the agent does not need your customer records, your accounting software or your shared drive. Leave them disconnected until a task genuinely needs them.

Check what the agent saves for later

Some agents keep notes between sessions so they can remember preferences or earlier work. OWASP calls the risk here memory poisoning: malicious data saved in the agent's memory that influences future sessions or other users.

This one is easy to miss because the damage arrives later. A bad instruction read today can shape what the agent does in a later session, long after anyone remembers the email that caused it. OWASP recommends checking data before it is stored and setting expiry dates and size limits on memory.

When you evaluate an agent, ask what it stores, who can see and delete it, how long it is kept, and whether one customer's notes can affect another customer's session.

Cap usage before it runs up the bill

OWASP's entry on Unbounded Consumption points out that cloud AI services charge per use, and describes attackers sending a high volume of requests to exploit that. It calls the pattern "Denial of Wallet". Its recommended defenses are limits on how many requests one source can make in a given period, plus time limits that stop heavy jobs from running on and on.

In buyer terms, agree a usage limit before launch, find out what the agent does when it reaches that limit, and make sure a named person is told. If you are also setting the budget, my article on cost explains how to cap the agent's spending alongside the other running costs.

Put the controls outside the model

The AI agent security best practices I would ask for first all share one idea. They do not depend on the model behaving well.

Require approval for high-impact actions. OWASP recommends that a person approve high-impact actions before they are taken. OpenAI describes the same idea in its own product: "explicit user confirmation" before consequential actions, and a "Watch Mode" in which critical tasks such as sending emails need your active oversight.

Enforce permissions in your systems, not in the model. OWASP's advice is to let the connected systems decide what is allowed rather than relying on the model to make that call. In practice, the account the agent uses in your email or customer database should simply lack the permission to delete or export. A manipulated agent then gets refused by the system itself.

Keep tools narrow and usage capped, as covered above. These AI agent risks get smaller when the agent can do less.

What fails is the reverse of each. An agent with full mailbox access and an instruction telling it never to delete anything is relying on the model to police itself, which is what OWASP warns against. Connections left switched on in case they are useful widen what a hidden instruction can reach. And in my view, an approval step only protects you if the person approving actually reads what they are approving.

Ask the seller these questions before you sign

These are my questions, drawn from the guidance above. Each one maps to a row in the table.

Which systems can the agent reach, and which actions can it take in each? Get the answer in writing, as specific as read access to email with no sending or deleting.

Which actions wait for a person's approval, and who can change that setting?

Where are permissions enforced? The answer you want is in the connected systems, through the account the agent uses, and not only in instructions given to the model.

What does the agent store between sessions, for how long, and who can delete it?

What usage limits exist, and what happens when the agent reaches one?

What security testing has been published for this agent, and what did it find?

Do not expect the last answer to be easy. A University of Cambridge story on the AI Agent Index, which looked at 30 top AI agents, found that only four had published formal safety and evaluation documents about the agents themselves, and 25 of the 30 did not disclose internal safety results. That is a study of what sellers disclose, not of how safe their agents are. If a seller cannot show you any testing, record it as unknown and keep the agent's access small to match.