An AI agent is not a chatbot with tools. It is an autonomous actor with capabilities — and every capability is an attack surface. To show what that means in practice, we built a deliberately vulnerable AI customer-support agent as a controlled target and ran a structured agentic red-team against it.
The target follows a common 2026 architecture: an LLM-powered agent connected to two MCP tool servers (customer-record lookup and email dispatch) and a RAG knowledge base of support documents. Everything in the lab is synthetic — invented customers, no real credentials, no real infrastructure, no real system affected. The point is to demonstrate the weakness classes and, more importantly, to prove they can be closed.
Five vulnerability classes, mapped to the agentic framework
We mapped each finding primarily to the OWASP Top 10 for Agentic Applications 2026 — the framework built specifically for autonomous agent systems — with the OWASP Top 10 for LLM Applications 2025, MITRE ATLAS and the NIST AI Risk Management Framework as secondary maps.
Agent persuaded to bypass its own identity-verification step.
An action tool with no approval gate, allowlist or rate limit can be driven to dispatch arbitrary messages.
A lookup tool with no authorisation boundary returns records the requester should never reach.
Instruction-like content inside retrieved documents is treated as commands rather than data.
Internal operating instructions exposed on request, arming the findings above.
None of these are theoretical. They were demonstrated against a straightforward agent built with popular, current tooling. They are also the failure modes most teams overlook, because traditional web-application testing — parameter tampering, SQL injection, cross-site scripting — does not cover prompt injection, tool-call agency without a human in the loop, or confused-deputy scenarios where one tool's output drives another tool's invocation.
Why a record-lookup with no boundary is a regulatory problem
In a production system holding real personal data, a record-lookup tool with no authorisation boundary is the class of weakness that engages GDPR Article 32 (security of processing) — which requires appropriate technical measures to protect personal data. An unauthenticated mass-lookup path is the opposite of that. In our lab the records were synthetic and nothing was exposed; in a live deployment, the same flaw is a reportable-breach waiting to happen.
The part that matters: we prove the fix
A finding without a proven remediation is just an opinion. So we built a hardened variant of the same agent and re-ran every exploit against it. Crucially, we kept the same model behaviour — the agent still attempts the malicious tool calls. The hardening sits outside the model, in a policy and guard layer, so the protection is demonstrably real and not a side effect of a quieter model.
Against the hardened build, every exploit that previously succeeded failed:
- Cross-record lookups are denied — the session is bound to one authenticated identity.
- The email action is approval-gated — an unattended attacker cannot satisfy it.
- Retrieved documents are sanitised — instruction-like content is neutralised before it can reach the model's context, while the agent still retrieves the document.
- System-prompt content is stripped from responses regardless of what the model tries to emit.
The indirect-injection case is the clearest illustration. The hardened agent still pulls the same poisoned knowledge-base document — the attack is still attempted — but the embedded override instructions are rewritten to a redaction marker before they reach the model. The fix is in the data layer, not a request that the model behave.
The full combined chain — reconnaissance, privilege escalation, bulk extraction, exfiltration — fired end-to-end against the vulnerable build and was stopped at every phase against the hardened one. Not by asking the model nicely, but by enforcing policy around it.
What this means for teams deploying agents
If you are putting an LLM agent in front of real tools and real data, treat each capability as an attack surface from day one: bind tool access to an authenticated identity, gate consequential actions behind approval, rate-limit and allowlist, and sanitise everything that enters the model's context — including your own knowledge base. Security has to be an architectural concern, not an afterthought bolted on once something breaks.
This is the methodology our team applies in an agentic red-team engagement: we build a representative target, exploit it systematically across the agentic attack surface, document the remediation that closes each finding, then re-test to prove the fixes hold.