September 24, 2026
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
Salman Khan
New Update: Our new blog is updated.
Free download
Omair Manzoor is the Founder, CEO, and Chief Hacker of ioSENTRIX, a CREST-accredited cybersecurity firm. With 14+ years in offensive security, he has led penetration tests for Fortune 500 companies including engagements for Amazon, Bank of America, VISA, and the London Underground. His exploits are part of the Metasploit Framework and Immunity Canvas. Omair is a published researcher, conference keynote speaker (DOD, CISA, BSides), and technical reviewer for academic security textbooks.
The report lands and it looks reassuring. Forty prompt-injection payloads attempted. None successful. Overall risk: low.
Six weeks later the agent issues the same refund twice, because a customer wrote a sentence into a support ticket and the agent read the ticket while deciding what to do.
That scenario is a synthetic composite, assembled from patterns we see rather than drawn from any one client. The point it carries is not. Nothing in that report was wrong — it tested a model, and the thing in production is an agent. The difference is not one of degree. It changes what you are measuring.
You test the actions, not the answers. An AI agent penetration test is an authorized adversarial test whose unit of measurement is the action the agent can take: for every action, the tester establishes what authority it carries, attempts to induce it from each channel that can reach the agent's context, and records the outcome as a reproduction rate rather than a pass or a fail.
That definition does two pieces of work. It puts the tool call rather than the model output at the center of the engagement, and it accepts up front that the system is non-deterministic — something conventional testing never had to.
Because a successful injection against a chatbot ends in a sentence, and a successful injection against an agent ends in a side effect. The payload can be identical. The consequence is not.
This is why OWASP's Top 10 for Agentic Applications, released on December 9, 2025, splits what used to be one problem into two entries: ASI01 Agent Goal Hijack, where the agent's objective is redirected, and ASI02 Tool Misuse, where the agent's legitimate capabilities are turned to an attacker's purpose. A test that only scores whether the model said something it should not have will report clean on both.
Prompt injection testing remains necessary. It is the delivery mechanism. It is not the finding. That shift — from scoring output to scoring action — is the one application security has to absorb in the agentic era.
Four, and they run in order, because each one depends on the last.
Enumerate the action surface. Every tool the agent can invoke, named individually, with read and write distinguished. This is downstream of scoping the engagement and should already be settled in the statement of work; if it is not, the test begins by discovering what the agent can do, which is testing time spent on inventory.
Establish the authority baseline. What the agent authenticates as, and what that identity can reach when nobody is attacking it. In the engagements we see, agents more often inherit an identity than get issued one, so the honest baseline tends to be broader than the team expects — which is the argument of non-human identity security. Record it before you attack, or you cannot tell privilege abuse from normal operation.
Drive the agent from every untrusted channel. Not just the user turn. Anything that lands in the agent's context is an input, and the agent cannot tell documentation from instruction.
Measure the blast radius. What executes downstream of the action without a human reading it first, and whether one induced failure propagates. ASI08 Cascading Failures is its own entry on the OWASP list, and our reason for holding testers to the second-order effect rather than stopping at the first.
Those four map onto the "holistic approach to Red Teaming in four areas: model evaluation, implementation testing, infrastructure assessment, and runtime behavior analysis" set out in OWASP's GenAI Red Teaming Guide.
Five channels reach an agent's context, and a test that exercises one has exercised one.
The user turn is the channel everyone tests and the one an attacker is least likely to own.
The retrieval corpus is the channel an attacker most often can write to — a support queue, an uploaded file, a shared wiki. Plant an instruction, then check whether it reaches a tool call rather than just an odd answer.
Tool responses come back into context as text. A compromised or merely chatty upstream service can place instructions in a field the agent reads. That is the tool-chain boundary covered in MCP security, approached here from the agent's side.
Inter-agent messages are the newest surface and, in our view, the least defended. ASI07 Insecure Inter-Agent Communication covers it, and OWASP's Multi-Agentic System Threat Modeling Guide applies the wider agentic taxonomy to that shape. NIST separates the problem as well: its Control Overlays for Securing AI Systems project keeps single-agent and multi-agent deployments as distinct use cases.
Memory and persisted state spans users, so it needs explicit authorization before you touch it. ASI06 Memory & Context Poisoning is the category; the test is whether content planted in one session surfaces in another.
You report the rate and the attempt count, and you fix the attempt budget before you start rather than after you see the results.
This is the part of agent testing that conventional methodology gives you nothing for. A SQL injection either works or it does not. An agent induced to call a tool it should not call may do so on the second attempt, the seventh, and not the eighth. Three practices keep it honest.
Declare the attempt budget in advance — a fixed N per abuse case, written into the rules of engagement — so nobody is negotiating at debrief about whether four out of ten counts.
Report successes as a rate against that budget, never as a bare "confirmed." A one-in-twenty reproduction is a real finding, and a different remediation conversation from a nineteen-in-twenty one.
Pin and record everything that moves: the model version and build, the system prompt revision, the tool manifest, the date. A result established against a configuration that no longer exists is a historical note.
One success means the path exists. Treat the rate as an input to severity, not as evidence of whether the finding is real.
The same four things any credible finding carries — the attempt, the observed result, the artifact, and the conditions — argued at length in AI security assessment and not re-derived here.
Agent testing adds three items to "the conditions" that a conventional report has no field for: the model version tested, the tool manifest as it stood, and the attempt count behind the result. Without those, a reader six months later cannot tell whether a fix worked or whether the system drifted — the same reason a point-in-time result on an agent ages faster than a point-in-time result on anything else.
None of this makes an agent safe, and no test of a non-deterministic system is exhaustive. What an agent penetration test produces is a set of demonstrated paths, each with a rate attached, against a configuration you can name. That is a smaller claim than buyers sometimes want, and a more useful one than "forty payloads, none successful."
It is also not a methodology only one firm can run. The frameworks are public and several good firms do this well. What we would insist on regardless of who you hire is that the report counts actions rather than answers, and states attempt counts rather than verdicts.
For a self-check, take an agent you have already had tested and answer five questions from the report alone. Can you list every tool it could call at the time? Does the report say what identity it acted as? Does any finding name the channel the payload entered through? Does any finding follow the action downstream to what executed next? And does any result carry an attempt count rather than a checkmark?
If the answer to the last one is no, you have a model evaluation. That is worth having. It is not a test of the agent.
Red teaming is goal-led and open-ended — it asks whether an objective can be reached by any route. An agent penetration test is surface-led: it enumerates the actions the agent can take and works through each one systematically. We covered the distinction and when each is worth buying in AI red teaming vs AI penetration testing.
Longer per abuse case than a conventional test, because every case is run N times rather than once. The attempt budget, not the number of tools, is usually what sets the duration, which is why it belongs in the scope document rather than in the tester's judgment.
Sometimes, and it is often the only place the real tool set exists — but write-capable tools acting on real systems need either a staged equivalent or explicit, narrow authorization per tool. Where a safe equivalent is not available, seeding synthetic canary data lets you prove a path was reachable without acting on anything real.
No. Model evaluation tells you what the model will produce; agent testing tells you what the system will do with it. Both are in scope for a complete AI system test, and the second one is the one that produces consequences.
ioSENTRIX is a CREST-accredited, ISO/IEC 27001 certified offensive security firm. Our AI and ML penetration testing engagements against agentic systems enumerate the action surface first, attack from every channel that reaches the agent's context, and report reproduction rates with the model version and tool manifest attached. Where the agent changes faster than an annual cycle, we run it continuously. We are services-first: we assure the stack you already chose, and independent adversarial testing produces this evidence whoever performs it.
If you have an agent in production and want a second opinion on how it was tested, get in touch.
