Have you ever received a message saying:
"URGENT! Your bank account will be blocked. Verify your account immediately."
Or clicked a link and wondered:
"Is this website actually safe?"
For someone with a cybersecurity background, these messages can contain obvious warning signs. But for a non-technical person, understanding those warning signs isn't always easy.
That's the problem I wanted to solve with CyberBuddy.
CyberBuddy is a local AI-powered cybersecurity assistant that helps non-technical users understand suspicious messages and URLs and decide what they should do next.
This project was built for the Hacktoberfest Weekend Challenge: Build for a Friend.
The Problem
Cybersecurity advice is often written for technical users.
Terms like:
- phishing
- credential harvesting
- suspicious indicators
- malicious URLs
- account takeover
- social engineering
can be confusing to someone who doesn't work in cybersecurity.
A person receiving a suspicious message doesn't necessarily need a complicated security report.
They need answers to simple questions:
- Is this suspicious?
- Why does it look suspicious?
- What should I avoid doing?
- What should I do next?
That's where CyberBuddy comes in.
Meet CyberBuddy
CyberBuddy is designed around a simple idea:
Give people understandable security guidance without requiring them to understand cybersecurity terminology.
The current MVP supports two types of analysis:
1. Suspicious Message Analyzer
A user can paste a suspicious email or message.
For example:
URGENT! Your bank account will be blocked.
Please provide your OTP immediately at
https://example.com/login
CyberBuddy analyzes the message and identifies indicators such as:
- urgent or pressure-based language
- credential requests
- financial information requests
- account access threats
- URLs
It then calculates a risk level and score.
2. Suspicious URL Analyzer
Users can also enter a URL directly.
For example:
http://192.168.1.10/login
CyberBuddy can identify indicators such as:
- HTTP instead of HTTPS
- IP address used instead of a domain
- security-sensitive keywords such as login
The URL is then assigned a risk score based on the detected indicators.
How CyberBuddy Works
One of the most important design decisions I made was to separate security analysis from AI explanation.
The architecture looks like this:
User Input
│
▼
┌─────────────────────┐
│ Deterministic │
│ Security Analysis │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Evidence Detection │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Risk Assessment │
│ + Risk Score │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Gemma 3 4B │
│ Local AI │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Simple Explanation │
│ + Safe Actions │
└─────────────────────┘
The important part is:
Gemma does not decide the security risk.
The deterministic CyberBuddy analyzers and risk engines are responsible for detecting indicators and calculating the risk.
Gemma receives that existing analysis and explains it in simple language.
This makes the AI an explanation layer, rather than the authority making the security decision.
Why I Used Gemma 3 4B
For the AI component, I chose Gemma 3 4B running locally through Ollama.
The reason was simple: I wanted CyberBuddy's AI functionality to work locally without requiring an external API key.
The setup is:
CyberBuddy
│
▼
Ollama
│
▼
Gemma 3 4B
Gemma receives the structured security analysis generated by CyberBuddy.
For example:
Risk: CRITICAL
Risk Score: 95
Possible Attack: Phishing
Indicators:
- Urgent language
- Credential request
- Account access threat
- Suspicious URL
Gemma then turns that technical information into something a normal user can understand.
For example:
This message is highly suspicious because it creates urgency, requests sensitive information, and threatens account access. Do not click the link or provide your OTP or password.
The model runs locally, so the AI explanation doesn't require sending the analysis to a third-party AI API.
Example: Message Analysis
Here's an example of the message analyzer detecting a phishing-style message.
URGENT! Your bank account will be blocked.
Please provide your OTP immediately at
https://example.com/login
CyberBuddy produced:
Risk: CRITICAL
Risk Score: 95/100
Possible Attack: Phishing
It also detected multiple indicators:
Urgent or pressure-based language
Credential or verification information requested
Financial or payment information requested
Account access threat detected
URL detected
The recommended actions include:
- Don't click the link until it has been verified.
- Don't provide passwords, OTPs, PINs, or verification codes.
- Don't share banking or card information.
- Verify the warning through the organization's official website or application. Gemma then explains these findings in simple language.
Example: URL Analysis
CyberBuddy can also analyze a URL independently.
For example:
http://192.168.1.10/login
The result was:
Risk: MEDIUM
Risk Score: 40/100
Hostname: 192.168.1.10
Protocol: HTTP
Detected indicators:
URL does not use HTTPS
IP address used instead of a domain name
Security-sensitive keyword detected: login
Gemma then explains why these indicators matter and provides practical guidance.
The goal isn't to tell the user:
"This website is definitely malicious."
Instead, CyberBuddy explains:
"These indicators suggest that the website may not be trustworthy. Be cautious and avoid entering sensitive information until the website has been independently verified."
That's an important distinction.
Fail-Safe AI Design
Another design decision was making the AI component optional.
If Ollama isn't running, CyberBuddy's deterministic analysis should still work.
The architecture therefore behaves like this:
Ollama available
│
▼
Risk Analysis → Gemma → Explanation
But if Ollama is unavailable:
Ollama unavailable
│
▼
Risk Analysis → Normal Result
The application doesn't depend entirely on the AI model to function.
This also keeps the security analysis predictable.
Technology Stack
CyberBuddy currently uses:
Python
FastAPI
JavaScript
HTML
CSS
Ollama
Gemma 3 4B
Pytest
Backend
The backend is built with FastAPI.
It provides endpoints for:
POST /api/analyze/message
POST /api/analyze/url
GET /health
Frontend
The frontend is a lightweight HTML/CSS/JavaScript interface.
Users can switch between:
Message
URL
and receive the analysis directly in the browser.
Testing
The project currently has automated tests covering:
- message analysis
- message risk engine
- URL analysis
- URL risk engine Current test result:
=============================== test session starts ================================
platform win32 -- Python 3.10.11, pytest-9.1.1, pluggy-1.6.0
rootdir: B:\Hacktoberfest\Cyberbuddy
plugins: anyio-4.15.1
collected 39 items
tests\test_message_analyzer.py .............. [ 35%]
tests\test_risk_engine.py ..... [ 48%]
tests\test_url_analyzer.py .............. [ 84%]
tests\test_url_risk_engine.py ...... [100%]
================================ 39 passed in 0.15s ================================
Building for a Non-Technical User
The most important part of this project wasn't just adding AI.
It was thinking about how a non-technical person would use it.
A security tool can detect dozens of technical indicators, but displaying all of them without context doesn't necessarily help someone.
CyberBuddy therefore tries to translate:
Technical Evidence
↓
Simple Explanation
↓
Practical Action
For example:
Credential request detected
becomes:
"The message is asking for sensitive information such as a password or OTP. Legitimate organizations generally shouldn't ask you to provide these through suspicious links or messages."
The goal is to make security guidance easier to understand and act upon.
What I Learned
Building CyberBuddy taught me several things beyond simply connecting an AI model to an application.
1. AI shouldn't always be the decision-maker
For security-related applications, deterministic rules can provide a predictable foundation while AI can make the results easier to understand.
2. Local AI is practical
Running Gemma through Ollama made it possible to add an AI explanation layer without requiring an external API.
3. User experience matters
A technically accurate security result isn't enough if the person using the application doesn't understand what it means.
4. Testing matters even for small projects
The project currently has:
39 automated tests
39 passing
This helped me make changes while ensuring the existing analyzers continued to work.
5. Building for a real person changes how you think
Instead of asking:
"What cybersecurity feature can I add?"
I started asking:
"What would actually help someone when they receive a suspicious message?"
That changed the direction of the project.
What's Next?
CyberBuddy is currently an MVP, so there is plenty of room for improvement.
Some things I'd like to explore next:
- Security alert/log analysis
- More sophisticated URL detection
- Additional phishing indicators
- Better AI response formatting
- More automated tests
- SOC-oriented alert explanations
- MITRE ATT&CK mapping for relevant security indicators
- More accessible UI for non-technical users
The goal is to gradually turn CyberBuddy from a simple analyzer into a more useful personal cybersecurity assistant.
Try CyberBuddy
The project is available on GitHub:
akashjha518
/
CyberBuddy
CyberBuddy is an AI-powered cybersecurity assistant that helps non-technical users analyze suspicious messages and URLs, assess security risks, and understand threats through local Gemma 3 4B AI running with Ollama.
🛡️ CyberBuddy
AI-Powered Cybersecurity Assistant for Non-Technical Users
CyberBuddy is a local, AI-powered cybersecurity assistant designed to help non-technical users understand and respond to suspicious messages and URLs.
Instead of requiring cybersecurity knowledge, CyberBuddy analyzes potentially dangerous content, identifies security indicators, assigns a risk level, and explains the result in simple language.
The project uses deterministic security analysis for risk assessment and Gemma 3 4B, running locally through Ollama, as an AI explanation layer.
🚀 Why CyberBuddy?
Cybersecurity warnings are often difficult for non-technical users to understand.
A suspicious message may contain:
- Urgent requests
- Phishing links
- Requests for passwords or OTPs
- Fake account warnings
- Financial requests
- Suspicious URLs
CyberBuddy provides a simple workflow:
Suspicious Message / URL
↓
Security Analysis
↓
Risk Assessment
↓
Evidence
↓
Gemma 3 4B AI
↓
Simple Explanation
↓
Safe Actions
✨ Features
📩 Suspicious Message Analyzer
Analyze suspicious emails, SMS messages, and…
To run the project locally, you'll need Python, Ollama, and Gemma 3 4B.
The basic AI setup is:
ollama pull gemma3:4b
ollama run gemma3:4b
Then start the CyberBuddy backend:
uvicorn backend.main:app --reload --port 8000
Open the frontend and start analyzing suspicious messages or URLs.
Final Thoughts
Cybersecurity doesn't have to be understandable only to cybersecurity professionals.
Sometimes the most useful security tool is one that simply answers:
"Here's why this looks suspicious, and here's what you should do next."
That's what I wanted CyberBuddy to provide.
I'm excited to build on this project and continue exploring how local open-weight AI can make cybersecurity guidance more accessible to everyday users.
Thanks to the Hacktoberfest Weekend Challenge: Build for a Friend for encouraging developers to build something around a genuine problem faced by someone else.
Top comments (0)