An autonomous threat detection and adaptive risk mitigation product that gives small and medium businesses security protection they couldn't otherwise afford, with LLM written alert summaries and remediation guidance that tell a team what happened and what to do next.
Overview
Cyberattacks are no longer a big company problem. Small and medium businesses run on the same cloud apps, email, and connected devices as large enterprises, often without a dedicated security team watching them, and attackers have noticed. Ransomware was present in 88% of breaches at small and medium businesses, compared with 39% at large organizations. 46% of small business owners say their current business has already been hit by a cyberattack, and when a breach happens it is expensive: the average U.S. breach cost a record $10.22 million in 2025. Small businesses needed security that was affordable, caught threats early, explained them in plain language, and told a small team exactly what to do next.
Using machine learning and generative AI, the AI Threat Detection Platform monitors a business's security data to detect threats autonomously and adapt its risk mitigation as conditions change. Its detection thresholds are tuned to catch real threats while cutting false alarms, and for every flagged threat an LLM explains what happened in plain language, using retrieval augmented generation (RAG) to pull step by step remediation guidance from a vetted security knowledge base, so the team knows what happened and what to do next.
AI Hypothesis
The bet the product was built to test:
If the AI continuously monitors a small business's security activity and flags suspicious behavior in real time, then threats can be caught before they spread, which reduces the damage and cost of a breach for companies with no dedicated security team.
Customer Research
Before writing a line of the PRD, I wanted to hear how small businesses actually experience a cyberattack, not how security vendors describe it. I led discovery interviews with the people who end up holding the problem when something goes wrong: business owners and the IT generalists who support them.
Each conversation walked through a recent security scare from start to finish: how they first noticed it, who they called, how long it took to resolve, and what it cost them. From there we explored their current tools and budget, and how much they'd let AI act on their behalf.
Interviews
20
Timeframe
2 weeks
Discussion guide
12 open ended questions
What kept coming up
Finding out too late. Attacks surfaced after the damage, not before it.
Nobody owns security. It lands on the owner or whoever handles IT part time.
Too many alarms. False positives trained people to ignore alerts, including real ones.
Alerts nobody can read. Warnings assume a security expert is on the other end.
Built for someone else. Enterprise tools are priced and designed for large companies.
Persona & Customer Journey
The interviews pointed to two groups with very different relationships to security:
IT generalists, the one person (or tiny team) who keeps everything running, with security as one job among many. They see every alert.
Business owners, who approve the budget and carry the risk but rarely touch the tools.
We built the MVP for the IT generalist. They live with the problem every day: they're the ones finding out too late, wading through false alarms, and trying to decode alerts written for a security team they don't have. If the product saves them time and earns their trust, the owner sees the result as fewer incidents and less downtime. That makes the generalist the fastest path to proving the hypothesis.
Primary persona · composite of 20 interviews
Marcus, the one person IT department
Role
IT generalist
Company
~60 employees
Reports to
The owner
Security training
Self taught
A day in his life
Marcus handles laptops, Wi-Fi, software licenses, new hire setups, and, somewhere in there, security. His mornings start with a queue of help desk requests and a pile of security alerts he doesn't have time to investigate. When something looks wrong, he searches online, makes his best guess, and hopes it was nothing.
Goals
Catch a real attack before it reaches the business
Spend less time chasing alerts that turn out to be nothing
Know exactly what to do when something is real
Show the owner that the business is protected
Frustrations
Alert noise: most warnings are false alarms
Alerts full of jargon with no clear next step
Enterprise tools that cost too much and assume a security team
Finding out about problems after they occur
Customer journey
How Marcus moves from first hearing about the product to relying on it, and where the product has to win him over at each step.
Discover
Evaluate
Set up
First real alert
Everyday use
What he does
Hears about a breach at a similar business and starts looking for help
Compares options and makes the case to the owner
Connects the business's systems and sets who gets alerts
Gets an alert, reads the summary, follows the steps
Checks alerts as part of his routine and reports to the owner
How he feels
Worried
Skeptical
Cautious
Relieved
In control
Pain points
Doesn't know where to start; vendors speak in jargon
Most tools are priced for large companies
Fears a complex setup on top of his day job
Past tools cried wolf; doesn't trust alerts yet
Alert fatigue creeps back if quality slips
How the product helps
Positioned for small and medium businesses, in plain language
Priced and packaged for a small business budget
Built to run without a dedicated security team
Real time detection with a plain language summary and next steps
Thresholds tuned to cut false positives, so alerts stay worth reading
AI Models Overview
Threat detection model
LSTM neural network
Purpose
Flag suspicious behavior in security logs and login activity as it happens.
Model characteristics
An LSTM (long short term memory) network reads events in order and remembers what came before, so it recognizes an attack as a pattern unfolding over time, such as a run of failed logins followed by a successful one from an unfamiliar place, rather than judging each event alone. Trained on labeled past incidents, with detection thresholds I tuned on the precision/recall tradeoff.
Alert summaries
Claude (LLM)
Purpose
Turn each flagged alert into a plain language explanation and step by step remediation guidance.
Model characteristics
A large language model that is strong at summarizing technical material and following strict output instructions, with a long context window for reading an alert's full activity history. I owned its prompt design and the eval set used to score its output.
RAG knowledge assistant
Claude + retrieval
Purpose
Ground remediation steps in verified guidance, and answer the IT team's follow up questions the same way, never from the model's guesses.
Model characteristics
A retrieval step first searches a knowledge base of security best practice guides and vendor documentation for the passages most relevant to the alert or question, then passes them to Claude, which builds its answer only from them. Source grounding checks, confidence thresholds, and fallback responses guard against hallucination. I worked with engineering on its retrieval architecture, and tuned and evaluated the assistant.
AI Proof of Concept
Before committing to a full build, we ran a proof of concept on a labeled set of past security incidents to answer one question: could the AI catch threats fast enough, and explain them clearly enough, for a small team to act on? We replayed known incidents through the detection model to measure how quickly it flagged suspicious behavior, tuned its thresholds on the precision/recall tradeoff to keep false alarms in check, and scored the LLM's alert summaries against an eval set with human review, checking every claim against its source. That evidence is what greenlit the MVP, with speed as the core bet.
AI Input & AI Output
AI input
Security logs: activity records from the business's systems. This is the raw signal the detection model scans for suspicious behavior.
Login activity: who signs in, when, from where, and on what device. Unusual logins are often the first sign of a compromised account.
Knowledge base: curated security guidance, searched at the moment an alert fires (RAG) so remediation steps and assistant answers come from a verified source.
Labeled past incidents: historical security events already marked as real threats or harmless activity, used to train the detection model and to test it in the proof of concept.
Reviewer feedback: the IT professional reviewing alerts marks each one as a real threat or a false alarm. Those labels keep training the model after launch.
AI output
Threat detections: suspicious behavior flagged in real time, using thresholds tuned on precision/recall to keep false alarms down.
Alert summaries: a plain language explanation of what happened, written by the LLM.
Remediation guidance: step by step instructions for what to do next.
Adaptive risk mitigation: responses that scale with the severity of the threat, from a recommended fix for low risk activity to automatic containment for high risk threats, such as locking a compromised account after a suspicious login.
Data Pipeline
I developed the data pipelines, including the RAG pipeline, and built the framework used to evaluate it. Data moves through four stages, from raw activity to an alert a small team can act on.
Collect
Security logs are gathered continuously from the business's connected systems.
Login activity is captured with who signed in, when, from where, and on what device.
Curated security guidance is loaded into the knowledge base.
Labeled past incidents form the training set for the detection model.
Prepare
Logs from different systems are cleaned and normalized into one consistent format.
Login events are compared with each user's normal patterns of time, place, and device.
Knowledge base content is split into passages and indexed for retrieval.
Detect & explain
The detection model scores activity against thresholds tuned on the precision/recall tradeoff.
Flagged activity is assigned a risk level that decides the response.
Each flagged event becomes a search query against the indexed knowledge base, and the most relevant passages are retrieved.
Claude writes the summary from the alert's own data and the remediation steps from the retrieved passages, passing source grounding checks and confidence thresholds, with a fallback response when it can't verify an answer.
Act & learn
High risk threats are contained automatically first, for example by locking the compromised account. The IT team is then alerted with the summary, next steps, and any lockout taken.
The team can ask the knowledge assistant follow up questions, answered through the same retrieval step.
Human-in-the-loop review and the eval set score the quality of every summary.
Reviewers mark each alert as a real threat or a false alarm, and those labels flow back into training, so the model gets more accurate over time.
Tech Stack
Machine learning: LSTM neural networks, which learn patterns in sequences of events, to spot suspicious behavior across log and login activity over time.
Generative AI: Claude to write plain language alert summaries and remediation guidance.
Retrieval (RAG): a retrieval pipeline that searches the indexed security knowledge base and feeds the most relevant passages to Claude, so remediation steps and assistant answers come from verified sources.
Data: Databricks for data pipelines, preprocessing, and preparing training data.
Cloud: AWS for hosting and running the platform.
System Architecture
How data moves from a business's systems to a decision: detection on the left, explanation in the middle, action on the right, and a feedback loop that keeps the model learning.
Detection path
Retrieval + generation path (RAG)
Feedback loop
Product Opportunities & Prioritization
The research surfaced three opportunities, each tied to a pain point we heard repeatedly. All three mattered, so the question wasn't whether to build them but in what order.
Speed
Monitor continuously and flag suspicious behavior in real time, so threats are caught before they spread.
Chosen as the core hypothesis.
Trust
Tune the detection model on precision and recall so it alerts only when a threat is likely, and teams don't tune alerts out.
Clarity
Use an LLM to turn each alert into a plain language summary with next steps, so nonexperts can respond on their own.
Why speed came first
Every other improvement depends on catching the threat in the first place. A clear explanation of an attack discovered days late doesn't undo the damage, and cutting false alarms only matters once detection is running. Finding out too late was also the failure with the highest cost: it's the difference between locking one account and recovering from a breach. So the MVP was built around real time detection, with thresholds tuned from day one so speed didn't come at the price of noise. Clarity followed once the detection layer was proven.
Impact vs. effort
Each candidate feature was scored on its impact for a small team without security staff, and on the effort to build it well.
Impact →Effort →
Must have high impact · lower effort
Real time detection on security logs and login activity
Risk scoring for every flagged event
Detection thresholds tuned on precision/recall
Alerts to the IT team
Automatic lockout for high risk threats
A mobile app for alerts and response
Major projects high impact · higher effort
LLM alert summaries built on Claude, with RAG grounding, guardrails, and an eval set
Knowledge assistant for follow up questions
Reviewer feedback loop that retrains the model
Quick wins later lower impact · lower effort
Custom alert settings: who gets notified, and how
Monthly security summary for business owners
Not for the MVP lower impact · higher effort
Custom integrations for niche tools
Product Roadmap
I built the product strategy and roadmap around the company's mission. As the company acquired several businesses, I set up its Agile process, cross functional collaboration framework, and master roadmaps. The roadmap followed the prioritization: catch and contain threats first, then make alerts understandable, then help the team respond and let the model learn.
Phase 1 · MVPDetect & contain
Phase 2Explain
Phase 3Assist & learn
Go-to-marketLaunch
AI & data
Databricks pipelines for logs and logins
LSTM trained on labeled incidents
Thresholds tuned on precision/recall
Claude alert summaries
RAG pipeline and knowledge base index
Guardrails and eval set
Reviewer feedback retrains the model
Model monitoring
Product
Real time detection
Behavior baselines
Risk scoring and alerts
Automatic lockout for high risk threats
Mobile app for alerts
Plain language alerts with remediation steps
Knowledge assistant
Launch readiness
Research & GTM
20 discovery interviews
Proof of concept on past incidents
User acceptance testing before launch
A/B testing on feature usage depth
Pricing and positioning
Sales enablement with Marketing
Phase 1 · MVPDetect & contain
Data foundation
Connect log sources
Capture login events: who, when, where, device
Normalize data in Databricks
Build per user behavior baselines
Detection model
Assemble labeled incident set
Train the LSTM
Proof of concept on past incidents
Tune thresholds on precision/recall
Define risk levels
Alerting
Risk scoring for flagged events
Alert delivery to the IT team in the mobile app
Alert format v1
Automatic containment
Define the high risk policy
Automatic account lockout
Report the lockout in the alert
Discovery
20 customer interviews
Persona and journey map
PRD v1
Validation
User acceptance testing before launch
False lockout checks
Phase 2Explain
Knowledge base
Curate best practice guides and vendor docs
Split and index passages
Tune retrieval relevance
LLM summaries
Prompt design
Summary from alert data
Remediation steps from retrieved passages
Consistent alert format
Safety & evaluation
Source grounding checks
Confidence thresholds
Fallback responses
Eval set and human review
Testing
A/B test feature versions with live customers
Measure feature usage depth
Phase 3Assist & learn
Knowledge assistant
Follow up questions through retrieval
Reuse guardrails for answers
Feedback loop
Real threat / false alarm labels
Retraining pipeline
Go-to-marketLaunch
Launch
Launch strategy
Pricing
Positioning
Sales enablement with Marketing
User Stories & Acceptance Criteria
The stories follow the two groups from research: the IT generalist who handles the alerts, and the owner who carries the risk. Each one ties back to a pain point from the interviews, and each acceptance criterion is something the team could test before calling the feature done.
Area
User story
Acceptance criteria
OnboardingMVP
As an IT generalist, I want to connect our systems and set up alerts quickly so that protection starts on day one without becoming another project on top of my day job.
Log sources and login activity connect through a guided setup
I choose who receives alerts, and on which device, including the mobile app
Detection starts as soon as the first systems are connected
DetectionMVP
As an IT generalist, I want suspicious activity flagged as it happens so that I can step in before a threat spreads to other accounts or systems.
Security logs and login activity are scored continuously, not in daily batches
Every flagged event gets a risk level
Detection thresholds meet the precision and recall targets set during the proof of concept
Login monitoringMVP
As an IT generalist, I want to know when a login doesn't match how that person normally signs in so that I can catch stolen passwords before they're used against us.
Each login is compared with the user's baseline for time, location, and device
A login that breaks the pattern is flagged with the reason it looked unusual
Normal variation, like a known laptop on a new network, doesn't trigger an alert on its own
Automatic lockoutMVP
As a business owner, I want a compromised account locked right away, even when no one is watching, so that a break-in at 2 a.m. doesn't become a breach by morning.
High risk threats lock the affected account automatically, before the alert is sent
The alert tells IT which account was locked and why
IT can unlock the account in one step if it was a false alarm
Low risk activity is never locked, only flagged with a recommended fix
Alert summariesPhase 2
As an IT generalist, I want each alert explained in plain language so that I can tell what happened and how serious it is without being a security expert.
Each flagged event comes with a short summary written from the alert data
The summary states what happened, which account or system was affected, and the risk level
Every claim in the summary can be traced back to the underlying event
Remediation stepsPhase 2
As an IT generalist, I want clear next steps with every alert so that I know exactly what to do instead of searching vendor docs.
Next steps are drawn from retrieved best practice guides and vendor documentation
Each step links to the source passage it came from
When no reliable guidance is found, the alert says so and gives a safe default instead of guessing
Knowledge assistantPhase 3
As an IT generalist, I want to ask follow up questions about an alert so that I can handle an unfamiliar threat without calling in outside help.
Questions are answered from the knowledge base through the same retrieval step
Answers pass the same guardrails as alert summaries
The assistant says when it doesn't know rather than making up an answer
Feedback loopPhase 3
As an IT generalist, I want to mark an alert as a real threat or a false alarm so that the product gets smarter about my business and sends fewer false alarms over time.
Every alert can be marked real threat or false alarm in one step
Labels flow into the training data and the eval set
Retrained models are checked against the eval set before they replace the current one
Risks & Mitigation
A security product has two ways to fail: it misses an attack, or it gets in the way of the business it's protecting. Each risk below was rated on how much damage it would do and how likely it was, and each mitigation was built into the phase that introduced the risk.
Risk
What could go wrong
Impact
Likelihood
Mitigation
Missed threats
The model fails to flag a real attack, and the business finds out too late, the exact failure the product exists to prevent.
High
Medium
Thresholds tuned on precision and recall from the proof of concept, an eval set built from labeled incidents, and reviewer feedback that retrains the model on what it missed
False lockouts
A legitimate employee is locked out of their account, which stops work and costs the product the owner's trust.
High
Medium
Automatic lockout only for high risk threats, low risk activity flagged but never locked, one step unlock for IT, and false lockout checks in user acceptance testing
Alert fatigue
Too many false alarms train the IT team to ignore alerts, including the real ones.
Medium
High
Detection thresholds tuned on precision/recall tradeoffs (−17% false positives), risk levels on every alert, and false alarm labels fed back into training
AI hallucination
The LLM states something about an alert that isn't supported by the data.
High
Medium
Source grounding checks, confidence thresholds, fallback responses, and human-in-the-loop review
Wrong or outdated guidance
Retrieval pulls a passage that doesn't fit the threat, or guidance that is out of date, and IT follows the wrong fix.
Medium
Medium
A curated knowledge base of vetted guides and vendor docs, retrieval relevance tuning, a source link on every step, and a safe default when no reliable guidance is found
Sensitive data exposure
Security logs contain employee and customer details that could leak while being processed.
High
Low
Only flagged events are sent to the LLM, never the full log stream, and all data stays inside the AWS environment
Model drift
Attack patterns change over time, and a model trained on past incidents slowly loses accuracy.
Medium
High
Continuous retraining from reviewer labels, with every new model checked against the eval set before it replaces the current one
Business Model / Lean Canvas
I defined launch and go-to-market strategy with Marketing, including pricing, positioning, and sales enablement. The canvas below sums up the business on one page.
Problem
Attacks are discovered too late, after they've spread
Nobody on staff owns security
Too many alarms, and alerts nobody can read
Existing alternatives
Enterprise tools and managed security services priced and built for large companies, or basic antivirus and hoping for the best
Solution
Real time AI threat detection
Automatic lockout for high risk threats
Plain language alerts with next steps
Key metrics
Time to detect
False positive rate
Analyst triage time
Unique value proposition
A patented security product built for small businesses, instead of one enterprise tool sold to every company size: threats caught as they happen, compromised accounts locked automatically, and every alert explained in plain language.
Channels
Managed service providers (MSPs) that run IT for small businesses
IT solution partners
Direct sales to business owners
Content marketing and webinars on small business security
Customer segments
Small and medium businesses with no dedicated security team
Early adopters
Companies of roughly 60 employees where one IT generalist handles everything
Cost structure
Cloud infrastructure on AWS
Databricks data platform
LLM usage for alert summaries
Engineering, data science, and go-to-market teams
Revenue streams
Monthly or annual subscription, priced per user, with simple size based tiers for small businesses
Tiered plans, with LLM summaries and the knowledge assistant in higher tiers
Partner pricing for MSPs and IT solution partners who bundle it into their services
Annual contracts at a discount
AI Product Scalability
Each new customer brings more logins, more logs, and more alerts. The product was designed so that growth makes it more accurate instead of more expensive or less reliable.
Data that grows with the customer base
New customers connect through the same ingestion and normalization pipeline in Databricks, so onboarding a business doesn't mean building anything new. Behavior baselines are learned per user, so each business's version of "normal" stays its own as the platform grows.
A model that improves with use
Every alert a reviewer marks as a real threat or a false alarm becomes training data, so detection gets sharper the longer a business uses the product. Each customer's data stays separate: one business's security logs are never used to train detection for another, which is a promise security buyers expect. Every retrained model has to beat the current one on the eval set before it goes live, and accuracy is monitored for drift as attack patterns change.
LLM costs tied to alerts, not data
Claude only sees flagged events, never the full log stream. Log volume can grow many times over while LLM usage grows only with the number of alerts, which keeps cost per customer predictable and fits the per user pricing.
Knowledge that updates without retraining
Because remediation guidance comes from retrieval, keeping it current means adding or replacing documents in the knowledge base and reindexing them. New threats and new vendor guidance reach every customer without retraining a model.
Results
I developed the MVP of the machine learning threat detection platform and wrote the PRD that shipped LLM generated alert summaries and remediation guidance. Measured through user acceptance testing and A/B testing, where the analyst is the IT professional who reviews and responds to alerts:
