Personal Project
A deliberately vulnerable LLM-enabled Flask application, built to demonstrate a real cross-user data leakage vulnerability class and then measure three progressively stronger defenses against it: identity trust, context isolation, input risk inspection, output redaction, and structured security logging. The vulnerable baseline is preserved unmodified so the 'before' stays real and reproducible; the defended modes are implemented alongside it, not in place of it, so the same attack set can be replayed against all three and compared directly.
Independent, self-built personal project against a real vulnerable application -- distinct from the separate CIS*6510 MSc course project, which evaluates a controlled, synthetic-data mock-LLM app and reports its own, different results.
Outcome: Unauthorized cross-user disclosure measured at 25% under the original vulnerable baseline, dropping to 0% once context isolation is added (Partial Defense) -- the full Defense-in-Depth mode adds pre-model risk-based blocking, output redaction, and resolves identity from a server-side session token rather than a client-declared field, which is what stops a separate identity-spoofing (IDOR) vector the first two modes both leave open.
- Unauthorized disclosure rate -- Vulnerable Baseline:
- 25% (3/12 adversarial cases)
- Unauthorized disclosure rate -- Partial Defense (context isolation only):
- 0% (0/12 adversarial cases)
- Unauthorized disclosure rate -- Defense in Depth:
- 0% (0/12 adversarial cases)
- Identity-spoofing (IDOR) case blocked:
- Only Defense in Depth (1/1); Baseline and Partial Defense both allow it
- Adversarial requests blocked before reaching the model -- Defense in Depth:
- 33% (4/12)
View repository →Research
Completed MSc thesis research applying Adaptive Moving Target Defense (AMTD) to secure LLM-enabled systems against prompt injection, jailbreak attempts, and sensitive data leakage. The design compares three conditions -- an undefended baseline, a static (fixed-defense) baseline, and an adaptive AMTD condition -- across 72 unique external attacks drawn from three independent red-team tools (24 from Promptfoo, 24 from NVIDIA garak's PromptInject module, 24 from Microsoft PyRIT), for 216 completed primary adversarial tests across the three defense conditions.
The AMTD architecture pairs a lower-cost local model (Qwen2.5-0.5B-Instruct, run in Google Colab) with a stronger hosted model (GPT-OSS-120B, via Hugging Face/Groq routing), escalating requests between them based on a calibrated risk score. Defensive layers include dual input detectors, prompt-template rotation, RAG-policy rotation, bounded decoding, input quarantine, output inspection, and selective model escalation -- combined to reduce attacker predictability rather than relying on any single static control. Evaluation used a multi-judge methodology across Promptfoo, NVIDIA garak, and Microsoft PyRIT, with a separate validation pass on a High-Privilege Agent scenario to test how the system handles naturally Critical-severity requests.
Outcome: AMTD reduced attack success rate (ASR) from a 38.9% undefended baseline and a 48.6% static-defense baseline down to 2.8%, blocking 70 of 72 attacks -- a 36.1 percentage-point reduction vs. the baseline and 45.8 points vs. the static defense. Of 29 attacks escalated from the local to the hosted model under the risk-based routing policy, 28 were genuine unsafe cases, and 100% of those genuinely unsafe escalated cases were successfully rescued or blocked. On a held-out set of 12 benign final-test tasks, AMTD matched the 75% baseline task-completion rate with no false refusals. A separate High-Privilege Agent validation (15 naturally Critical-severity attacks) showed all 15 routed immediately to the hosted model and all 15 blocked -- a 0% ASR on the Critical route.
- Adversarial test scope:
- 72 unique external attacks (24 Promptfoo, 24 NVIDIA garak PromptInject, 24 Microsoft PyRIT) across 3 defense conditions = 216 completed primary adversarial tests
- Attack success rate (ASR) — Baseline (undefended):
- 38.9%
- Attack success rate (ASR) — Static defense:
- 48.6%
- Attack success rate (ASR) — AMTD:
- 2.8% (70/72 attacks blocked)
- ASR reduction:
- 36.1 percentage points vs. baseline; 45.8 percentage points vs. static defense
- Output-routing guard performance:
- 96.6% precision, 73.7% recall
- Model-escalation accuracy:
- 29 attacks escalated to the hosted model (Model B); 28/29 were genuine unsafe cases; 100% of genuinely unsafe escalated cases were rescued or blocked
- Benign-task utility:
- 75% task-completion on 12 held-out benign tasks under AMTD, matching the 75% baseline rate, with no false refusals
- High-Privilege Agent validation (Critical-severity route):
- 15/15 naturally Critical attacks routed immediately to the hosted model; 15/15 blocked (0% ASR)
Academic Project
A controlled, Flask/Python mock-LLM web application built with synthetic data for a graduate course project (CIS*6510) analyzing data leakage attacks and defense-in-depth mechanisms in LLM-enabled web applications. Two attack classes were tested: cross-user data leakage and prompt injection. Three defensive layers were implemented -- Context Isolation (restricts model access to only the data a user is authorized to view), Prompt Sanitization (detects and filters malicious or manipulative user inputs before they reach the model), and Response Redaction (masks or blocks sensitive information if the model attempts to expose it in its output) -- and evaluated across 8 defense configurations (every combination of the three layers on/off) against both attack classes.
This is a distinct, earlier, controlled academic evaluation using synthetic data in a mock-LLM environment -- separate from the independently built and measured LLM Data Leakage Lab (a personal project against a real, self-built vulnerable Flask app), which reports its own, different numbers.
Outcome: Final result: under the vulnerable baseline configuration, both attack classes (cross-user data leakage and prompt injection) succeeded. Under the full three-layer defense configuration, both attack classes were blocked. Across the 8 evaluated configurations, no individual layer alone was sufficient to stop both attack classes -- the combined, layered defense-in-depth configuration provided the strongest protection, the same architectural pattern independently measured end-to-end in the separate LLM Data Leakage Lab.
Academic Project
A course final project building a triage application for suspected AI-generated (deepfake) audio and video evidence, exploring how investigators could systematically assess such evidence rather than relying on ad hoc review. The application performs SHA-256 hashing to preserve evidence integrity, extracts metadata, applies rule-based triage to identify indicators warranting further investigation, and produces structured forensic findings.
Outcome: Final grade: 95/100 (Digital Forensics course capstone project).
Academic Project
A threat intelligence project classifying malware samples by their associated Advanced Persistent Threat (APT) groups using opcode-based analysis. Workflow: Dataset Creation (extracted and cleaned opcode text from malware samples, mapped each to its corresponding APT group, building a structured dataset of file hashes, APT labels, and opcode text features); Feature Engineering (converted opcode sequences into numerical features using unigram and bigram representations); Model Training (trained and compared multiple classifiers -- Support Vector Machine, K-Nearest Neighbours, and Decision Tree); Evaluation (assessed performance using accuracy, precision, recall, F1-score, and confusion matrices); and a Threat Intelligence Focus exploring how malware behaviour patterns can support attribution and help analysts connect samples to known adversary groups.
Outcome: Reinforced the applied value of machine learning in cyber threat intelligence -- malware triage, pattern recognition, and early-stage attribution support.
Commercial ProductPRE-LAUNCH
Independent, commercial SaaS product for service businesses, automating customer retention and recurring-service engagement: automated service reminders, customer follow-up, appointment/booking flows, recurring-customer engagement, and AI-assisted customer interactions. Amalachukwu is the primary product builder and owner. The product spans multiple application surfaces in a single monorepo/workspace architecture: a marketing/onboarding site, a customer application/dashboard, an admin surface, a booking flow, an embeddable widget, and an API.
Currently at production-readiness / pre-launch stage -- built and hardened as a real product, not yet claiming an established customer base.
Product-security work, approached from both the builder and AppSec sides: replacing demo/fake auth with real authentication (Supabase Authentication) including email verification and a secure sign-in/session flow; tenant/membership boundaries and role-based access control built on the principle of least privilege, enforced at the database layer with row-level/data-access controls rather than only in application code; removal of insecure client-side/admin shortcuts left over from earlier prototyping; secure environment-variable and secret handling, including application encryption-key handling; Stripe webhook signature verification; audit logging and structured, redacted application logging; permission-gated administrative actions; authentication regression testing; canonical production-domain/session consistency; onboarding entitlement and billing/trial-state validation; health/readiness endpoints; and a production-readiness security review before launch.
Outcome: A production-readiness security review covering authentication, tenant/access boundaries, secrets handling, webhook verification, and logging was completed ahead of launch -- treated as a pre-launch gate, not a post-incident fix.