AI Agents With Tool Access: Prompt Injection, Least Privilege and Human Approval

From text to actions

Early language-model products produced text and a person read it. A growing share now act: they read mail, search files, call business systems, write code and send messages. That is useful, and it changes the security question. A wrong answer is an annoyance. A wrong action, taken with your credentials, can leak customer records or move money. The OWASP GenAI Security Project's Top 10 for LLM Applications 2025 is a reasonable map of what can go wrong. This article concentrates on three entries that matter most once tools are attached. Our earlier article on the OWASP agentic threats and our article on MCP servers cover related ground from other angles.

LLM01: prompt injection

Prompt injection means input changes the model's behavior in ways its builders did not intend. In the direct form, a user types instructions that override the rules. In the indirect form, which matters more for agents, the malicious instructions sit in content the agent reads: a web page, a PDF, a support ticket, a calendar invite, a code comment or an email. The agent reads that content as part of doing its job, and the content says to forward the last ten messages to an outside address.

The reason this is hard is structural. In a conventional program, code and data are separate. In a language model they arrive in one stream of text, and the model decides what to treat as an instruction. Filters, delimiters and instructions such as never obey text in documents all help and none is a guarantee. OWASP says outright that it is unclear whether fool-proof prevention exists, and recommends layered mitigation. The practical lesson is to assume a successful injection and ask what the agent could do next.

LLM06: excessive agency

OWASP lists three roots of excessive agency. Excessive functionality is an agent given tools it does not need for its task, such as a document summarizer that can also delete files. Excessive permissions is a tool that runs with more access than it should, such as a database connection with write rights when it only reads. Excessive autonomy is an agent that takes high-impact actions without anyone checking. Injection makes all three dangerous, because it turns the agent's legitimate access into the attacker's access.

Designing so that an injection is survivable

These controls work whether or not the model is fooled.

• A short allowlist of tools per agent. If the job is to draft replies, the agent gets a draft tool, not a send tool.
• Narrow tools instead of general ones. A tool that reads one named folder is safer than one that runs any shell command or fetches any URL.
• Separate read from write. Reading is reversible in effect and writing is not, so apply stricter limits and approval to the write path.
• Scoped, short-lived credentials issued per task, in the user's name where possible, and held by the tool service, not shown to the model. The model should never see a secret.
• Break the triangle. A frequently cited framing in security writing is that risk peaks when an agent has access to private data, reads untrusted content and can communicate outward. Remove one: block outbound destinations except an allowlist, or keep the agent that reads the web away from the one that holds customer data.
• Limits on volume and rate, so a hijacked agent cannot export a whole database or send a thousand messages (see also LLM10, unbounded consumption).
• Sandboxes for code execution, with no network by default and no access to the host's files or credentials.

Human approval that means something

The standard answer to autonomy risk is to put a person in the loop. It only works if the approval is designed well. A person who clicks yes on forty prompts an hour is not reviewing anything.

• Approve by consequence, not by tool. Reading is automatic. Sending outside the company, changing a record, spending money or deleting needs approval.
• Show the real action: the actual recipient, the exact amount, the actual command or the diff, rendered by the system, not described by the agent in its own words.
• Make the safe choice the easy one, and log who approved what and when.
• Keep approvals rare enough to read. If everything needs approval, narrow the agent until only the risky actions do.
• Require a second person for the highest-impact actions, the same rule finance applies to payments.

LLM05 and the rest of the list

Improper output handling (LLM05) is the old injection problem in a new place. If the model's output is passed on to a browser, a database query or a shell without checks, a manipulated output becomes cross-site scripting, SQL injection or command execution. Treat the model like any untrusted user: validate and encode its output, use parameterized queries and never pass it to an interpreter directly. Sensitive information disclosure (LLM02) and system prompt leakage (LLM07) are a reminder not to put secrets in prompts. The retrieval and supply-chain entries matter when an agent pulls from shared knowledge bases or third-party tools.

Test it like an attacker would

Before an agent touches production data, run it against a set of injection attempts hidden in the kinds of content it will really read, and check which tool calls it makes. Record each call with its arguments, the identity used and what triggered it, so an investigator can reconstruct the chain. Repeat the tests when the model, the prompts or the tool list change. Our article on what insurers and auditors now ask about your AI lists the evidence they expect to see.

If you are planning agents for back-office work, or want an existing one assessed, start with our Super Intelligence service. Our team designs the tool list, the permissions and the approval steps together, and tests them with adversarial content before launch.

Sources

• OWASP Top 10 for Large Language Model Applications 2025 (OWASP GenAI Security Project)
• LLM01:2025 Prompt Injection (OWASP GenAI Security Project)
• LLM06:2025 Excessive Agency (OWASP GenAI Security Project)
• NIST AI 100-2e2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
• AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems (CISA, NSA, FBI)

This article is general information about a fast-moving field. Treat the controls as a starting point and test them against your own systems. Last reviewed November 9, 2026.

Keep reading

Next · SecurityPenetration Test, Vulnerability Scan or Red Team: Which One Do You Actually Need?The three terms get used as if they meant the same thing, and they answer different questions. This is a decision guide: what each one tests, who it suits, which one a standard may already require, and what to do before you order.8 min read

• Local, Private or Frontier? How to Use AI Without Exposing Sensitive Data6 min
• Local AI vs Frontier APIs: Cost, Privacy and Governance of Running Open-Weight Models on Your Own GPUs8 min