AI agent security: prompt injection, permissions and safe setups

An AI agent that can only chat is a limited risk. An agent that can read email, browse the web, call tools, change records and send messages is a different matter: anything that can steer it can act through it. Security for agents is therefore partly about the model and largely about what the agent is allowed to touch. This page covers the main risks and the controls that digital collar workers can put in place without being security specialists.

The short answer: treat everything an agent reads as untrusted, because hidden instructions in a web page, file or email can redirect it. There is no known fool-proof fix for this, so limit the damage instead: give the agent only the tools and permissions its job needs, run it with the user's own access rather than a powerful shared account, require a person's approval for high-impact actions, and log what it does.

Why agents change the security picture

The US National Institute of Standards and Technology notes that generative AI expands the attack surface, because the systems themselves are vulnerable to attacks such as prompt injection and data poisoning (NIST AI 600-1, Generative AI Profile). An agent connected to company systems turns that weakness into a route into those systems.

The OWASP Top 10 for Large Language Model Applications, a widely used community security list, puts prompt injection first in its 2025 edition and lists excessive agency, sensitive information disclosure and improper output handling among the other top risks (OWASP Top 10 for LLM Applications 2025).

Prompt injection

OWASP defines a prompt injection vulnerability as one that occurs when prompts alter a model's behaviour or output in unintended ways, and notes that the instructions need not even be visible to a person (OWASP LLM01:2025 Prompt Injection). It distinguishes two kinds:

• Direct: a user's own input changes the model's behaviour in unintended ways, on purpose or by accident.
• Indirect: the model takes in content from outside sources, such as websites or files, that contains instructions which change what it does.

NIST adds that security researchers have demonstrated indirect prompt injections that steal proprietary data or run malicious code remotely (NIST AI 600-1). For an agent, the realistic case looks like this: it is asked to summarise a supplier's web page, and the page carries hidden text telling it to forward the user's files somewhere.

OWASP is blunt about the limits: because generative models are probabilistic, it is unclear whether there are fool-proof methods to prevent prompt injection (OWASP LLM01:2025). The working assumption should be that an agent can be tricked, and the setup should make that survivable.

Excessive agency

OWASP's term for an agent that can do more than it should is excessive agency. It identifies three root causes (OWASP LLM06:2025 Excessive Agency):

• Excessive functionality: tools or extensions that can do more than the task needs.
• Excessive permissions: access to more systems or data than the job requires.
• Excessive autonomy: high-impact actions taken without a person checking.

Every one of these is a setup choice, which makes it the part of agent security that the people running agents control most directly.

Controls that limit the damage

Drawing on OWASP's recommended mitigations (LLM01, LLM06):

1. Least privilege. Give the agent only the tools, functions and permissions its job needs. Read-only where reading is enough.
2. Narrow tools over open-ended ones. A tool that can "send an invoice reminder" is safer than one that can run any command or send any email.
3. Act as the user, not as an administrator. Run the agent with the access of the person it works for, not a shared high-privilege account.
4. Human approval for high-impact actions. Payments, deletions, external messages and permission changes wait for a person. OWASP describes human-in-the-loop controls as a key safeguard against both accidental mistakes and malicious prompt injection.
5. Separate outside content. Mark clearly which input comes from untrusted sources, so the agent and its reviewers can treat it accordingly.
6. Check outputs before they are used. Validate what the agent produces before another system acts on it, especially code, links and commands.
7. Log and rate-limit. Record what the agent does and cap how much it can do in a period, so that unwanted behaviour is spotted early and stays small.
8. Test it as an attacker would. Try to trick the agent before someone else does, and repeat after changes.

Keeping secrets secret

OWASP lists sensitive information disclosure and system prompt leakage among its top risks (OWASP Top 10 2025). Two simple rules follow. Do not put passwords, keys or confidential data in an agent's instructions, because those instructions can leak. And do not give an agent access to data it does not need, because what it can read, it can be tricked into revealing. Our page on AI agents and personal data covers the data protection side.

Questions to ask before switching an agent on

• What untrusted content will it read: web pages, emails, uploads, documents from outside?
• What is the worst thing it could do with its current tools and permissions?
• Which actions need a person's approval, and is that enforced by the system rather than just written in the instructions?
• Whose account does it act with?
• Is there a log, and does anyone look at it?
• Can it be stopped at once, and who can do that?

Security for agents is not only the IT team's job. The person who writes an agent's brief and chooses its tools makes most of the decisions that matter. See also our guide to introducing AI agents at work.