Sherbano Khan / AI Security & GRC

Understanding risk.
Building security.

I test AI agents and software supply chains, then turn what I find into controls and policy teams can act on.

AI security and GRC analyst. Master of Information and Cybersecurity, UC Berkeley.

Explore my work

Try the AgentGuard attack

A replay of my local lab. All data is fake.

Internet Public repo Agent Private repo 1 file issue 2 list_issues 3 read 4 secrets 5 post_comment 6 attacker reads Attackerany user Issue #42poisoned Triage agentqwen2.5 7B config.ymlAPI keys Public replypost_comment
readyPick how the attacker hides the instruction, choose whether the allowlist is on, then run the attack.
93%

Measured on a local model over 15 runs per technique. With the allowlist on, private access fell to 0%.

My work

Security in practice.

Open a card to see everything in it.

Projects

Open a project for its architecture, results, and demo.

AgentGuardAI agent security lab: prompt injection, tool permissions, and governance2026, personal project

I built an AI issue-triage agent with real tool access, then showed how one poisoned GitHub issue could make it read a private repository and leak its secrets. I measured how often that worked, fixed the root cause, and wrote it up the way a security team would.

67–100%runs reached private data
0%with the allowlist on
8.6CVSS, High
  • Indirect prompt injection (OWASP LLM01) and excessive agency (LLM06)
  • Phase 1: a simulated agent with 13 automated tests. Phase 2: a local LLM agent with Ollama
  • CI on GitHub Actions runs the tests plus bandit and pip-audit security scans
Public issues incl. poisoned #42 Local LLM Ollama, qwen2.5 7B Triage agent agent.py, tool loop Tool layer, tools.py list_issues read_repo_file post_comment Allowlist public_repo only ACCESS DENIED returned to agent public_repo private_repo fake secrets Experiment runner 3 techniques x 15 runs Results and reports vuln assessment, threat model, playbook denied drives CI: GitHub Actions runs pytest, bandit, and pip-audit
Architecture. The allowlist sits in the tool layer, so it holds even when the model is fooled.

Click a metric to see why I scored it that way.

8.6High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
ArgussAutonomous software supply chain security for npm dependencies2026, UC Berkeley capstone

My UC Berkeley capstone, built with a team of three. Arguss scans npm dependency updates, runs three checks on each one, and makes a call: merge the low-risk fixes, send the unclear ones to a reviewer, and block the dangerous ones.

3checks per update
6intelligence sources
3outcomes
  • Vulnerability data from OSV.dev, GitHub Security Advisories, CVSS and EPSS, and CISA KEV
  • Trust signals from the npm registry and deps.dev
  • Python backend with a Jinja2, HTMX, and Tailwind front end
Dependency update npm package diff Three-check pipeline Vulnerability OSV.dev, GitHub advisories CVSS, EPSS, CISA KEV Trust npm registry, deps.dev maintainers, provenance Pipeline pipeline analysis Fix Confidence Engine scores each update Auto-merge low risk Escalate human review Block dangerous Python backend Jinja2, HTMX, Tailwind UI
Architecture. Every update gets the same three checks before the engine decides.

How the engine sorts updates. Example packages, not real npm data.

Auto-merge

All three checks pass

Escalate to a reviewer

Something needs a human call

Block

A check fails outright

Select a package to see why it landed there.

About me

Investigate deeply.
Communicate clearly.

I'm an AI security and GRC analyst with a Master of Information and Cybersecurity from UC Berkeley. I started out building websites, took security electives during my computer science degree, and got hooked.

Before security, I ran technology operations across eight FedEx Office locations. That taught me controls only work when the people using them understand them.

Areas of focus
AI & agent securityApplication securityVulnerability managementCyber risk & GRCSoftware supply chainNIST AI RMF & ISO 42001Threat modelingOWASP LLM Top 10

My work connects hands-on security testing with practical recommendations that engineering and governance teams can act on.