Sentinel Inbox

Inspiration

Phishing is still the #1 way attackers get in, and AI has made it worse: flawless lookalike emails, CEO gift-card scams, and messages that say "your manager just called you." Most "AI security" tools are a chatbot you have to trust blindly. I wanted a triage tool that shows its work, runs locally, and needs no paid API.

What it does

Sentinel Inbox takes a pasted email or a raw .eml file and returns a risk verdict, the attack type, evidence, recommended actions, a safe reply draft and an exportable incident report. Every finding points to the exact text, link or header that triggered it, and Locate in email highlights it in the message.

How I built it

• Fine-tuned local model: a MiniLM transformer fine-tuned in PyTorch with two heads, one for the phishing probability and one for the attack type. It's calibrated, quantized to int8 (23 MB) and runs in Node via ONNX Runtime in about 12 ms per email.
• Explainable rules: detection of lookalike and Unicode-homograph domains, deceptive or obfuscated URLs, Reply-To mismatches, SPF/DKIM/DMARC results (read only from real headers), credential and payment requests, urgency, risky attachments and prompt injection.
• Hybrid agent: the pipeline parses the email, runs the rules and the model, retrieves similar labelled examples, combines everything under a fixed policy, and validates the output schema. If the model is unavailable, it falls back to rules only and says so.
• Stack: Next.js 14, TypeScript and Tailwind, deployed on Vercel.

Training data and evaluation

I trained on the public-domain SpamAssassin corpus plus synthetic attack emails from a documented generator. I tested on a separate set of hand-written emails that was never used in training.

Attack-type F1 is 0.83. On the full benchmark of 82 held-out, demo and adversarial emails, the hybrid scored F1 0.992. Appending prompt-injection text to 54 malicious emails changed none of the verdicts.

Challenges

• My first model read raw headers and flagged a genuine sign-in alert as 99.8% phishing. Restricting it to the parsed, visible email brought that down to 1.1%.
• Regression tests found inputs that took over 40 seconds to analyze, which I fixed.
• Keeping false positives low on legitimate but urgent emails.

What I learned

A small specialized model plus transparent rules can beat a general-purpose LLM for this task, and measuring against baselines matters more than claims.

Limitations and what's next

The test set is small (58 challenge emails), and the robustness attacks are scripted rather than adaptive. Next I want more real-world data, Outlook and Gmail add-ins, and better separation of invoice fraud from voice-clone attacks.

Built With

• minilm
• next.js
• onnx-runtime
• python
• pytorch
• react
• tailwindcss
• transformers
• typescript