Most defenses against adversarial LLM attacks target one point in the pipeline — clean the training data, or harden the model, or filter the output — and attackers adapt around whichever single barrier is in front of them. This framework instead layers defense across three independent stages: data sanitization at ingestion (catching poisoned samples before they ever reach training), adversarial training during model development (exposing the model to perturbed inputs so it generalizes past them), and runtime backdoor detection at inference (flagging trigger-pattern inputs even if they slipped past the first two layers). An attacker now has to defeat three separate mechanisms instead of one.

Validated with a proof-of-concept on DistilBERT and GPT-2, simulating data-poisoning and backdoor attacks and benchmarking robustness against FGSM, PGD, and DeepFool adversarial methods on IMDB and AG News. The result won Best Paper at ICEIBT Conference 2026 and is currently under review for WoS publication. As LLMs get embedded deeper into production systems, single-point defenses that only catch known attack signatures are a shrinking target — the bet here is that resilience has to come from the architecture of the defense, not any one perfect filter.

Plain LLM chatbots hallucinate confidently, and bolting on retrieval doesn't fully fix that — if the system always answers from whatever got retrieved, irrelevant context gets treated as gospel just as often as good context does. This project puts a routing layer in front of generation: per query, it decides whether to answer from retrieved context, call an external API for something that needs to be current or exact, or escalate to a specialized module rather than force a generic LLM answer.

That routing decision is the actual engineering problem — it's effectively a lightweight orchestrator sitting in front of the model rather than treating the LLM as the whole system. The architecture is also naturally extensible: new tools or data sources can be added at the routing layer without retraining or fine-tuning anything, which is closer to how production LLM systems are actually built than a single-shot RAG demo.

Honeypots generate huge volumes of attack telemetry, and most of it is noise — the hard part isn't collecting the data, it's turning raw network/host event logs into features a model can actually learn from. This project engineers those features from AWS honeypot data and trains a Random Forest classifier to separate benign activity from malicious traffic, reaching over 91% accuracy.

The practical value is triage: a pipeline like this is what would sit in front of a security operations workflow, automatically surfacing the honeypot hits worth a human's attention instead of requiring someone to review every single one manually. It's the ML-modeling half of security work — evaluation methodology and feature engineering — kept deliberately separate from the cross-phase-defense-framework research, which is about LLM-specific attack surfaces rather than network intrusion detection.

Most malware scanning happens after a file is already sitting on disk. FileGuard intercepts earlier — it injects inline "Scan" buttons directly into the Gmail UI via DOM observation (MutationObserver), so the check happens before the attachment ever touches your machine, and queries VirusTotal's multi-engine analysis for a verdict.

The engineering constraints are what make it more than a wrapper around one API call: attachments are hashed client-side (SHA-256) rather than uploaded anywhere, so the file itself never leaves your machine — only its hash does, which matters for privacy and for staying inside VirusTotal's free-tier upload limits on large files. A rate-limiting queue keeps the extension inside VirusTotal's request quotas, a batch "Scan All Attachments" mode handles multi-attachment emails with per-file progress and a summary report, and a settings panel lets users manage their own API key via the Chrome Storage API rather than hardcoding one.

Electronic voting has two goals that are normally in tension: auditability (anyone should be able to verify the tally is honest) and anonymity (no one should be able to link a person to their vote). This project satisfies both at once rather than picking one. Auditability comes from a Proof-of-Authority chain where a block is only accepted once a configurable quorum (default 5 of 7) of HMAC-SHA256-signed validators agrees — no single party, including the system operator, can unilaterally rewrite the ledger. Anonymity comes from a coin-based model: each registered voter receives one spendable "voting coin" at registration, and only an anonymous token — never the voter's identity — is what actually gets written to the chain when that coin is spent.

That coin model also enforces one-vote-per-person at the data layer, not just the UI layer — meaning even if someone found a way around the frontend's session checks, the underlying ledger structure would still refuse a second vote from an already-spent coin. An admin/validator dashboard shows live tallies computed directly from the blockchain (not a separate database, avoiding any drift between "what's displayed" and "what's actually on the chain") plus full chain-integrity verification.

Grew directly out of a pattern I kept hitting during my Entab internship, building near-identical school websites over and over: the components you need almost always already exist somewhere in an old codebase, but finding them means either remembering exact file names or grepping through dozens of unfamiliar repos. This tool indexes reusable UI sections across a whole library of React codebases and makes them searchable by what a component does, not what it's named — a semantic search layer built on Sentence-Transformer embeddings and FAISS, so "staff directory grid with photos" finds the right component even if it was never labeled that.

The harder problem underneath is safe merging. Pulling components from different codebases risks CSS collisions and structurally invalid JSX if you naively concatenate files, so this uses automatic CSS selector scoping and a client-side, AST-based JSX merger built on Babel to combine components into one valid file — deliberately avoiding regex-based string manipulation, which breaks in ways that are hard to predict. I also evaluated using an LLM to do the merging and decided against it: an AST-based parser gives deterministic, structurally guaranteed correctness that a generative model can't promise, which matters when the output is going straight into a production website.

Most people first learn BFS, DFS, and Dijkstra's algorithm from static diagrams and a final answer — this notebook game instead lets you place obstacles and weight edges on a campus-style graph and watch each algorithm's frontier expand step by step. That makes the trade-offs concrete instead of theoretical: BFS explores level-by-level regardless of cost, Dijkstra's accounts for edge weight and finds the true shortest path, and DFS can commit to a path early and miss the optimal one entirely — differences that are easy to state and hard to feel until you watch them happen side by side on the same graph.