Where it started

CyberCube began as our major project. We could have built another full-stack app, but we wanted to try something different, so we moved into cybersecurity as an experiment. This post covers what we built and what its numbers do and do not mean.

From packets to alerts

Traffic can enter the platform in two ways:

• PCAP upload. You drag a packet-capture file into the web app. A parser I wrote unpacks the binary data field by field, reading the Ethernet, IP and TCP headers by hand. It then groups packets into two-way flows and runs the model on each one.
• Live capture. The sniffer tries to capture packets directly from the machine's network interface. That needs administrator privileges. When they are missing, it falls back to generated traffic so the live view keeps working. That fallback is meant for demos, not as real capture.

Detected threats appear on a React dashboard through a WebSocket connection (/ws/threats), so new alerts arrive without refreshing the page. The dashboard includes alert tables and a global threat map that plots where attackers appear to come from.

The dataset, and an honest caveat

Training a detection model needs labelled traffic. I generated a dataset of 12,000 records with 22 features, designed to follow the CIC-IDS2017 schema, and included attacker locations and MITRE ATT&CK labels. The data is synthetic. That means the accuracy numbers below show the pipeline works from end to end, but they are not a claim about performance on real-world traffic.

Choosing a model

I needed a classifier that is accurate, fast, and explainable, because analysts will only act on alerts they trust. I benchmarked four on an 80/20 split of the data (2,400 test samples):

• Gradient Boosting matched the accuracy but was about 1.8 times slower, roughly 30 microseconds per prediction against 17.
• The neural network was faster but less accurate, and hard to explain.
• Logistic Regression was the fastest but the least accurate.
• Random Forest gave the best balance.

I deployed Random Forest: about 99.5% accuracy, 99.37% macro-F1, around 17 microseconds per prediction, and explanations that show why each flow was flagged.

Explaining every alert

A label like "DDoS, 98% confidence" is not enough for an analyst, so each alert comes with more:

• SHAP waterfall charts. SHAP shows which features of a flow, such as the timing between packets or the count of TCP flags, pushed the model toward "attack" or "benign".
• MITRE ATT&CK mapping. Each threat type is tagged with a standard technique ID. For example, DDoS maps to T1498, port scans to T1046, brute force to T1110, web attacks to T1190 and botnet traffic to T1071.
• Plain-language summaries. The Gemini API turns an alert into a short root-cause explanation, sent through a backend proxy so the key stays on the server.

From detection to response

CyberCube also helps you act:

• Firewall rules. One click generates commands to block an attacker's IP: netsh advfirewall for Windows, iptables for Linux, and rules for Suricata and Snort.
• PDF incident reports. A report contains the severity, attacker location, MITRE technique, all 22 flow metrics, the SHAP-based root cause, and a space for the analyst's signature.

Multi-tenancy and deployment

Several organizations can use the same platform without seeing each other's data. Users sign in with Google OAuth, and every threat record carries a tenant key derived from the user's email using HMAC. Session tokens are signed and expire after 12 hours, and the WebSocket only delivers alerts that match the connected user's key.

The backend is FastAPI with SQLAlchemy, using SQLite by default and PostgreSQL (Neon) in production. A script injects sampled flows from the dataset into the system on a schedule, run by GitHub Actions, which keeps the dashboard populated. The app is deployed on Render and Vercel.

What I would improve next

• Train and test on real CIC-IDS2017 data and compare it with the synthetic results.
• Test the live sniffer on real network traffic instead of relying on the demo fallback.
• Add more attack types beyond the five currently mapped.
• Write automated tests for the PCAP parser and the prediction pipeline.

Takeaways

A detection model is only useful if an analyst can trust it and act on its output. The explanations, the standard threat labels and the ready-made firewall rules were as much of the project as the classifier itself. And being clear about what synthetic data can and cannot prove makes the results more believable.

• Live app: ai-powered-cyber-threat-detection-soc.onrender.com
• Code: github.com/NartanNaik/CyberCube
• Stack: Python, Scikit-learn, FastAPI, React, PostgreSQL, SHAP, Gemini API

