AI Agent Security: Prompt Injection, Tool Permissions and Least Privilege

A chatbot that answers questions can embarrass you if it is wrong. An agent that can send email, update records, issue refunds or run code can cause real damage if it is manipulated. As soon as a model can take actions and read content you do not control, security stops being an afterthought and becomes a core design constraint.

This guide covers the main risks, with prompt injection first, and the controls that actually reduce them: least privilege for tools and data, treating everything the agent reads as untrusted, approval gates for consequential actions, sandboxing, logging and adversarial testing. It extends the security notes in our [AI agent development guide](/blog/ai-agent-development-guide) and the control principles in our [human-in-the-loop guide](/blog/human-in-the-loop-ai).

Why agents change the threat model

Traditional software separates code from data. A language model does not: instructions and content arrive in the same stream of text, and the model decides what to treat as an instruction. That makes prompt injection possible. A user, or far more dangerously a document, web page, email or tool result the agent reads, can contain text crafted to override its instructions or redirect its behaviour.

The risk compounds with capability. The more an agent can do (and the more it can see), the more an attacker gains by steering it. A useful framing is to ask, for any agent, three questions at once. Can it access sensitive data? Can it read content from untrusted sources? Can it take actions or send data outward? When all three are true, a successful injection can read something sensitive and send it somewhere, and you should design as if that will eventually be attempted.

Direct and indirect injection

• Direct injection: the user types something designed to bypass the agent's rules. Easier to anticipate, because you know the source.
• Indirect injection: the hostile instruction hides in content the agent retrieves or processes, such as a support ticket, a shared document, an inbound email or a web page. The user may be entirely innocent. This is the harder problem, and it is why every retrieved document in a RAG or agent pipeline should be treated as untrusted input, as noted in our enterprise RAG architecture guide.

Control	What it does	Limitation
Least-privilege tools	Agent can only call the specific tools and scopes it needs	Requires deliberate design; broad shared credentials undo it
Scoped data access	Agent sees only the data the current user is entitled to see	Must be enforced outside the model, in the data layer
Approval gates	Human confirms consequential or irreversible actions	Adds friction; reviewers need clear context to avoid rubber-stamping
Sandboxing	Code execution and file access isolated from production systems	Does not stop misuse of the tools you deliberately allow
Output and action validation	Check proposed actions against rules before executing	Rules cannot anticipate every novel attack
Logging and monitoring	Record inputs, tool calls and outcomes for detection and audit	Detects after the fact unless paired with alerts
Adversarial testing	Probe the agent with injection attempts before launch	Finds known patterns; needs repeating as the agent changes

Apply least privilege everywhere

Give each agent its own identity and the narrowest permissions that let it do its job: read-only where reading is enough, access to specific records rather than whole databases, short-lived credentials rather than long-lived keys, and separate tools for read and write. Enforce the user's access rights in the data layer so the agent can never retrieve something the person asking could not see themselves. A support agent that can look up one customer's order does not need the ability to export the customer table.

Gate consequential actions

Sort actions by blast radius. Low-risk, reversible actions (drafting a reply, looking up a status) can run automatically. Moving money, deleting data, changing permissions, sending external communications or anything irreversible should require explicit approval, with the proposed action, its inputs and the reason shown clearly to the reviewer. Design the approval screen so a person can genuinely judge it in seconds; an approval nobody can evaluate is only theatre.

Contain data exfiltration paths

Injection often aims to leak data by getting the agent to include it in a link, an email, a tool call or an image URL. Restrict outbound destinations, strip or block untrusted links and markup in rendered output, and limit which tools can send data outside your boundary.

Log, monitor and test

Record each tool call with its arguments, the context that led to it and the result, so you can reconstruct incidents. Alert on unusual patterns such as bursts of tool calls or access to atypical data. Before launch and after significant changes, run adversarial tests: injection strings in documents and tickets, attempts to extract the system prompt, and requests that try to trigger unauthorized actions. Our LLM observability guide covers the tracing foundation that makes this possible.