I Built a Private, Local AI That Explains Why a Message Looks Like a Scam

Preetam Malawade — Sat, 24 Oct 2026 14:17:38 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

ScamShield Local: An AI Scam Assistant That Shows Its Evidence, Not Just a Verdict

Imagine receiving a message saying your bank account will be blocked in 30 minutes unless you verify your details.

Or a job offer promising ₹45,000 per month that asks you to pay a registration fee first.

The messages might look convincing. You might be in a hurry, worried about losing money, or unsure whether the sender is legitimate.

You could ask an AI chatbot for help, but a response like "This might be a scam. Be careful" doesn't really solve the problem. You still don't know which parts are suspicious or how to verify the claim safely.

And if the message contains personal or financial information, sending it to a cloud-based AI service raises another concern: privacy.

I built ScamShield Local to help people understand suspicious messages, see the evidence behind an AI assessment, and decide what to do next — without depending on a third-party AI API.

What I Built

ScamShield Local is a local-first AI assistant that analyzes user-submitted messages and explains potential scam indicators.

Instead of simply returning a "Scam" label, it focuses on four things:

Risk assessment: Classifies the message as High Risk, Suspicious, or No Obvious Warning Signs Detected.
Evidence-based explanations: Extracts exact phrases from the message and explains why they may be suspicious.
Safe verification steps: Suggests independently checking official apps, websites, or trusted contact channels.
Explicit uncertainty: Explains what cannot be reliably established from text alone, such as the sender's true identity or the legitimacy of a website.

For example, if a message threatens immediate account suspension, ScamShield can identify the wording that creates urgency and explain why it deserves scrutiny.

If a job offer requests an upfront registration fee, it can highlight that request as a potential warning sign.

The point isn't to make people suspicious of everything. It's to help them pause and investigate before clicking a link, sharing sensitive information, or transferring money.

The people who benefit most are those who don't have the technical knowledge to recognize phishing techniques but still need a practical way to assess suspicious messages.

Demo

Prototype Screenshot:
https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/yqtivtuofggxr9cm66tj.png

GitHub repository: PREET4M/ScamShield

You can explore the source code and project documentation in the repository.

For the strongest demonstration, I'll include a screenshot or screen recording showing the actual workflow:

Paste a suspicious test message.
Run the analysis locally.
View the risk assessment and exact evidence quotes.
Review the recommended verification steps.

Note: ScamShield is an early prototype. I haven't included a separate deployed demo or video link here because I don't want to present an unverified link as a working demo.

Code

Explore the code: GitHub — ScamShield

The project uses a simple architecture that separates the user interface, backend validation, and local model inference.

React + Vite
     |
     v
Python + FastAPI
     |
     v
Ollama + Gemma 3 4B
     |
     v
Structured Risk Analysis
     |
     v
Evidence & Safe Recommendations

This separation makes the application easier to understand, maintain, and extend.

The backend validates incoming requests, constructs the model prompt, and validates the structured response before returning it to the frontend.

The model is instructed to treat the submitted message as untrusted content rather than instructions it should follow. This is important because a malicious message might contain text designed to manipulate the model itself.

Prompt instructions and schema validation provide useful safeguards, but they do not eliminate every prompt injection risk or guarantee correct detection.

How I Built It

I chose a local-first architecture because the application processes potentially sensitive information.

Here's the stack:

React + Vite: Frontend and analysis dashboard.
Python + FastAPI: Backend API, request handling, input validation, prompt construction, and output validation.
Ollama: Local model runtime.
Gemma 3 4B: Open-weight language model used to analyze messages and generate structured findings.

When a user submits a message, the frontend sends it to the FastAPI backend. The backend prepares the request and passes it to the locally running model through Ollama.

The model generates the analysis, and the backend checks the response structure before sending it to the frontend.

The core AI workflow is designed to run without third-party AI API calls. This means users can perform the analysis using compatible local hardware without depending on a paid cloud inference service.

I also smoke-tested the prototype against mock scenarios involving phishing alerts, upfront-fee job offers, ordinary notifications, and attempted prompt injections.

These tests are an initial check of expected behavior, not a comprehensive benchmark of real-world scam detection accuracy. Broader evaluation, including false-positive and false-negative measurements, remains important.

Why Does Open Innovation Matter?

For a project like ScamShield Local, open innovation is about more than making source code available. It's about giving developers the freedom to inspect, question, test, and improve how an AI-powered security tool works.

Using an open-weight model through a local runtime makes experimentation possible without requiring a paid, hosted model API for the core analysis.

That matters in several ways.

Privacy-conscious experimentation: Developers can build and test the analysis workflow locally instead of having to send every test message to a cloud AI provider.

Accessibility: People can experiment with the project using compatible hardware without maintaining a paid inference subscription.

Transparency and extensibility: Developers can inspect the application code, review the prompts and validation logic, and propose improvements.

Community-driven testing: Contributors can help identify failure cases, improve test coverage, evaluate different models, and explore support for regional languages.

A closed API can be convenient and powerful, but it can also introduce external service dependencies, usage costs, and less control over the inference environment.

Open-weight models and open-source tooling give this project another path: build locally, inspect the implementation, and improve it through community contributions.

Open innovation doesn't automatically make an application secure or accurate. The real value comes from making it possible for others to examine the work and help improve it.

My Agent Session

Optional section.

I'll add a DevRelay agent session here if I save and publish a relevant session showing the development process.

For now, the GitHub repository is the primary project link.

The Lazy Payoff

The time-saving benefit isn't about automating away a complex investigation. It's about making the first step easier.

Without ScamShield, someone unsure about a message might have to figure out what to look for, manually identify suspicious wording, and ask several follow-up questions to understand the risks.

ScamShield brings those first steps into one workflow:

Submit the message.
Review the potential warning signs.
Understand why specific phrases matter.
Follow safer verification steps.

That can reduce the effort needed to get an initial, structured assessment.

I haven't measured a reliable time-saving figure yet, so I won't claim a specific number of minutes saved or suggest that the tool prevents every scam.

The more important goal is to help users make a more informed decision without needing to understand cybersecurity terminology first.

Prize Categories

My project is primarily focused on open-source AI and local inference, using Ollama and Gemma 3 4B to build a privacy-conscious scam analysis assistant.

I'll select the applicable partner prize categories according to the official challenge rules and the categories available on the submission page.

What's Next?

ScamShield Local is an early prototype, and there are several areas I'd like to improve:

More systematic evaluation against diverse scam and legitimate-message examples.
Better support for Indian languages and regional scam patterns.
Stronger testing against prompt injection and adversarial inputs.
Measurement of false positives and false negatives.
Additional capabilities that preserve the local-first approach wherever possible.

These are important steps toward making the tool more reliable and useful beyond a prototype.

Let's Build Safer AI Tools

I believe AI is most useful when it helps people make better decisions instead of asking them to trust a black box.

ScamShield Local is my attempt to put that idea into practice: local AI, understandable evidence, practical verification steps, and honest uncertainty.

If you're interested in local AI, cybersecurity, or open-source development, I'd love for you to explore the project and share your feedback.

GitHub: https://github.com/PREET4M/ScamShield

One question I'd love to hear your thoughts on:

If an AI flagged a message as suspicious, would you trust its verdict — or would you need it to show you the exact evidence first?

For me, showing the evidence is where trust should begin.

devchallenge #hf26challenge

Hi

Preetam Malawade — Mon, 12 Oct 2026 09:49:17 +0000

I am new to this! I hope everything goes well

DEV Community: Preetam Malawade