Sarthi: an AI relationship-manager copilot for banking

A relationship manager's day is spread across a dozen systems: the customer's accounts and transactions, credit risk, loan products, government schemes, policy circulars and KYC documents. The questions they actually ask — is this customer drifting into risk, which loan fits, what does the policy say — need all of that at once, in plain language.

Sarthi started as a hackathon brief: build that copilot. The harder brief Shreyansh set himself was to make it honest about where AI helps, where it guesses, and where the system itself is unsafe.

Once the demo worked, Shreyansh reviewed it as an outsider would and wrote the result down: twenty findings, graded P0 (security) to P3 (polish), worst first. P0 #1: no authentication on any endpoint, and sequential customer IDs (CUST-1001…CUST-1024) — the whole book scrapeable with a for-loop. P0 #2: the chat API accepted a caller-supplied 'system' role in its history — a full prompt-injection override. P0 #3: no rate limit in front of a paid LLM API.

The decision was to keep that document in the repository, alongside the fixes — role whitelisting and a ten-turn cap on chat history, zod validation on every POST route, response checks in every client fetch, a per-IP rate limiter with a stricter cap on chat, an optional API gate token, and security headers — and to state plainly what was deliberately deferred: real per-user authorization and a move off in-memory data, both unnecessary for a synthetic-data prototype but essential before real customers.

A working twelve-module copilot, and a written record that separates a hackathon build from something you could put in front of real customer data. Every P0–P3 finding was addressed except the two deferred items, which are named as such.

It's the clearest example on this site of how Shreyansh treats AI systems: the model sits inside the loop, and the system around it is audited like any other code.