OWASP FinBot: An Agentic AI Security Test Range
OWASP FinBot is an intentionally vulnerable multi-agent app that scores exploits on real business state, turning agentic AI security claims into testable evidence.
Disclaimer
This article is intended for informational purposes and reflects the state of published research and industry practice as of mid 2026. It is not professional security advice. Your specific environment, threat model, and regulatory obligations will shape how these principles apply to your situation.
For Security Leaders
When an artificial intelligence agent acts for you, approving invoices, moving payments, contacting vendors, the risk is not what it says but what it does to your business records. Testing these systems by reading the model’s replies misses the failures that cost money, because the words and the resulting action often disagree. If your team cannot reconstruct which agent took which action, under whose authority, and what changed, you cannot yet prove your agentic systems are safe.
What this means for your organization:
Model output is not assurance: a confident, correct-sounding agent reply can accompany a wrong or unauthorized change to a real business record.
Your real gap is reconstruction: if an incident cannot be rebuilt from logged actions and state changes, the finding will not survive an audit or a regulator’s question.
Safe practice is already available: OWASP FinBot is a free, public, intentionally vulnerable application your teams can attack to build agentic testing skill before touching production.
What to tell your teams:
Judge an agent test by the change it caused in the system of record, not by the text the agent produced.
For every agent action, capture the input, the tool that ran, the identity that authorized it, and the resulting state change.
Practice on OWASP FinBot at a pinned version first, and write down the exact version tested.
Treat any finding as incomplete until you can reconstruct the whole sequence from your own logs.
Using OWASP FinBot as an agentic AI security test range
There is a challenge in OWASP FinBot that you cannot win by making the AI say the right thing. FinBot is an intentionally vulnerable, multi-agent financial application that OWASP published in August 2025 so people could practice attacking and defending AI agents. One of its challenges asks you to get the invoice-processing agent to approve an invoice whose amount sits above the agent’s hard policy limit, an amount the policy says must always be rejected. The challenge is scored on exactly one condition: whether the invoice record in the database actually flips to a status of approved. A fluent, approving-sounding paragraph from the agent earns you nothing. The detector behind it, named in the source, keys on the stored state.
That distinction is the whole argument of this article, and it is why I think FinBot is worth your time. In The Agentic AI Security Stack, the reference guide I published in July 2026, FinBot appears exactly once, as the recommended training vehicle for engineers new to agentic threat modeling. That single line undersells it, and it also needs a caveat I want to state plainly. FinBot is not mine. I did not build it, and it is not a companion workbook for the book. It is an OWASP GenAI Security Project resource, created by Helen Oakley, Venkata Sai Kishore Modalavalasa (which peer reviewed my book) and Allie Howe under the project’s Agentic Security Initiative. For a reader working through the book, or through any framework for securing AI agents, FinBot is an external, public range where the architecture claims stop being diagrams and start producing evidence you can check. The claim I want to defend here is narrow and, I think, durable: once your test object is a running agentic application, a security finding has to be tied to a state change and a reconstructable trail, or it is not a finding. FinBot is the first OWASP artifact I know of that makes agentic application testing something you do with your hands rather than read about.
How agentic systems get tested today
Most AI security testing you will see optimizes for one thing: a reproducible relationship between an input and a model’s output. A prompt-injection demonstration shows a prompt and the text the model returned. Jailbreak benchmarks go one step further and score that reply against a list of forbidden strings. In a capture-the-flag exercise, a token is hidden inside the system prompt and you win by extracting it. Scanners automate the whole loop: a battery of adversarial inputs goes in, a label comes out. Each of these treats the model’s response as the system under test, and for a long time that was a reasonable simplification, because for a long time the model’s response was the entire product.
I have spent the last several articles pushing on the limits of that simplification. In a local run of CyberSecEval, Meta’s security benchmark suite, I found the benchmark scoring the model’s visible answer field while the substantive reasoning sat in a separate reasoning field the scorer never read, so the headline number described the measurement path more than the model. Testing tools like garak, a large language model vulnerability scanner, and promptfoo, an LLM testing and evaluation harness, against a local model, the most useful lesson was a meta-one: which class of evidence each tool is even allowed to produce, whether a scanner label, a harness pass or fail, a red-team transcript, or a judge score. Those are different objects, and treating them as interchangeable is how teams end up trusting a green checkmark that measured the wrong thing. The through-line across that work was a chain of trust: a result is only as strong as the weakest link between what you claim and what you can show.
All of that was built around systems whose output was text. The reason it needs revisiting is that agentic applications are not built around text output at all.
Where the transcript stops being the system
An agentic application, in plain terms, is a system where the model does not just answer, it acts: it calls tools, takes steps over many turns, remembers things between turns, and hands work to other agents. The OWASP Top 10 for Agentic Applications, published in December 2025 as the agent-specific companion to the older list for large language model applications, names why this breaks the old testing model. Its rationale, distilled, comes down to three runtime properties a bare model does not have: tool use, where the agent changes something in the world instead of only producing words; multi-step reasoning, where a decision unfolds across many turns and a single injected instruction can compound as it goes; and inter-agent communication, where agents pass instructions to each other, often through a shared standard called the Model Context Protocol (MCP), a common interface that lets an agent call external tools and data sources. Every one of those only exists while the system is running. None of them is visible in a single prompt-and-response pair.
Consider what that does to the invoice challenge. If I judge the attack by the agent’s reply, I am reading a paragraph that says something like “I have reviewed this invoice and approved it for payment.” That paragraph carries no weight on its own. The finding is whether a row in the invoices table now reads approved, whether a payment tool was actually invoked, and under whose authority the invocation ran. The model’s words are a claim about the world. The state change is the world. When the two disagree, and in agentic systems they disagree often, the state is what a defender, an auditor, or an incident responder has to work from.
This is the point where the transcript stops being the system. The consequence is concrete: to test an agentic application honestly, you need a target that exposes state and records the path to it, and you need to follow that path from the input, through the context the model actually saw, through the model’s response, to the specific tool call, to the authorization check that did or did not gate it, to the business-state transition, and finally to the audit record that lets someone else reconstruct the sequence. That is a demanding shopping list. Standing up a realistic multi-agent application, wiring it to real tools, and instrumenting all of that is weeks of work before you have tested anything. Which is exactly the gap FinBot fills.
What FinBot actually is
FinBot simulates a fintech company that runs on AI agents. Vendors onboard, invoices get processed, payments get made, fraud gets flagged, and messages get sent, and language-model-backed agents do that work with real tool access. The version I pinned for testing, commit 1450fc4d authored in June 2026, ships an orchestrator that routes requests to five specialized agents, onboarding, invoice, payments, fraud, and communication, and five MCP tool servers those agents can call, including a document store, a payment simulator, and an email sender. Players reach the system through three portals, one for vendors, one for admins, and one for the capture-the-flag scoring, and each player gets an isolated namespace so one person’s attacks do not corrupt another’s environment. It runs from a single Docker Compose command against SQLite or PostgreSQL, and at this commit its default model is gpt-5-nano. One naming point will trip up anyone who starts from the OWASP page: that page links a smaller demo repository, finbot-ctf-demo, while everything I describe here comes from the fuller platform repository, finbot-ctf, at the pinned commit above. If you follow the official link and see fewer agents and challenges than this article describes, that is why.
Two design choices make it a test range rather than a quiz. The first is that there are no static flags. Nothing is hidden for you to find and paste back. Instead, agent activity streams through an event bus, and a set of detector and evaluator components decide whether a challenge was solved by inspecting what happened. The invoice challenge I opened with is adjudicated by a detector that fires only when an over-limit invoice reaches approved status, so the success condition is a declared, observable state the detector checks without ever interpreting the agent’s tone. The second choice reinforces the first: the scoring engine applies a penalty, cutting the points in half, when it detects crude prompt-injection strings like “ignore your instructions,” which pushes you toward the plausible social engineering a real fraud actor would use and away from the blunt jailbreak text that inflates benchmark scores without reflecting realistic risk. The platform is teaching the same evidence discipline from the outside that I have been arguing for from the inside.
Because FinBot exposes real components, its challenges map onto the parts of an agentic security framework that are about the application rather than the infrastructure, and they arrive pre-labeled against the OWASP lists for both large language model applications and agentic applications, along with the Common Weakness Enumeration and MITRE ATLAS, the industry knowledge base of adversarial techniques against machine learning systems. The policy-bypass challenges, where you drive an agent into approving what it should reject, are the cleanest business-logic surface, and they line up with the book’s threat-model and human-approval chapters. The vendor-versus-admin identity boundary carried down into the MCP tool layer lines up with the agent-identity, orchestration, and protocol-security chapters. And there is a memory surface that is deliberately weak: the source code annotates certain agent-notes fields as an intentional opening for memory poisoning, where content you plant in one interaction persists and re-enters the agent’s context later, which is the memory chapter made testable. The most instructive challenge in this set, called Zero-Click Harvest, chains several of these together. A poisoned document uploaded by one vendor sits dormant until an admin runs a routine compliance review, at which point the instructions in the document route another vendor’s data through the communication agent and out by email, with no further action from the attacker. That is indirect prompt injection, where the hostile instruction arrives inside content the agent retrieves rather than from the user typing it, a technique first characterized in the academic literature in 2023 and now something you can watch execute end to end.
If you have your own agent application, you could of course instrument that instead, and eventually you should. FinBot’s value is that it removes the weeks of setup and gives everyone the same pinned, shared reference to reason about, so the method you practice here transfers to the system you actually own.
Where the map and the range diverge
A test range earns trust by being honest about what it does not simulate, so here is the boundary. FinBot is high-fidelity for agent decisions and low-fidelity for infrastructure compromise, and the gap is documented in its own source. Its system-utilities tool server, the one whose functions look like running diagnostics or managing storage, records every command an agent was manipulated into attempting and then executes none of them; the detectors judge whether the attempted command was dangerous. Its email path defaults to printing messages to the console instead of sending them, and exfiltration challenges are scored by capturing the intended payload inside the platform, before anything reaches a real network boundary. So when a FinBot challenge is marked solved for remote code execution or data exfiltration, the accurate reading is narrow: an agent was successfully driven to attempt a destructive or leaking action. No host was compromised and no data left the building.
That boundary matters because it maps directly onto which chapters of an agentic framework FinBot can and cannot exercise. The decision layer is not simulated: an invoice that should have been rejected and was instead approved is a real failure in the agent’s reasoning and control flow, and it would fail the same way in production. FinBot carries the vendor-versus-admin identity down to the tool layer, but recording an explicit allow-or-deny decision for every tool invocation is the kind of instrumentation you layer on when you run an assessment. Closing that last link falls to whoever runs the test.
But the isolation, egress, and credential concerns, the parts of the stack about containers, network perimeters, and secret stores, are testable against FinBot mostly through configuration review and intent detection; a demonstrated exploit of those layers is out of reach. Reading the running code rather than the design document matters here too. FinBot’s shipped code runs ahead of its own design notes: the architecture file still lists several agents and the tool layer as planned work, while the code already implements them. A threat model built from the documentation alone would understate the live attack surface. The lesson generalizes past FinBot. With any agentic system, inventory what the code actually does before you trust what the diagram claims.
There is one more limit worth stating plainly. FinBot’s challenges cover eight of the ten categories in the 2026 agentic risk list through explicit exercises, but two, human-agent trust exploitation and rogue autonomous agents, have no dedicated challenge at the commit I examined, and human oversight failure shows up only indirectly through the approval-threshold bypasses.
What you carry away
The prior articles in this series argued that a security result must rest on evidence you can reconstruct, and they kept running into the same wall: a benchmark or a scanner hands you a label, and behind the label there is often no state and no trail to check. FinBot removes that wall by giving you an application whose findings are state changes with an event history attached. The question you practice asking here is the one that transfers to whatever agent system you are responsible for: not what did the model say, but what did the application do, under whose authority, and can I rebuild the sequence afterward from what was logged. If the answer to the last part is no, you do not yet have a finding you can defend, whatever the transcript shows.
The next article in this series draws the map before the first exploit: how to threat-model FinBot as an agentic application, so that when the labs start, every claim already has a place to attach its evidence.
Peace. Stay curious! End of transmission.
Fact-check appendix
Statement: OWASP FinBot was published in August 2025 as an intentionally vulnerable agentic AI capture-the-flag application under the OWASP GenAI Security Project’s Agentic Security Initiative, created by Helen Oakley and Allie Howe, and described as “the Juice Shop for Agentic AI.” | Source: OWASP GenAI Security Project, FinBot resource page, https://genai.owasp.org/resource/finbot-agentic-ai-capture-the-flag-ctf-application/
Statement: The OWASP Top 10 for Agentic Applications for 2026 was published in December 2025, extends the OWASP Top 10 for LLM Applications, and identifies added agentic risk from tool use, multi-step reasoning, and inter-agent communication across categories ASI01 through ASI10, including ASI09 (Human-Agent Trust Exploitation) and ASI10 (Rogue Agents). | Source: OWASP GenAI Security Project, https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
Statement: FinBot ships an orchestrator with five specialized agents (onboarding, invoice, payments, fraud, communication), five MCP tool servers, three portals, per-player namespace isolation, event-driven detection with no static flags, Docker Compose deployment on SQLite or PostgreSQL, and a default model of gpt-5-nano, at commit 1450fc4d. | Source: OWASP-ASI finbot-ctf repository, https://github.com/OWASP-ASI/finbot-ctf
Statement: The invoice-threshold challenge is scored only when an over-limit invoice reaches approved status, and the scoring engine applies a 50 percent point penalty for detected brute-force prompt-injection strings. | Source: OWASP-ASI finbot-ctf repository, challenge and detector definitions, https://github.com/OWASP-ASI/finbot-ctf
Statement: FinBot’s system-utilities tool server records attempted commands but executes nothing, and email defaults to console output rather than real sending, making its code-execution and exfiltration challenges intent-detection rather than real compromise. | Source: OWASP-ASI finbot-ctf repository, systemutils server and email configuration, https://github.com/OWASP-ASI/finbot-ctf
Statement: Indirect prompt injection, where a hostile instruction arrives inside retrieved content, was characterized in the academic literature in 2023. | Source: Greshake et al., “Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection,” https://arxiv.org/abs/2302.12173
Statement: The Agentic AI Security Stack was published in July 2026 and references OWASP FinBot as the recommended training vehicle for engineers new to agentic threat modeling. | Source: Next Kick Labs, https://www.nextkicklabs.com/p/agentic-ai-security-stack-book-release
Statement: A local CyberSecEval run scored the model’s visible answer field while substantive reasoning sat in a separate field the scorer did not read. | Source: Next Kick Labs, Article 067, https://www.nextkicklabs.com/p/cyberseceval-local-llm
Statement: Different LLM security tools are permitted to produce different classes of evidence (scanner label, harness result, red-team transcript, judge score). | Source: Next Kick Labs, Article 068, https://www.nextkicklabs.com/p/no-nmap-for-llms
Statement: A security result is only as strong as the weakest link in its chain of trust between claim and evidence. | Source: Next Kick Labs, Article 069, https://www.nextkicklabs.com/p/ai-security-testing-chain
Top 5 sources
OWASP-ASI finbot-ctf repository (https://github.com/OWASP-ASI/finbot-ctf). The primary technical source: the running platform, its agents, MCP servers, challenge definitions, and detectors, inspected at a pinned commit. Authoritative because it is the artifact itself, maintained by the OWASP Agentic Security Initiative.
OWASP GenAI Security Project, FinBot resource page (https://genai.owasp.org/resource/finbot-agentic-ai-capture-the-flag-ctf-application/). The official description, authorship, and framing of FinBot. Authoritative as the publisher’s own statement of what the project is.
OWASP Top 10 for Agentic Applications for 2026 (https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/). The peer-reviewed agentic risk taxonomy the challenges are labeled against. Authoritative as a globally reviewed OWASP framework.
Greshake et al., indirect prompt injection (https://arxiv.org/abs/2302.12173). The academic characterization of the attack class underlying the Zero-Click Harvest challenge. Authoritative as the peer-reviewed origin of the technique.
OWASP Top 10 for Large Language Model Applications (https://owasp.org/www-project-top-10-for-large-language-model-applications/). The base list the agentic taxonomy extends and that FinBot challenges also label against. Authoritative as the foundational OWASP LLM security standard.