> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI-Infra-Guard: Open-source security scanner for AI systems
- URL: https://f4n6.co.uk/security-feed/ai-infra-guard-open-source-security-scanner-for-ai-systems/
- Published: 2026-09-09T09:24:47.000Z
- Updated: 2026-09-09T09:24:47.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Tencent's Zhuque Lab has released AI-Infra-Guard, a free, open-source security scanner for AI infrastructure, available on GitHub. The tool fingerprints running AI services (Ollama, vLLM, ComfyUI), matches them against more than 1,600 known CVEs, inspects MCP servers and agent skills across 14 risk categories, and runs jailbreak evaluations against target models. Two properties matter to EMEA financial services clients: the open-source build ships with **no authentication mechanism and no RBAC** — it is a single-operator tool that holds the API keys for every model it evaluates, and the vendor's own documentation warns against internet exposure; and its LLM-driven skill-analysis component is itself exposed to indirect prompt injection via the tool and skill descriptions it ingests from potentially hostile servers, a risk only partially mitigated as of release 4.1.9\. This is a defensive tooling advisory, not an active-threat advisory: no exploitation, no threat actor, no CVEs in the tool itself are reported. No verified reference data resolved for this item, so no CVSS, KEV or attribution claims are made here.

## 2\. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The tool is a defensive scanner, not an incident, a patch cycle or a contracted third-party service; nothing in the source material triggers a distinctive obligation under the articles in scope. Clients choosing to deploy it should note that its own documented weaknesses (no authentication, prompt-injection exposure in the scanning agent) are deployment-configuration matters, not reportable events.

## 3\. Technical analysis & attack chain

There is no attack chain to reconstruct — this item covers a defensive tool, not an intrusion. The technical analysis below covers the tool's capabilities and, more importantly for defenders, its own attack surface.

### What the tool does

1. **Service fingerprinting and CVE matching.** AI-Infra-Guard fingerprints running AI services — the source names Ollama, vLLM and ComfyUI — and checks the identified versions against a corpus of more than 1,600 known CVEs. Zhuque Lab characterises this layer as deterministic: "CVE version-matching isn't intent-based at all… FPR there is purely a function of fingerprint accuracy." No false-positive rate is quoted for this layer.
2. **MCP server and agent-skill inspection.** The tool inspects MCP servers and agent skills across 14 categories of risk. This layer is LLM-driven: to evaluate a skill, the platform asks a language model whether it looks malicious, scored against SkillTrustBench, a public benchmark of 5,520 human-labelled samples across nine risk categories. False-positive rates on SkillTrustBench range from **1.20% to 18.67% depending on the judging model**. In practical terms: at the low end roughly one clean skill in eighty is flagged; at the high end close to one flag in five is a false positive.
3. **Jailbreak evaluation.** The tool runs jailbreak evaluations against a target model.

### The tool's own attack surface — the part defenders must treat seriously

- **Indirect prompt injection against the scanner itself.** Both scanning components ingest tool descriptions and skill files that a hostile server controls. Indirect prompt injection — instructions embedded in content the model reads, aimed at the model doing the reading — is the applicable technique. Release 4.1.9 hardened the scanning agents: file/tool content is placed into a dedicated, explicitly delimited text block in the prompt, structurally separated from instructions, and the scanning agent is instructed to treat that block as data to analyse, never as commands to follow. Zhuque Lab states this "cuts naive-to-moderate injection significantly" but is "a mitigation, not a formal guarantee," and that they "don't claim it's unbreakable, and we'd say that about any LLM-driven agent." A defender scanning a suspicious MCP server should treat a clean result as one input, not a clearance.
- **No authentication in the open-source build.** The repository carries a warning that the platform "currently lacks an authentication mechanism." It is a single-operator tool by design — "No login, no RBAC" — and the documented recommendation is to place access control outside the application: a reverse proxy in front (nginx with Basic Auth or an IP allowlist) plus normal firewall rules. A deployment that skips this is running a vulnerability scanner that holds the API keys for every model it evaluates, reachable by anyone who can route to the port.

