Tech stack interaction (analyst: Next.js frontend, agent coordination: FastAPI backend, Python core, SQLite log)
Sentinel simulates fraud attacks on a bank's rules so an analyst can decide, with evidence, whether to approve the proposed fix.
Agentic fraud attacker test the bank's current fraud detection system
Creating a network map based on the agent attacker's behavior

Inspiration

Changing a fraud rule is one of the riskiest calls a bank analyst makes. If a bank leaves a gap in their detection rules and criminals walk money through it, and banks usually find out after the money is gone.

Analysts usually implement fraud detection improvements with little evidence about what the rule changes will actually do, since their rules are built and tested on past attacks that criminals have already moved beyond. Security teams have had red-teaming for years. We wanted to give fraud teams the same: a safe place to attack their own rules, test a fix, and see the tradeoffs before deciding.

What it does

Sentinel exists to answer one question for a fraud analyst: should I approve this rule change?

To get there, it runs a full round in a safe sandbox:

Build a fake bank. A seeded simulator creates a synthetic credit union (salaried households, gig workers, small businesses) with thousands of realistic transactions. No real customer data is involved.
Red finds a gap. An attacker agent tries to move stolen money through mule accounts without tripping an alert. It adapts based on which rule caught it, for up to 4 turns. In our demo round, it moves \$6,859 through a slow mule chain that waits hours at each hop, so the speed-based rules never fire.
Sentinel explains the miss. For every rule that stayed silent, the analyst sees which check fell short and by how much.
Blue proposes a fix. A defender agent proposes a rule change, for example: alarm if money passes through 4+ accounts within 72 hours, each holding it under 24 hours and forwarding at least 40%.
Plain code scores it, not an AI. The fix is tested on held-out attacks and customers neither agent has seen. Five safety gates check that it catches more fraud, keeps everything the old rules caught, and stays within a false-alarm budget.
The analyst decides. Everything above lands on one decision screen:
- Does it catch more fraud? Yes: $8 \to 32$ of 48 unseen attacks.
- Will it flag good customers? No more than before: 49 of 500.
- What does it still miss? 16 attacks, shown openly.
- Is it safe? If any gate fails, the server refuses the approval, not just the button.

Approving creates a new detector version, and Red immediately attacks it again to look for the next gap.

The fix's results held across 11 of 11 random seeds. Every step lands in an append-only audit log, so a compliance team can see exactly why a rule changed and who approved it.

How we built it

Every part is built to make the analyst's decision trustworthy.

Backend (Python, FastAPI, SQLite): a seeded transaction simulator, a feature library that can only look at past transactions, a rules detector, and an evaluator with the safety gates. Each round runs through an explicit state machine.
Red agent: a bounded "recipe" of six attack knobs (hop count, hold time, splits, forwarding percentage and more) that compile into simulator actions. A heuristic policy adapts based on which rule caught it. There's also an opt-in LLM policy with leak tests confirming Red never sees labels or held-out data, and it falls back to the heuristic if the model fails.
Blue agent: Gemini with structured JSON output, validated with Pydantic, with fail-closed retries. A record/replay mode lets anyone re-verify a full lab offline.
Frontend (Next.js, React Flow): designed around the decision. It shows an attack-path map that toggles between "slipped through on the current rules" and "stopped by the proposed fix." A timeline shows why each rule stayed silent, and a pinned scorecard sits next to the approve/reject panel.
Determinism everywhere: one seeded RNG per component and money stored as integer cents. The same seed gives the same result every time, so the numbers an analyst sees can be reproduced.

Challenges we ran into

Our first baseline was useless. The starting rules flagged 57% of normal customers, so any "improvement" meant nothing. We retuned the baseline before the fix's results meant anything.
Making the fix defensible, not lucky. Our first rule's margin was thin. Instead of picking a seed that looked good, we refined the rule (the 40% forwarding condition) and tested it across 11 seeds and multiple thresholds.
Keeping the AI honest. An agent can easily "win" by peeking at answers. We built leak tests so Red never sees labels or held-out data, and no number on the scorecard comes from model output.
Integration at 3am. Merging two backend branches meant resolving conflicts by hand and chasing a Windows-only SQLite bug. We also had to untangle two backends that both claimed the same /timeline route.

Accomplishments that we're proud of

A complete loop that works end to end: attack, explain, fix, independent scoring, human decision, rechallenge.
A fix that holds up: $8 \to 32$ of 48 attacks caught with zero new false alarms, across every seed we tried.
Safety rules enforced by the server, not just the UI.
We redesigned around the analyst's decision after a user test. Our tester's top question was "which attacks did the fix still miss, and why?" We built a breakdown that answers it directly, because an analyst can't approve a rule responsibly without knowing its blind spots.
99 backend tests, including determinism and no-future-data checks.

What we learned

The hardest part of fraud detection isn't writing a rule. It's knowing whether a rule change is safe to approve. False alarms matter as much as catches.
AI works best here as a proposer, not a judge. Letting plain code do the scoring made the system easier to trust and debug.
At a bank, a lab approval is only step one, followed by weeks of shadow testing and formal sign-off. Sentinel's job is to make sure only fixes likely to survive that process get sent there.
Talking to a real user halfway through changed what we built, for the better.

What's next for Sentinel

Close the gaps the new rule still misses: chains that hold money longer than 24 hours, very short chains, and attacks that split funds many ways.
Calibrate the synthetic bank against a real institution's transaction patterns.
Add authentication and roles so only authorized analysts can approve.
Retire held-out test sets after use, so repeated testing doesn't overstate how well a fix works.
Export approved rules in formats real rules engines can import.