# Inside the XRPL AI Red Team: What We've Found and Fixed > Source: > Published: 2026-05-29 17:30:07+00:00 Back in March, we [announced](https://ripple.com/insights/strengthening-xrp-ledger-security-with-ai-for-next-phase-of-growth/) that Ripple was standing up a dedicated AI-assisted red team to continuously hunt for vulnerabilities in the XRP Ledger. Two months in, we want to give the community a real look under the hood: how the effort is structured, what kinds of bugs we've found, and what we've learned along the way. The XRPL has been running continuously since 2012 and has processed over three billion transactions. That track record is something to be proud of, but it also means the codebase carries the weight of a decade of engineering evolution - design decisions made at a different scale, assumptions that predate modern tooling, and legacy patterns that interact in non-obvious ways with newer features. New features ship regularly, each adding complexity across the core protocol, client SDKs, and the Clio API server. A codebase that has evolved over a decade accumulates subtle interactions between subsystems that no single person can hold entirely in their head. AI models allow us to go both deeper and broader in larger codebases, at a speed and scale that would otherwise be near-impossible. Teams can thoroughly explore large codebases at a depth and breadth that would be impractical with manual review alone, finding edge cases where subsystems intersect and in sections of the codebase that haven’t been closely scrutinized in years. The red team combines several complementary techniques, each catching different classes of bugs. **AI bug-finding agents.** The core of our approach is custom AI pipelines that analyze the rippled codebase, XRPL client SDKs (xrpl.js, xrpl-py, xrpl4j, xrpl-rust, xrpl-go), and Clio. We run these agents against feature branches, release candidates, and the main codebase on a continuous basis, including scheduled weekly runs against the `develop` branch to catch bugs introduced by new code. **DepthFirst.** We use [DepthFirst](https://depthfirst.com/), an AI-powered vulnerability discovery platform, for deep scans of our repositories. While our custom pipelines are purpose-built around XRPL-specific semantics, DepthFirst brings broader coverage: it traces data flows, business logic, and cross-service interactions across the codebase to find attack paths that span module boundaries. We specifically use their low-level C/C++ model, which is tuned for the memory safety and type-confusion bugs that dominate systems-level code. **Antithesis (fault-injection testing).** We use [Antithesis](https://antithesis.com/), a continuous fault-injection platform, to run rippled under adversarial conditions - exploring behaviors that only emerge under concurrent load, partial failures, or unusual transaction ordering. This catches a different class of bug than static analysis: timing-dependent crashes and assertion failures that only appear when the system is under stress. Antithesis has already caught real bugs that we have shipped fixes for in production releases. **External security research intake.** We actively receive and triage reports from external researchers, whether through our [bug bounty program](https://ripple.com/legal/bug-bounty/) or via other channels. These flow through the same triage pipeline as our internal findings. **PR review bots.** We run GitHub Copilot and a Ripple-managed Claude-based bot on rippled PRs. Both post inline comments directly on the PRs, catching issues before they can become bugs in the codebase. Discovery is only the first step. As Mozilla observed in their similar work [hardening Firefox with AI](https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/): "A discovery subsystem is necessary but not sufficient. In order to scale the effort, we needed to integrate it with our full security bug lifecycle: determining what to look for, where to look, and how to handle what it produces." We've built the same thing for the XRPL. Our lifecycle looks like this: Coverage spans nearly every major subsystem: the transaction engine, the RPC layer, the peer/overlay protocol, AMM, MPT, Vault, Lending, Permission Delegation, NFTs, and more. To date, the team has publicly disclosed 287 xrpld issues on GitHub (231 open, 49 closed), with more issues regularly created as triage continues. These issues are mainly code-quality improvements and defense-in-depth enhancements, and none affect system stability, availability, or the safety of funds. The full list is [on Github](https://github.com/XRPLF/rippled/issues?q=is%3Aissue+label%3A%22AI+Triage%22). The 3.1.3 release was dedicated entirely to security and bug fixes. No new features, just hardening. It included 20 red-team findings across several categories: **Permissioned Domain + Tickets crash (Critical).** A specific combination of a Ticket-based transaction with the PermissionedDomain feature could trigger a keylet collision that would crash the validator. Neither feature was individually broken; the bug only existed at their intersection. This bug was initially caught by the XRPL Commons team back in March, and an initial fix that fixed the crash but not the root cause (since that required an amendment) was released in 3.1.2. However, during our release testing for 3.1.3 with Antithesis, we caught a second crashing issue with the same root cause. *This is exactly the class of issue the red team was built to find, and exactly why we run fault injection against staging before release.* The initial PR from 3.1.2 is [#6540](https://github.com/XRPLF/rippled/pull/6540), and the full fix in 3.1.3 is [#7129](https://github.com/XRPLF/rippled/pull/7129). **Ledger RPC API v2 crash (High).** The Ledger RPC API v2 endpoint had a crash path reachable from any public connection (no authentication required). A malformed request would bring down the node. This is the kind of bug that's easy to miss in code review because the crash condition is a few layers removed from the input handling, yet straightforward to find with systematic adversarial input generation. The fix PR is [#7109](https://github.com/XRPLF/rippled/pull/7109). The remaining findings are summarized in the table below: | Bug | Category | Severity | PR | |---|---|---|---| | HTTP Forwarded Header Out-of-Bounds Heap Read | Core / RPC | High | | `removeExpired` Silently Ignores `deleteSLE` FailureThere were also several assorted smaller fixes included, some of which were found by AI. *Note: this is not an exhaustive list of all bugs fixed in 3.1.3 - only those found by AI red team efforts.* The team has also been scanning Clio and several widely-used client libraries (xrpl.js, xrpl-py, xrpl4j, xrpl-go, xrpl-rust). The SDK scan found many issues across multiple language implementations, several of which have already been patched. We have also publicly disclosed [44 issues](https://github.com/XRPLF/xrpl-py/issues?q=is%3Aissue%20label%3A%22AI%20Triage%22) in xrpl-py, [48 issues](https://github.com/XRPLF/xrpl.js/issues?q=is%3Aissue%20label%3A%22AI%20Triage%22) in xrpl.js, and [126 issues](https://github.com/XRPLF/xrpl-rust/issues?q=is%3Aissue%20label%3A%22AI%20Triage%22) in xrpl-rust. **AI is a force multiplier, but cannot fully replace humans.** Our pipelines find real bugs (including Critical and High severity issues), but also produce false positives. Human review of AI verdicts, especially for false positives, is a crucial part of the process. The combination of AI discovery + AI triage + human expert validation is what makes the system work. **A full pipeline beats a great tool.** Having a strong bug-finding AI model is necessary but not sufficient. The real value is in how you use it (the prompts and harnesses you use to guide the model to find bugs) and the surrounding infrastructure (issue tracking integration, deduplication, severity standardization, routing to the right teams, and tracking through to the fix). **Cross-feature interactions are the hardest bugs to find.** The most significant findings were in the intersections between features that individually worked correctly, rather than in any one single feature. This is where AI-assisted analysis has the clearest advantage: it can explore the full range of possible feature interactions much more exhaustively. **Security transparency requires responsible coordination.** Fixing critical bugs while protecting the network and users requires close coordination with validators and ecosystem participants before public disclosure. The 3.1.3 release was the first dedicated security release to come out of this effort. Future planned releases, including 3.2.0, will include more fixes from the backlog of confirmed findings. We're expanding our analysis to cover cross-feature interactions better, and continuing to run Antithesis fault-injection tests on new release branches. We're also working to run more comprehensive attackathons on new amendments before they're activated on mainnet - the security bar for new amendments is going up. We also plan on open-sourcing our pipelines as soon as we have fixed all the exploitable bugs. If you find a potential vulnerability in the XRP Ledger, please report it through our [responsible disclosure process](https://ripple.com/legal/bug-bounty/). The red team reviews all incoming reports. Security at this scale requires the whole ecosystem. We'll continue to keep you posted on what we find.