Your AI agent has the database key. Who else does?
Agents with function calling and MCP turned the chatbot into a privileged user of your system. The five abuse patterns we find in agent pentests and how to shrink the blast radius.
From chatbot to privileged user
In 2024 the risk of a chatbot was saying something wrong. In 2026 the risk is doing something wrong. Agents wired through function calling, MCP (Model Context Protocol) or direct integrations query the CRM, open tickets, issue refunds, run SQL and call internal APIs. The model became a user of the system — often with a service account that has more permission than any human.
The OWASP Top 10 for LLM calls this Excessive Agency (LLM06) and Insecure Output Handling (LLM02). In practice, it is what produces the most critical findings in our agent engagements.
The five patterns we find
1. The tool trusts the model
get_invoice(customer_id) receives whatever ID the model decided to pass. If the model can be convinced — by direct prompt injection or a poisoned document — to pass another customer’s ID, the tool complies. It is BOLA/IDOR with a middleman that speaks English. The fix is the same as for APIs: authorization inside the tool, bound to the authenticated user’s identity — never to a parameter chosen by the model.
2. One credential for everything
The agent runs with a single API key or service account that sees every tenant. Any successful injection becomes full access. We have seen support agents with write access to the production database "because one tool needed to update a status".
3. Tool chaining
On their own, read_file and send_email are harmless. Together, they are exfiltration. The attacker does not need a dangerous tool; they need two benign tools and a prompt that chains them. Testing tool by tool does not find this — combinations have to be tested.
4. Actions without human confirmation
Refund, delete, transfer, publish. When the agent performs irreversible actions without an approval step, a single malicious document in the knowledge base becomes a financial incident. The safe pattern is human-in-the-loop for any destructive or value-moving action, with per-transaction and per-period limits.
5. Model output treated as trusted
The model returns markdown, HTML or JSON that the frontend renders or another system executes. Without sanitization it is XSS or command injection with one extra hop. The classic case: the agent generates a link with context data in the URL and the application’s own client makes the request that exfiltrates it.
Shrinking the blast radius
- Least privilege per tool, with the end user’s identity propagated (not an agent account).
- Tool allowlists by context: the support agent does not need
run_sql. - Structural separation between instructions and retrieved data, with explicit marking of untrusted content.
- Human confirmation for irreversible actions; value and rate limits.
- Logs for every tool call with input, output and the context snippet that triggered it — without them there is no investigation.
- Security testing of the whole system before every expansion of the agent’s permissions.
How Pentest Machine tests this
In our AI/LLM Pentest we map every tool, credential and integration of the agent, test direct and indirect injection, chaining and privilege escalation, and deliver a reproducible PoC with the real impact — the exposed record, the sent email, the refund issued in a test environment. If your agent already has access to customer data, it is already part of your attack surface.