CART
Banks are deploying AI systems that change weekly and testing them with red-team engagements that happen yearly. CART is a continuous adversarial agent I am building to close that gap: a planner-executor-judge-memory loop that attacks a deployed AI system the way its failures actually arrive, constantly, adaptively, and with a record auditors can use. The wedge is financial services, because its governance structure does not merely permit this product; it requires it three times over.
I build production AI systems as an AI engineering consultant: agentic root-cause analysis at one of the world's largest consumer internet platforms, and the rebuild of a Fortune 500 bank's development lifecycle around agentic tooling, cutting feature cycle time from days to hours for most changes. In the bank, I watched the assurance side up close. When an AI system needs adversarial testing, the institution buys a boutique red-team engagement: commonly quoted in the low-to-mid six figures, staffed for a few weeks, delivered as a PDF.
The engagement model has a structural defect that no amount of consultant quality fixes: it is point-in-time assurance for a system that does not hold still. The model gets updated, the prompts get tuned, the retrieval corpus grows, upstream APIs change shape, and users adapt to the system itself. Each of those changes can open a failure mode the last engagement never saw. The PDF certifies a system that no longer exists by the time it is filed.
The result is a gap between assurance cadence and change cadence. Everything about AI deployment is continuous except the thing checking it.
CART is an autonomous red-team agent that runs against a target AI system on a standing basis. Four components, one loop.
Planner. Selects what to attack next: which capability, which interface, which class of adversarial pressure, informed by what has and has not worked against this target before.
Executor. Runs the attack against the target: prompt-level adversarial inputs, tool-boundary probes, data-channel injections, policy-violation attempts.
Judge. Scores the outcome. Did the target violate policy, leak what it should not, act outside its mandate, or fail silently. Judged evidence, not raw transcripts, is what flows downstream.
Memory. Persists findings, successful attack lineages, and target behavior over time, so the agent escalates where the target is weak instead of replaying a static script. A fixed attack set decays into a checklist; a remembering one does not.
The output is not a report. It is a living record: every finding timestamped, reproducible, and mapped to the control it implicates, which is the shape of evidence that risk and audit functions can actually consume.
The reason to start in financial services is not that banks have money. It is that banking governance is legally structured in a way that multiplies this product. The argument runs in four steps, and each step is load-bearing.
Model risk governance in banking, the regime shaped by supervisory guidance such as the Federal Reserve's SR 11-7 and its European counterparts, mandates a Three Lines of Defense structure: a first line that builds and owns AI systems, a second line that independently validates them, and a third line, internal audit, that independently assures both.
The second line's mandate is effective challenge. A validator who tests a model using the builders' own test harness inherits that harness's blind spots, and the challenge is no longer independent in substance. Internal audit applies the same standard one level up. Shared tooling across lines is the kind of independence deficiency the third line exists to flag.
It follows that adversarial testing cannot be one shared instance. The first line needs it pre-deployment, in the development loop. The second line needs it configured to its own scenarios, run on its own authority, producing its own evidence. The third line needs assurance over both, on an audit cadence. Three functions, three legitimate and separately budgeted needs.
CART is one adversarial engine configured per line: a build-time SKU for the first line, a validation SKU for the second, an audit SKU for the third. The same institution can buy it up to three times, and each sale strengthens the case for the next, because evidence that flows between lines in a consistent format is itself a governance improvement. Regulation, not sales effort, creates the multiplication.
The multiplication argument holds only if institutions treat adversarial tooling as subject to the same independence standard as validation tooling generally. Where a bank's audit function accepts shared tooling with configuration-level separation, three SKUs collapse toward one. Early design-partner conversations exist in part to test exactly this.
The EU AI Act's obligations for high-risk systems, a category that explicitly covers credit scoring and other core financial-services uses, take effect August 2, 2026. Days from this note's publication, in-scope institutions carry binding duties around risk management, robustness, and post-market monitoring, and continuous adversarial testing is among the most direct ways to generate the evidence those duties demand. Supervisors on both sides of the Atlantic have spent two decades building the model-risk regime described in §4; the AI Act extends its logic and adds a date. Point-in-time PDFs were a weak answer before the deadline. After it, they are a documented gap.
This note is the company; two companion notes are the technology. The ARCH thesis note describes the reasoning architecture, an executive layer that gates an agent's conclusions on counterfactual consistency, which is what a red-team agent needs in order to escalate attacks deliberately rather than randomly. The CORTEX evaluation note describes the measurement methodology, reliability scored as degradation under perturbation rather than single-run success, which is what the judge scores against. This document is the argument that one specific market structurally needs both, three times over.
CART is at build stage. In progress: v1 of the planner-executor-judge-memory loop, run against open-source targets first. Sought: design partners in financial services willing to test the §4 argument against their real governance constraints, second-line and third-line teams especially. No customers or revenue are claimed here, because there are none yet; what is claimed is the argument, and it is written down so it can be attacked. If you sit in any of the three lines and think a step above fails in your institution, that conversation is the one I want to have.