Sentinel

Autonomous fraud investigation, with a human in command.

Comment

Autonomous fraud investigation, with a human in command.

Inspiration

When a bank's transaction-monitoring system flags something suspicious, it lands in a queue, and a level-one fraud analyst picks it up. Their job is triage: open the case, then open six more tabs — transaction history, KYC documents, device and geolocation logs, sanctions and PEP screens, and any prior cases on the customer — piece together what happened, and write a disposition that recommends closing the alert, escalating it, or filing a Suspicious Activity Report (SAR).

Each case takes 45–90 minutes. Banks run entire floors of these analysts and still can't keep up; alerts pile up, and genuine fraud slips through the backlog. The work is repetitive, evidence-gathering-heavy, and exactly the kind of multi-step, tool-using task an agent should be able to do — if it can reason over real operational data and stay under human control. That's the bet behind Sentinel.

What it does

Sentinel takes a single flagged transaction and autonomously produces the analyst's complete case file in about a minute:

  • A written suspicious-activity narrative in the analyst's voice, suitable for a SAR or internal disposition
  • A full, auditable evidence trail — every query the agent ran, in order, on the record
  • Citations to similar historical cases, retrieved by semantic similarity ("we saw this exact velocity-and-geography pattern in a past case, confirmed as a money mule")
  • A recommendation — close as benign / escalate / file SAR — with a confidence score

Then it stops. A human reviewer reads the case and approves, escalates, or rejects it. Sentinel never files on its own. What took an analyst 45–90 minutes, Sentinel compresses into roughly 60–90 seconds — turning the analyst from an evidence-gatherer into a decision-maker reviewing finished work.

How we built it

The agent. Sentinel is built with the Google Agent Development Kit (ADK) — the code-first path of the Google Cloud Agent Builder ecosystem — reasoning with Gemini 3.5 Flash on Vertex AI. ADK runs the agent's full plan-and-act loop: it decides which queries to run next, calls its tools, interprets the results, and assembles the case. All planning, tool-calling, and reasoning happen inside ADK + Gemini.

Its superpower: the MongoDB MCP Server. The agent's entire toolset is the MongoDB MCP Server, integrated over authenticated HTTP. Rather than hand-coded data functions, the agent calls MCP tools to query the database directly — this is what turns Gemini's reasoning into real action against live banking data.

The data layer: MongoDB Atlas as a unified store. Customers, accounts, transactions, KYC documents, device fingerprints, sanctions hits, and prior case files all live in one Atlas cluster. During an investigation the agent:

  • Resolves the subject, accounts, and the flagged transactions
  • Traces the money with aggregation pipelines across the transaction graph (e.g. 14 wires to 3 downstream accounts in 72 hours)
  • Checks KYC records, device fingerprints, and sanctions screens for mismatches
  • Runs Atlas Vector Search over thousands of historical case narratives — embedded with Voyage AI (voyage-3-large, 1024-dim) — to retrieve the most similar past cases and ground its conclusion in the institution's own history

The same database holds both the operational data the agent queries and the precedent it reasons from — MongoDB's "operational + vector in one place" pitch, used for real.

Everything runs in production:

  • Agent (ADK + Gemini) and the MongoDB MCP Server → both deployed on Google Cloud Run
  • App (Next.js, tRPC, Tailwind, shadcn/ui) → Vercel
  • Event trigger → Inngest durably delivers the alert.created event from the app to the agent. Inngest is the event pipe, not the agent's brain — the agent itself is pure ADK + Gemini.

The live flow: a flagged transaction fires an event → Inngest durably invokes the agent on Cloud Run → the agent investigates through the MongoDB MCP Server against Atlas, persisting each tool call, the final narrative (with its vector embedding), and the case status back to MongoDB as it works → the UI streams the investigation in real time, ending on a completed case awaiting human review.

Challenges we ran into

  • Authenticated MCP over HTTP. Running the MCP server as a hosted, locked-down Cloud Run service (not a local stdio process) meant the agent had to mint Google identity tokens on the fly to authenticate to it — lazy token fetching via the metadata server on Cloud Run, with a local override for development.
  • Deploying a Python ADK agent to Cloud Run. The ADK CLI's container loader kept mis-detecting our agent's config in the container. We solved it by wrapping the ADK agent in a small FastAPI service that imports the agent directly and exposing a single /investigate endpoint, then deploying that with a plain Dockerfile. Clean, reliable, and still pure ADK underneath.
  • Wiring the full live chain. Getting Vercel → Inngest → Cloud Run agent → MCP → Atlas → Vertex to run end-to-end in production — correct credentials at every hop, durable triggering, and live progress streaming back to the UI — rather than only working on a laptop.

Accomplishments that we're proud of

A genuinely agentic, multi-step investigation — not a scripted pipeline. ADK + Gemini decide what to query, trace the money themselves, retrieve precedent, and write a coherent SAR narrative with a recommendation and confidence score.

And it's fully deployed and live — not a local demo. A judge can sign in and fire a real investigation on the hosted URL, watch the agent work through its tool calls in real time, and review a finished case in about a minute: agent and MongoDB MCP server on Google Cloud Run, app on Vercel, triggered durably through Inngest.

We're also proud of the discipline of the design: a compliance-grade evidence trail, a human-in-the-loop gate on every filing, and an institutional, audit-first UI rather than a chat box.

What we learned

  • MongoDB's "operational + vector in one database" is real leverage for an agent. The same store holding live transactions also holds the historical case narratives the agent reasons from — no second system, no sync, one query surface via MCP.
  • The MCP server is what makes an agent do things. Exposing the database as a toolset (rather than bespoke functions) let the agent decide its own investigative path instead of following a fixed script.
  • Human-in-the-loop isn't a limitation; it's the design. Financial-crime decisions carry legal weight, so the right architecture is an agent that compresses the investigation and a human who owns the judgment.

What's next for Sentinel

  • Real-time triggering via MongoDB change streams, so investigations start the instant an alert lands
  • A richer reviewer workflow with audit history, reviewer notes, and escalation routing
  • Growing the historical-case corpus so precedent retrieval via vector search sharpens with every closed case
  • A multi-agent split (intake → investigation → narrative → review) for deeper, parallelized analysis

Built with

Google Agent Development Kit (ADK) · Gemini 3.5 Flash · Vertex AI · Google Cloud Run · MongoDB Atlas · MongoDB MCP Server · Atlas Vector Search · Voyage AI · Next.js · tRPC · Tailwind · shadcn/ui · Prisma · better-auth · Inngest · Bun · TypeScript · Python

Built With

  • atlas-vector-search
  • better-auth
  • bun
  • gemini
  • google-adk
  • google-cloud-run
  • inngest
  • mongodb
  • mongodb-atlas
  • mongodb-mcp-server
  • next.js
  • prisma
  • python
  • tailwind
  • trpc
  • typescript
  • vertex-ai
  • voyage-ai
Share this project:

Updates