The problem: a codebase does not fit in a prompt

The obvious fix is to send the whole repository to an AI model. That fails quickly. On a large raw repository, the input came to about 6.45 million tokens, far beyond any model's context window. My early attempts with a big project like CyberCube ended with an AI telling me it was too huge and to try a smaller one.

That is not a useful answer for a tool whose job is to understand big projects. So the real problem became deciding what the model should never see.

The scanner: cutting 98% of the noise

Most of a repository is not worth reading. Build artifacts, binaries, lockfiles and generated files add size and no understanding. I wrote a custom scanner in Python that:

• Skips ignored directories, file names and extensions (build output, binaries, lockfiles).
• Enforces size caps on individual files, on the raw upload and on the final text sent to the model.
• Ranks files by importance so the most useful code is kept when the cap is reached.

That is a 98% reduction in model input, and it removes the context-window failures.

Three ways to bring in code

• Folder picker. The browser reads the folder directly. The files are filtered on the client side first, so less data is uploaded, and then zipped with JSZip.
• ZIP upload. The archive is opened in the browser, filtered, and zipped again.
• GitHub URL. The backend fetches a public repository, up to a size limit, and processes it the same way.

Four depths of analysis

Not every question needs a 20-page report, so Unpack offers four analysis depths. Each uses its own prompt and token budget, and the backend picks a model to match:

1. Quick Summary: a short overview of what the project is.
2. Standard Architecture: the main components and how they connect.
3. Deep Dive: everything: stack, data flow, schema, file breakdown.
4. Diagnose: a full audit that also lists security and technical-debt issues.

Streaming the answer

A detailed analysis takes a while to generate, so the backend streams it back as newline-delimited JSON events instead of making you wait for one big response. There are four event types: delta carries new text, ping shows the model is still working, done returns the final report, and error reports failures. On the frontend, a small XMLHttpRequest helper tracks both the upload and the streaming response, so the user sees live progress.

Accounts and cost control

Users sign in with Google or GitHub through Supabase Auth. The first time someone logs in, the backend validates their session, creates an OpenRouter key for that user capped at $0, and stores it in Supabase along with a SHA-256 hash of the key. The key is tied to the user's email, so each person gets their own.

A $0 cap means free models only, so the app cannot produce a surprise bill, and one person's usage cannot use up another's allowance.

Users can also choose between two modes: Temp, where the analysis is not saved, and Persistent, where it is stored in a history table in Supabase so they can come back to it.

Exporting in the browser

Reports can be downloaded as PDF, DOCX or PPTX. All three are generated entirely in the browser, with jsPDF, docx and pptxgenjs, so nothing goes through the server. Every export has the same branding: a purple and gold watermark, an UNPACK footer and page numbers.

Nothing in this project was dramatically hard, but the PDF was the fiddliest, and generating the watermark for all three formats took more time than I expected.

Does it work?

Yes, and I can prove it with my own projects. The architecture notes I keep for CreatorLens AI and CyberCube were generated by Unpack. They include the system architecture, tech stack, database schema, features, file breakdown and a list of technical-debt issues, and that is exactly what I built it to produce.

What I would improve next

• Add rate limiting to the key-provisioning and analysis endpoints.
• Redact secrets such as API keys from source files before they reach the model.
• Add automated tests, starting with the scanner's filtering rules.
• Validate uploaded archives more strictly, beyond checking their size.

Takeaways

With LLM apps, deciding what not to send matters as much as the prompt. Filtering the input removed 98% of the tokens and made large repositories workable, and it came from understanding what a model actually needs to see to describe a project.

• Live app: unpack-tau.vercel.app
• Code: github.com/NartanNaik/Unpack
• Stack: React, FastAPI, Python, Supabase, OpenRouter

Step one: pasting usernames by hand

I started by pasting each creator's username into the app one at a time. That worked for ten profiles and became painful at a hundred.

So I added mass upload: collect usernames in a list, then add them all at once. It was faster, but I was still filling in every attribute myself, and that took even longer than collecting the names.

Step two: letting AI fill in the details

