LLM red-teaming tools test whether an agent's behavior can be manipulated. Post-quantum crypto tools test whether a primitive is quantum-safe. Nothing checks both for the same project, at the same time, and escalates one when the other is missing. QuantumAgentGuard does.
A 2026 CVE in Microsoft Semantic Kernel (CVE-2026-26030) showed that current agent
frameworks fail from ordinary architecture bugs, an eval() reachable from
LLM-influenced input, a blocklist filter that's trivially bypassed, not from anything
exotic about the model. Microsoft's own conclusion: the LLM can't be treated as a
security boundary. Meanwhile, the entire Web PKI, root CAs down to every end-entity
certificate, is still RSA/ECDSA-based, and every agent framework built on top of it
inherits that exposure whether or not anyone thought to check.
Agentic red-teaming tools (e.g. DeepTeam, ~3k★) test prompt injection and unsafe tool use. Post-quantum tooling (e.g. liboqs, ~3.1k★) tests cryptographic primitives. They don't talk to each other, and neither one flags a project that's dangerously exposed in both dimensions at once.
One scan, one report: known agentic-vulnerability shapes and classical-crypto/PKI exposure together, with an explicit cross-file rule that escalates crypto findings to HIGH the moment it sees an agent framework with zero PQC dependency anywhere in the project.
Every rule is a documented AST/pattern heuristic you can read in full, not a benchmark score.
| Rule | Category | Fires on | Precedent |
|---|---|---|---|
AG001 | Agentic | eval()/exec(), HIGH if arg looks agent/LLM-derived | CVE-2026-26030 |
AG002 | Agentic | os.system/popen, subprocess with shell=True | Command injection via tools |
AG003 | Agentic | pickle.load(s), unguarded yaml.load() | Insecure agent-state deserialization |
AG004 | Agentic | subprocess.*([interpreter, "-c", code], ...) with a non-literal code arg | Same risk as eval/exec, via a subprocess |
PQ001 | Quantum | RSA key generation | No PQ migration path |
PQ002 | Quantum | ECDSA key generation | No PQ migration path |
PQ003 | Quantum | Deprecated ssl.PROTOCOL_TLSv1*/SSLv2*/SSLv23 | Blocks hybrid PQ key exchange |
PQ004 | Quantum | Agent framework marker + zero PQC marker anywhere in project | Cross-file escalation |
Scanned against examples/vulnerable_agent_demo/, a small fixed target shaped after CVE-2026-26030, included in the repo. Reproduce with qag scan examples/vulnerable_agent_demo.
QuantumAgentGuard scan: examples/vulnerable_agent_demo Files scanned: 1 Findings: 6 | Risk score: 45/100 -- AGENTIC VULNERABILITIES (3) -- [HIGH ] AG001 tool.py:17: Dynamic code execution via eval() [CVE-2026-26030] [HIGH ] AG002 tool.py:21: Shell command execution via os.system [MEDIUM] AG003 tool.py:25: Unsafe deserialization via pickle.loads -- QUANTUM-READINESS GAPS (3) -- [HIGH ] PQ004 (project-wide): Agent framework detected with zero post-quantum crypto dependencies [MEDIUM] PQ001 tool.py:33: RSA key generated at 2048 bits [MEDIUM] PQ003 tool.py:29: Deprecated TLS protocol constant ssl.PROTOCOL_TLSv1
v0.1.0 was run against 6 real public repositories (CrewAI examples, MCP servers, Semantic
Kernel, AutoGen, LlamaIndex tool integrations, plus a negative control). Every
PQ004 finding it produced was a true positive — but it also missed two
real findings entirely: an eval()/exec() call hidden inside a
Jupyter notebook cell (no .ipynb support), and a
subprocess.run([sys.executable, "-c", code]) call in a real MCP tool
integration (no rule covered it). Both are fixed in v0.2.0, verified against the exact
files that exposed them. Full methodology and results:
EVALUATION.md.
pip install -e . from a clone. Zero runtime dependencies.
qag scan /path/to/agent/project, or add --json for machine-readable output.
qag scan . --fail-on HIGH to fail a pipeline on any HIGH finding.