Independent AI intelligence Two editions daily · ET
FervorAI

Analysis · August 21, 2026 · repo

AI-Infra-GuardTencent Zhuque LabMCPAgent Skillsagent-securitymcp-securityai-skillsagent-infrastructure

Tencent's AI-Infra-Guard Will Scan Your Agent Stack. Its Own README Says Don't Put It on a Public Network.

The free red-team platform for MCP servers, agent skills, and AI infrastructure is worth running. Understand what you are adding to your network before you do.

Two sentences from the same project, written by the same team.

From the AI-Infra-Guard technical report: "An inference server exposed without authentication represents an infrastructure security failure."

From the project's README, in the installation section: "It currently lacks an authentication mechanism and should not be deployed on public networks."

I do not read that as hypocrisy. A security team that knows exactly what it built said so out loud, which is more than most tools in this category manage. The placement is less generous than the sentence: it sits inside a collapsed "More installation options" block, below the third install method, where a reader who followed the Quick Start will never see it. That combination, a correct warning filed where nobody reads it, sets the terms for how you should think about this tool, and those terms are not the ones most people apply to a scanner.

What it actually does

AI-Infra-Guard, shortened to A.I.G, comes out of Tencent Zhuque Lab, part of Tencent's Security Platform Department, and it is Apache 2.0. Its feature table currently lists six capabilities that most teams would otherwise assemble from six separate projects.

The infrastructure scanner fingerprints running AI services and matches them against known CVEs. You point it at an address, not a repository: http://127.0.0.1:8000 for a local vLLM instance, http://192.168.1.100:11434 for an Ollama server, or a CIDR block if you want to sweep a subnet. The README claims coverage of more than 100 AI components and over 2000 known CVEs.

The MCP server and agent skills scanner is the piece I would actually go install this for. It reads a remote URL or an uploaded source archive, with no running instance required, and checks against 14 categories of risk, with the newer standalone skill-scan engine documenting nine skill risk categories of its own. That is the gap almost nobody fills. Everyone has opinions about prompt injection in skill files; very few tools will read a SKILL.md and tell you which specific pattern in it is the problem.

Agent Scan runs multi-turn black-box red teaming against a deployed agent, with support for agents running on Dify and Coze. Jailbreak Evaluation throws curated attack datasets at a model endpoint you configure, and the operator library has grown fast: version 4.1.4 added TAP and Crescendo strategies to the MCP scan's multi-turn module, 4.1.9 added more than twenty single-turn operators and six multi-turn ones including tree jailbreaking and Best-of-N, and 4.5.1 added Many-Shot, PAIR, GOAT, and ActorAttack. ClawScan checks OpenClaw installs for insecure configuration, skill risk, CVEs, and privacy leakage. The sixth row, a model and API relay checker covering model fingerprinting and relay black-box auditing, is the newest addition.

The technical report is clear about why these are separate engines rather than one scanner with six modes. Different classes of risk come from different system properties, so the paper describes four assessment paradigms: deterministic rule matching for infrastructure, LLM-driven semantic auditing for MCP servers and skills, multi-turn black-box red teaming for deployed agents, and large-scale adversarial enumeration for models. That is a better articulation of the problem than most commercial AI security vendors have published.

The part that changes your threat model

Here is the position I want to defend. AI-Infra-Guard is worth running, and you should treat the box it runs on as production infrastructure rather than as a utility you spin up on a laptop and forget.

Look at what the service holds and what it can reach once you have it working.

To use Jailbreak Evaluation you go to Settings, then Model Config, and give it a base URL and an API key for the model you want tested. That is a live credential with billing attached, sitting in an application whose own install note says it has no authentication mechanism. Version 4.1.4 added support for HTTPS model endpoints with self-signed certificates, along with an InsecureSkipVerify option, which is a reasonable thing to need in a lab and one more setting that can end up wrong in a hurry.

To use the infrastructure scanner you hand it network targets, including CIDR ranges. Anything that can talk to port 8088 can therefore ask the box to make arbitrary requests inside your network. That is the shape of a server-side request forgery primitive with a friendly web interface on top.

And the scanner reads untrusted input by design. Version 4.1.9's release notes include a line I would frame and hang on a wall: "Add indirect prompt injection defense to scanning agent prompts." The tool that reads your MCP server's tool descriptions to find prompt injection is itself an LLM agent reading attacker-controlled text.

