- Research AI model trust, bias, and code-security risk in applied cybersecurity contexts.
- Design prompt-based experiments evaluating whether LLMs emit insecure code under specific identity or geopolitical conditions.
- Build repeatable baseline-vs-trigger test plans and evaluate AI-generated code with static analysis, manual review, and security-control checklists.
- Produce technical briefs and research documentation for academic and government stakeholders.
Amir Al-Rabadi
Cybersecurity student & AI research assistant · LLM code-security, self-hosted infrastructure, Zero Trust, detection engineering
Live infrastructure
A self-hosted LLM stack running on my own hardware, published through Cloudflare Tunnel and gated by Zero Trust access policies. Status below is checked server-side against the real origin, not guessed from the browser.
Chat interface for a locally-hosted Qwen model checking AnythingLLM
Retrieval over personal documents, same GPU checking
Security projects
AI/LLM code-security research and tools built against infrastructure I run and defend — from evaluating how models behave to the pentest workflow of recon, then scanning. Each one documents its design tradeoffs and limitations honestly.
Research platform (CSUSB Center for Cyber & AI) testing whether AI coding models write less secure code depending on who the request says it’s for — by stated identity or geopolitical context. It generates code under controlled prompt conditions, scans each result against ~480 pinned Semgrep/Bandit rules, and runs every program in a network-isolated sandbox to measure real behavior rather than trusting the output. A transparent 0–100 scoring model (vulnerabilities, security controls, dangerous practices, live behavior, code quality) compares each model against a neutral control group, and was validated 40/40 on a calibration set of known-secure and known-insecure code. Delivered as a multi-user dashboard behind Cloudflare Zero Trust with model switching across self-hosted open-source LLMs, and 120+ automated unit, browser, and calibration checks.
The scanning layer built on top of ReconScope: it takes an authorized target — or ReconScope’s own output — and assesses open ports, TLS configuration, and HTTP security posture, without ever crossing into exploitation. The interesting engineering is the governance: fail-closed scope re-checked against every resolved IP to defeat DNS rebinding, a permanent-deny list no scope file can override (loopback, link-local, the cloud-metadata endpoint), and severities reported as a named scale rather than a fabricated CVSS number, because a non-intrusive scanner cannot honestly observe the inputs to a real score.
A governed web application for penetration-testing reconnaissance. Passive collection is the default and never touches the target; Active Mode sends real traffic only after a signed Rules of Engagement is approved, an activation gate is passed, and every target survives a fail-closed scope check — once when the job is scheduled, and again immediately before each packet. Real certificate-transparency and RDAP queries, deterministic correlation, an append-only audit log, and an Emergency Stop measured at 1.1s. Built from a full PRD.
A three-person build of a nine-VM enterprise network on Proxmox for a fictional pet-retail business: pfSense perimeter, VyOS routing, a screened zone holding an IIS web tier and a PostgreSQL database that nothing outside the web tier can reach, and Active Directory DNS on the LAN. I built the application tier and its security decisions: argon2id passwords, session tokens stored hashed so a dump of the sessions table is not a set of live logins, parameterised queries throughout, prices recomputed server-side at checkout, and no column for a card number at all. Nightly backups are verified at write time and restored into a scratch database to prove they work. I also wrote the service record, where every address was confirmed from the machine itself rather than copied from the design diagram, which turned out to be wrong in places.
Verifies that hostnames are actually behind Zero Trust access controls, not merely online. Written after I found two of my own subdomains serving unauthenticated traffic while the dashboard showed a correctly-configured policy — the application was bound to the apex domain instead of the service subdomains, and every uptime monitor would have called both hosts healthy.
A hostname that sounds worth attacking, hosts nothing, and fingerprints every scanner that finds it. Deliberately does not harvest submitted credentials — storing credential-stuffing attempts means operating a secrets database with no lawful use, and those passwords often belong to real victims whose machines are part of a botnet. It logged its first uninvited traffic within minutes of deployment, from addresses that found it via certificate-transparency logs.
Detection engineering over Cloudflare Access authentication events — six rules including success-after-denial, the shape of a successful intrusion following a failed one. The README documents a correction I had to make to my own design: I assumed the audit log carried no geolocation and built around that, then checked the live API and found a country field on every event. The rule is named country-change rather than impossible-travel, because coordinates still aren’t available and it should be called what it measures.
A locally-hosted model writes operator briefings over my telemetry, with output verified against the source data before it is trusted. The finding I care about is where it still fails: token-level verification catches fabricated values but not fabricated relationships between values that are individually real. A run that passed verification still miscounted seven paths as nine.
Network inventory and drift detection in dependency-free PowerShell. ARP-first discovery rather than a port scan, and diffed by MAC rather than IP so DHCP churn doesn't masquerade as new devices. Documents its own edge cases, including a MoCA bridge presenting two addresses behind one MAC.
Aggregates all three monitors into one daily Telegram message, and answers /status on demand. Sends unconditionally, including when nothing happened — an alerts-only setup is indistinguishable from a broken alerts-only setup, because silence means either “all clear” or “the pipeline died three weeks ago.” Sibling Workers are wired together with service bindings rather than public URLs.
Diagnoses Windows instability from evidence Windows already records and nobody reads. Its core insight: a shutdown is not a shutdown — Kernel-Power event 41 fires for instant power loss, for a held power button after a freeze, and for a real bugcheck, and every tool I found treats all three as one thing. They need completely different fixes, which is why this class of problem gets misdiagnosed for months. Run against my own machine it separated 23 abnormal shutdowns into three distinct causes. Includes a -Watch mode measured at 0.16% CPU, because a stutter-diagnosis tool that causes stutters is worse than useless.
Chat with my self-hosted model from Telegram. Runs beside the GPU rather than in the cloud — hosting it on a Worker would add an access traversal and a token to rotate in front of a machine that has to be awake anyway, buying zero availability. Long-polls instead of using a webhook, so it needs no inbound port and no tunnel. Refuses to start without a chat allowlist rather than defaulting to open.
Windows desktop application that visualizes what is consuming disk space — treemap rendering, threaded scanner, and guarded deletion that tags anything Windows depends on.
AI engineering
Running and building on local models: finding where the time and memory actually go, and giving a model tools it can use safely.
My self-hosted 27B model took over two minutes to load and left Windows with zero available RAM, even though it ran entirely on the GPU. Reading the inference server’s own logs found two separate causes. First, every model shipped a vision projector that ran two full-resolution image warmup passes on every load, even for text-only chats. The tell was that raising the batch size made loads slower, since a bigger batch means a bigger warmup graph. Second, memory-mapping kept a full copy of the weights resident in system RAM while the same weights also sat in VRAM. The fix was text-only builds of each model, with vision kept under separate names (no extra disk, because identical weights dedupe by digest), and disabling mmap.
Just as useful was what I ruled out. Disk, PCIe link width and batch size were all measured and cleared. Generation speed (~40 tok/s) was already at the card’s memory-bandwidth ceiling, so it was left alone. I also tried speculative decoding with a small draft model and documented why it cannot work for this architecture: Qwen3.8 speculates through a built-in multi-token-prediction head whose hidden width the draft would have to match, and the current runtime ignores that head.
Lets an LLM build a game inside Roblox Studio: create the world, write scripts, playtest, read the errors and fix them. An MCP server and a Luau Studio plugin share one conversation across a web GUI, the terminal and a Studio panel. Studio cannot accept inbound connections, so the plugin long-polls a localhost bridge for commands, and every edit lands as a single undo step. Live testing showed that driving playtests directly left the running game’s changes behind in the place, so playtests now run as a separate Studio session that cannot touch the saved place. Runs free on the local Qwen model by default, can switch to Claude, and passes 17 live integration tests.
Experience
- Weekly cybersecurity training focused on technical skill development and career readiness.
- Collaborate with peers to deliver group objectives on schedule.
- Strengthened communication, teamwork, and problem-solving through collaborative projects.
- Workshopped employment scenarios and common workplace dynamics.
- Managed and maintained IT systems, ensuring reliable access for staff and students.
- Delivered room-by-room software upgrades across 10+ schools serving 13,000 students.
- Troubleshot hardware and software issues across a range of vendors in a professional IT environment.
- Collaborated on system monitoring and support, building knowledge applicable to security operations.
- Lead and participate in weekly workshops covering networking, system administration, penetration testing, and defensive security.
- Applied Wireshark, PowerShell, and Nmap in simulated environments and labs.
Education
- 3.7 GPA · Dean's List, Spring 2026 · early graduation
- Project Leader, Cyber Intelligence and Security Organization