Agentic Honey-Pot: AI Counter-Scam Platform

Agentic Honey-Pot answers scammers with AI personas instead of real people. Each persona plays a believable victim — confused, out of their depth with technology, keen on the transaction, or just slow — while the backend scores the conversation for malicious intent in real time and a dashboard shows the conversations live. Shaunak Chorge and I built it together at the GUVI AI Impact Buildathon 2026.

Blocking a scammer protects one person, once. The scammer moves on to the next target, and you learn nothing about how the scam works. A honeypot flips that around: instead of ending the conversation, you keep it going with something that looks like a real victim but isn't. Every minute a scammer spends on a bot is a minute not spent on a real person, and the conversation itself becomes intelligence.

Doing that by hand means a human sitting in every conversation, staying in character for as long as it lasts. Agentic Honey-Pot hands that job to LLM-driven personas.

The goal in one line: simulate realistic victims to waste scammers' time, gather intelligence and protect real targets.

We split the project into two apps: a Python backend that runs the personas and the scoring, and a React frontend for the people watching.

• Backend (scam_honeypot_backend) — a FastAPI app served by Uvicorn, with Pydantic for validation. It orchestrates the AI agents behind the personas, calls the LLM through the Groq API, and runs the scam-probability analysis on each conversation in real time.
• Frontend (scam_honeypot_frontend) — React 19 on Vite, with Axios for API calls and Lucide icons. It shows the conversations live, with controls to intervene.

The backend is async FastAPI, built for high concurrency. That suits a system that leans on an external LLM API: while one conversation waits for its next reply, the others keep moving.

The persona engine is built on character archetypes with four engagement strategies:

• PASSIVE — confused, asks basic questions.
• VULNERABLE — feigns technical incompetence.
• ENGAGED — shows fake interest in the transaction.
• STALLING — deliberately prolongs the conversation.

The idea is that each strategy gives the scammer a different reason to keep going. Basic questions need answers. A victim who can't follow technical steps has to be walked through every one. Apparent interest in the transaction keeps the payoff in sight. And stalling simply buys time. Switching between personas and strategies is the job of the FastAPI orchestration layer.

Alongside the personas runs the detector: a real-time, semantic score of the conversation's probability of malicious intent. The score is compared against a threshold — 0.7 by default — set through the SCAM_THRESHOLD environment variable, so moving it is a configuration change rather than a code change.

Any threshold is a trade-off. Lower it and you catch more real scams, but you also flag more innocent conversations — false positives. Raise it and the false positives drop, but more scams slip under the line — false negatives. Which mistake costs more depends on what a flag triggers and who reviews it, which is exactly why the number shouldn't be hard-coded.

An LLM agent that talks to scammers isn't something you want just anyone on the internet to drive, so the backend has two guards and one convenience:

• API-key authentication on the internal endpoints.
• Custom rate-limiting middleware. Every persona reply is an LLM call, so unthrottled traffic would turn straight into spent API quota.
• Interactive API docs with Scalar at /scalar, rendered from the OpenAPI schema that FastAPI generates — so the docs stay in step with the code.

The React 19 + Vite frontend is where a person watches the honeypot work: live conversation dashboards that follow the personas and scammers as they talk, and intervention controls so a human can step in rather than leaving every decision to the model. An autonomous agent talking to scammers is exactly the kind of system that needs a person able to interrupt it.

Each of these follows from the design, and each has a clear next step:

• Every turn depends on an external LLM API. Persona replies come through Groq, so the honeypot's latency, cost and uptime are tied to a provider we don't control. Next step: a fallback model or provider, and a defined behaviour for when neither is available.
• A single threshold is a blunt instrument. One number makes the call for every conversation. Next step: label a set of real conversations, check that a score of 0.7 really corresponds to about a 70% chance of a scam, and choose the threshold from the precision–recall curve rather than by default.
• Persona realism needs evaluating. Whether a persona is convincing is an empirical question. Next step: run each of the four strategies against real scam scripts and compare how long each keeps the conversation going and how much it draws out.