I connected the Gemini API so I no longer had to type attributes like nationality by hand. The AI reads the categories I have defined and fills them in for each profile. The part I like most is that if I add a new column, the AI fills that one in too, so the schema is not hard-coded.

Step three: a mobile app with a share button

The workflow was still slow because I had to open the web app and enter things. So I built a Flutter mobile app with a built-in share target. When I find a creator's reel, I share it to my app the same way I would send a reel to a friend, and it lands in the website's queue. The app signs in with Google, stores tokens securely on the phone, and sends the URL to the REST API with a bearer token.

It was better, but each share still took more than 5 seconds from tapping share until the app closed itself.

Step four: the Garbage Eater

While working on the app I had been saving reels, and I realised those saved reels were already a list of everything I wanted to add. So I used a scraper to export all my saved reels as a JSON file, then built a feature to paste that JSON in and import everything at once. I named it the Garbage Eater, because I throw a big messy file at it and it sorts everything out.

Now my whole job is to save a reel and keep scrolling. Everything else happens afterwards, with each reel taking under a second in my own use.

CreatorLens now has four ways to add profiles:

The staging pipeline

Raw URLs do not go straight into the main database. They pass through a staging queue, which is a two-step pipeline:

1. Queue. A shared reel (URL, username, thumbnail, caption) is saved in a staging collection and the request returns immediately.
2. Process. A separate request enriches that item: it fetches metadata such as followers, likes, comments and views, and runs the AI step. After that, I approve the item and it moves into the main profiles collection.

Splitting it this way means no single request has to do everything, and it lets me review items before they become real profiles.

Hitting Vercel's 10-second limit

I first hit Vercel's 10-second function limit with the Garbage Eater. Small files were fine, but a large JSON file took too long to process in one request, and the request was cut off.

The fix was to break the work into batches. The importer now sends items in chunks of at most 50 per request, and the staging pipeline processes them separately, so each request stays well inside the limit. The batches are throttled as well, so a big import does not flood the database.

Protecting a free-tier database

I run on Firestore's free tier, so every read and write counts against a daily quota. Three things keep usage down:

• A Bloom filter is a small in-memory structure that answers "have I seen this username before?" without touching the database. It can say "probably yes" by mistake, but it never says "no" for something it has seen, which makes it a safe quick check. Because it skips a database read, it is faster and saves quota.
• Per-route rate limiting caps how often each group of endpoints can be called. For example, mass upload allows 60 requests a minute, bulk actions 30, and the video refresh job only 5.
• Chunked, batched writes group many writes into transactions instead of sending one write per profile.

The Bloom filter has a limit I should be honest about: it lives in memory on each running server instance and is not loaded from the database. After a restart, or on another instance, it starts empty, so it reduces duplicates and database reads but does not guarantee zero duplicates.

A security detail worth sharing: column names

Because users can create custom columns, those column names end up in database queries. Firestore treats a dot in a field name as a path into nested data, so a malicious name could write to places it should not reach. A validation step now allows only letters, numbers, underscores and hyphens in column names, and I added middleware that blocks NoSQL and dot-notation injection before any input reaches a query.

The rest of the API follows the same careful approach:

• Short-lived JWTs with refresh-token rotation, so a leaked token expires quickly.
• AES-256-GCM encryption for sensitive fields.
• Google OAuth sign-in with per-user data isolation, so no one can see another user's profiles.

What I would improve next

• Share duplicate checks across server instances, so deduplication survives restarts.
• Add automated tests. The project currently has none, and the importer and staging logic would benefit most.
• Stream-parse very large JSON files instead of loading them whole.
• Move long-running enrichment to a proper background job queue.

Takeaways

Most of this project was removing the slowest step, one step at a time: first typing, then pasting, then AI, then the phone, and finally the importer. A serverless time limit does not have to block you if you split the work into small, separate requests.

• Live app: createrlens.vercel.app
• Code: github.com/NartanNaik/CreaterLens
• Stack: React, Node.js, Express, Firebase Firestore, Flutter, Vercel, Gemini API