The strongest evidence is in the project's own history. Version 4.1.1 fixed issue #226 by masking token fields in the GetTaskDetail API response, because the platform had been returning configured credentials through its task-detail endpoint. That got fixed. It got fixed in a service with no authentication in front of it, which is why it mattered.

None of this makes the tool bad. It makes the tool a high-value internal target, which is the normal condition of every security scanner ever written and the thing people forget when the scanner is free and installs with one Docker command.

Put this into practice

You can get to a real finding in about twenty minutes. Steps three and four are the ones people skip.

  1. Bring it up locally. Clone the repo, then docker-compose -f docker-compose.images.yml up -d, which pulls prebuilt images rather than building from source. You need Docker 20.10 or newer, 4GB of RAM, and 10GB of disk. The web interface comes up on http://localhost:8088.

  2. Do not expose 8088. Bind it to loopback, or put it behind a reverse proxy that does authentication, or run it on a host that is not routable from your general network. The maintainers told you this; the failure mode is that someone runs it on a shared box "just for a day."

  3. Give it a throwaway model key with a spend cap. Jailbreak Evaluation and the MCP and skills scanner both consume tokens, and the semantic auditing engine is an LLM. Use a scoped key created for this purpose, not your team's production key.

  4. Sync the rule data before your first scan. The data/ directory carries fingerprints, CVE rules, MCP scan rules, and jailbreak datasets, and since version 4.1.6 it updates by git clone through the platform's own update endpoint rather than waiting on a tagged release. If you skip this you will scan with whatever shipped in the image you pulled.

  5. Start with the skills scan on something you already trust. Point it at an MCP server or skill pack you use every day. A scanner's findings only mean something once you have calibrated its false positive rate on code you can personally vouch for.

  6. Then run the infrastructure scan against one host, not a subnet. Get a feel for what the fingerprinting says about a service you know the version of before you turn it loose on a range.

If you want it inside an agent workflow, the team publishes skills on ClawHub. clawhub install aig-scanner, then set AIG_BASE_URL to your running instance. There is a certain recursion to installing a skill that scans skills, and it works.

Honest limitations

The release cadence is fast enough that anything you read about this project goes stale in weeks, including this article. The latest tag is v4.5.2 from August 17, four days before I wrote this, and the 4.5 line open-sourced the frontend, split skill, MCP, and agent scanning into standalone command-line tools, and added Python bytecode bypass detection. I checked the repository page mid-draft and it served me a two-month-old release number, which is a good argument for reading the changelog rather than the landing page.

The coverage figures move with it. The README now says 100-plus components and 2000-plus CVEs, where the May release notes said 68 components and the number in between kept climbing. Star counts told the same story: I saw 3.9k on one page load, 4.1k in search results, and 5.2k from the live badge API in the same session. Nothing here is dishonest, but it does mean you should test the coverage claim against your own stack rather than take any single published number, including mine.

Breadth costs depth. Six scanning surfaces in one platform will not match a dedicated tool on any single one of them. If you have a mature CVE pipeline already, the infrastructure scanner is redundant; the skills and MCP audit is the part with no obvious substitute.

The LLM-driven audit means findings vary between runs. That is inherent to semantic auditing, not a bug in this implementation, and it means you cannot treat a clean scan as a gate the way you would treat a deterministic rule pass. Run it twice on anything you care about.

The Pro version at aigsec.ai is invitation-only, prioritized for people who have contributed issues or pull requests. Documentation is strongest in Chinese, and the English pages occasionally trail. And the interface itself still surfaces some Chinese labels alongside English in places, which is cosmetic but worth knowing before you demo it to a security team.

Who scans the scanner

The uncomfortable thing about this category is that every tool built to find risk in an agent stack becomes part of that stack. AI-Infra-Guard reads untrusted skill files with an LLM, holds model credentials, and makes network requests on your behalf, which is a fair description of the agents it is meant to evaluate.

The team clearly knows. They shipped a SECURITY.md with a trust model in version 4.1.4, hardened their own scanning agent against indirect prompt injection in 4.1.9, and wrote the no-authentication warning down in plain language. I would only ask them to move that last sentence out of the collapsed block and put it where the Quick Start lives, because the people most likely to expose port 8088 are exactly the people who stopped reading after the first docker-compose command.

What I have not seen anyone answer is what a scan of A.I.G by A.I.G would actually return. If you run one, I would genuinely like to see the report.

Sources: Tencent/AI-Infra-Guard on GitHub, the project CHANGELOG, AI-Infra-Guard releases, arXiv:2606.31227 (quoted from v1, since retitled "Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming"), Tencent Zhuque Lab.