Prompt injection in AI agent tool calls, explained

Prompt injection is text that an AI model reads as instructions although it came from data, such as a support ticket, a web page or a database row. For an agent with tools, the injected text can trigger real tool calls: reading secrets, changing records or sending them out. It is a property of how models read text.

Why agents make it worse

A chat model that reads injected text can only say something wrong. An agent can act on it. Whatever its tools can do, the injected text can ask for: a query, a write, an email, a refund. That is why the OWASP Top 10 for LLM applications puts prompt injection first, as LLM01, and lists excessive agency, LLM06, beside it.¹

The injected text rarely arrives through the chat box. It comes in with the data the agent was asked to handle: a customer’s ticket, a pull request, a page it fetched, a row in a table.

Two public cases

A support ticket and a database. In a July 2025 demonstration with dummy data, a support ticket carried instructions aimed at a developer’s AI assistant. The assistant used the Supabase MCP server under a service_role credential, which bypasses row-level security. It read the integration_tokens table and added its contents as a new message in the same ticket, where the attacker could see it.²
A read-only mode that wasn’t. Datadog Security Labs showed that an archived Postgres MCP server ran each query in a read-only transaction that a stacked COMMIT; ended, after which later statements ran with the role’s full rights.³ Text that gets the agent to send such a query turns “read-only” into write access.

In both, the model did what text told it to, and the damage came from what its credential could do.

What limits the damage

No filter reliably tells instructions from data, so plan for the agent to be fooled sometimes, and decide in advance what a fooled agent can do:

Least privilege. Give the agent’s credential only what its job needs. A role that can’t read a secrets table can’t leak it, whatever the prompt says.
Rules outside the model. Decide each tool call with rules the model can’t edit: refuse destructive verbs, several statements at once, and writes without a WHERE.
A person for the irreversible. Hold refunds, deletes and sends to the outside for approval.
Separate readers from writers. An agent that reads untrusted text shouldn’t also hold the keys to change production.
Check afterwards. Compare what the system really changed with what the agent said, so a quiet change doesn’t go unnoticed.

An example

examples/policies/postgres-safe.yaml in the Deedglass repository (excerpt)yaml

rules:
  - id: one-statement-only
    match: { connector_type: postgres }
    when: sql.multi
    decision: deny
    reason: Send one SQL statement per action. This request had several.
  - id: block-destructive-sql
    match: { connector_type: postgres }
    when: sql.kind in ["drop", "truncate"]
    decision: deny
    reason: DROP and TRUNCATE are never allowed for agents.

How Deedglass uses it

Deedglass doesn't detect injected text. It limits what any instruction, injected or not, can make a tool call do. Agent SQL runs as a least-privilege role in a transaction Deedglass controls, one statement per action.⁴ Through an MCP server, only tool calls meet your rules; resources, prompts and other messages pass through, and the server's requests for your model or your input are refused unless you allow them.⁵

Sources

Last checked 25 October 2026. We re-check the glossary every month. If something here is wrong, write to hello@deedglass.com.

Prompt injection

Why agents make it worse

Two public cases

What limits the damage

An example

How Deedglass uses it

Related on this site

Terms

Posts

In the docs

Sources