**Adoption context (single-sourced).** The claim that banks, carriers and manufacturers use the tool — including ICBC, China Merchants Bank, China Telecom, Lenovo, vivo and Bilibili — comes solely from the Help Net Security article. Treat as single-sourced; verify before relying on it for vendor-risk or peer-benchmarking decisions. ICBC and China Merchants Bank are named users, which is relevant context for financial-services clients evaluating the tool, but this is not independent corroboration.

## 4\. Mitigation & containment

These are deployment controls for clients adopting the tool, not incident-response steps.

### P1 — within 24h (before or at first deployment)

- Do **not** expose the AI-Infra-Guard web surface to any network beyond a single-operator jump path. The open-source build has no authentication and no RBAC; the repository itself warns against internet exposure.
- Implement the vendor's documented access-control pattern: reverse proxy in front of the application — nginx with Basic Auth or an IP allowlist — plus firewall rules restricting the listening port to operator workstations only.
- Treat the tool's stored model API keys as high-value secrets: the platform holds the API keys for every model it evaluates. Store keys outside the application where possible, scope them to read-only or evaluation-only permissions where the provider supports it, and rotate on any suspicion of unauthorised access to the scanner host.

### P2 — within 72h

- Pin to release **4.1.9 or later**, which contains the prompt-injection hardening for the scanning agents (delimited data blocks structurally separated from instructions). Verify the running version before pointing the scanner at any third-party or untrusted MCP server.
- Restrict the scanner's network egress: the tool fetches tool descriptions and skill files from servers it inspects, which may be hostile. Run scans of untrusted targets from a segmented host with egress limited to the target scope, so an injected instruction or malicious fetch cannot reach internal services.
- Do not let the scanner's LLM-judging calls egress arbitrary content: constrain the judging model's network access to its inference endpoint only.

### P3 — within 7 days

- Codify the vendor's own guidance into runbooks: a clean skill-scan result is one input, not a clearance. Human review remains mandatory for any skill or MCP server being onboarded, particularly given the 1.20%–18.67% false-positive range and the acknowledged residual prompt-injection risk.
- Select the judging model deliberately: false-positive rates on SkillTrustBench vary by more than an order of magnitude across models, which directly determines analyst review load. Record which model is used and its benchmark FPR.
- Review the tool's GitHub repository for updates to the authentication mechanism; the lack of login is a current-state limitation, and upstream changes should be tracked.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. This advisory covers a defensive tool; no malicious artefacts, network indicators or hashes are described.

## 6\. Detection

Insufficient indicators to author detection rules. The source material describes a defensive scanner and its configuration weaknesses; it contains no threat artefacts — no strings, command lines, file paths or registry keys belonging to a malicious actor — from which rules could be built.

## 7\. Sources

- Help Net Security, "AI-Infra-Guard: Open-source security scanner for AI systems," https://www.helpnetsecurity.com/2026/09/09/ai-infra-guard-open-source-security-scanner-ai-systems/, 2026-09-09

## 8\. Adverse Trace position

This is a low-severity, tooling-adoption advisory — there is no active threat, no exploitation and no CVE in the tool itself reported in the source material, and no verified reference data resolved for this item, so we make no severity or KEV claims. The genuine risk to EMEA financial services clients is self-inflicted: deploying an unauthenticated, key-holding vulnerability scanner on a reachable network segment converts a defensive asset into a high-value target, and pointing its LLM-driven components at untrusted MCP servers carries a residual prompt-injection risk the vendor itself declines to guarantee against. Our position: the tool is worth piloting for AI-infrastructure inventory and CVE matching — the deterministic fingerprinting layer is the stronger component — but only behind the documented reverse-proxy and allowlist controls, pinned at 4.1.9 or later, with human review retained for all skill and MCP onboarding decisions. The named-user list (ICBC, China Merchants Bank among them) is single-sourced and we will not treat it as corroborated adoption. We will monitor the upstream repository for an authentication mechanism and for any report of injection bypass against the 4.1.9 hardening, and will reissue if either materialises.

---

[Read the original source →](https://www.helpnetsecurity.com/2026/09/09/ai-infra-guard-open-source-security-scanner-ai-systems/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*