Tencent AI-Infra-Guard: an unauthenticated red teaming console with five scanners you can also run alone

One console on port 8088 in front of five separate scanners

A.I.G (AI-Infra-Guard) is Tencent Zhuque Lab's attempt to put several AI security checks behind a single web interface. The scanners cover AI infrastructure vulnerability matching, LLM security assessment through jailbreak evaluation, MCP server scanning, Agent Skill auditing, agent probing, and OpenClaw security checks. The project is licensed under Apache-2.0 and was presented in the Black Hat Europe 2025 Arsenal; the repository root carries the Arsenal slides and a BHEU-25 talk on compromising the agent ecosystem through MCP.

The code base is split by language. The web server is Go 1.23.2, built on gin with SQLite through gorm and glebarez/sqlite, and uses mark3labs/mcp-go and openai-go as libraries. The scanners under agent-scan/, mcp-scan/, skill-scan/, infra-scan/ and AIG-PromptSecurity/ are Python. A frontend/ directory is compiled with pnpm on Node 22 and copied into the Go binary's static folder at image build time. Releases arrive on a weekly rhythm: v4.6.6 on 2026-10-15, v4.6.7 on 2026-10-22 and v4.6.8 on 2026-10-29, with the last push on 2026-11-02. The API is described in api.md, with Japanese and Chinese versions beside it.

No login screen, so the platform cannot sit on a public network

The project states plainly that A.I.G currently lacks an authentication mechanism and is positioned for internal use by enterprises or individuals, and that it should not be deployed on public networks. This is the single most important constraint for anyone planning a shared deployment.

The consequence is concrete. Once the stack is up, anyone who can reach http://localhost:8088, or whatever address the host publishes port 8088 on, can start scans, read task results stored in the SQLite file at /app/db/tasks.db, and see uploaded files under /app/uploads. A red teaming tool holds exactly the data an attacker wants: model endpoints, API keys typed into scan forms, and a list of what is vulnerable. If a team needs multi-user access, it has to supply the access control itself, for example by binding the published port to a private interface or putting an authenticating proxy in front. The compose file publishes "8088:8088" on all interfaces as shipped, so the default does not do this for you.

The agent container runs with SYS_ADMIN and seccomp disabled

docker-compose.yml defines two services. The webserver container, ai-infra-guard-webserver, publishes port 8088, mounts ./data, ./db, ./logs and ./uploads from the checkout, sets TZ=Asia/Shanghai, and waits for the agent to report healthy before starting. The agent container, ai-infra-guard-agent, only exposes port 8000 to the internal ai-infra-guard-network and is reached by the webserver through AIG_API_CHECKER_URL=http://agent:8000.

The agent is where the privilege sits. It is granted cap_add SYS_ADMIN, runs with security_opt seccomp:unconfined, and gets a shm_size of 2gb. Both services use restart: always. For a scanner that sends traffic to untrusted targets, this weakens the isolation Docker normally gives you between the container and the host kernel. On a dedicated scanning VM that trade may be acceptable. On a shared build server or a developer laptop with other workloads, it deserves a review before the first docker-compose up, because the compose file applies it unconditionally. The TZ value is also hardcoded to Asia/Shanghai in both services, so task timestamps follow that zone unless you edit it.

The API checker refuses plain HTTP and private targets until you flip two variables

The agent service reads four API checker settings from the environment, each with a default baked into the compose file:

- AIG_API_CHECKER_MAX_JOBS defaults to 20 - AIG_API_CHECKER_ALLOW_HTTP defaults to 0 - AIG_API_CHECKER_ALLOW_PRIVATE_TARGETS defaults to 0 - AIG_API_CHECKER_CORS_ORIGINS defaults to empty

The two zero defaults matter for internal testing. A model served over plain HTTP, or on a private address inside your own network, is the common case for a team evaluating a self-hosted endpoint, and these are the switches that govern it. If an internal target fails to scan, check these two values before assuming the target is unreachable. Turning them on is a deliberate loosening: a console with no authentication that is also allowed to reach private addresses can be used to probe the network it sits in. The checker stores its state in a named volume, api-checker-data, mounted at /api-checker-data, and serves under AIG_API_CHECKER_ROOT_PATH=/api-checker.

Three install routes with different costs

All three routes end in the same web UI and require Docker 20.10 or higher, 4GB or more of RAM and 10GB or more of disk. The first pulls prebuilt images from Docker Hub:

# This method pulls pre-built images from Docker Hub for a faster start
git clone https://github.com/Tencent/AI-Infra-Guard.git
cd AI-Infra-Guard
# For Docker Compose V2+, replace 'docker-compose' with 'docker compose'
docker-compose -f docker-compose.images.yml up -d

The project labels a one-line script as its recommended method. It installs Docker for you and launches A.I.G, which means piping a remote shell script from the main branch into bash with whatever privileges your shell has:

curl https://raw.githubusercontent.com/Tencent/AI-Infra-Guard/refs/heads/main/docker.sh | bash

Building from source runs plain docker-compose up -d against docker-compose.yml. The Dockerfile is a three-stage build: node:22-alpine compiles the frontend with pnpm, golang:1.23.2-alpine builds the ai-infra-guard binary from ./cmd/cli/main.go with CGO disabled, and a python:3.12-alpine runtime installs uv and runs uv sync --no-dev inside agent-scan. The frontend stage activates pnpm@latest through corepack, so two source builds weeks apart can use different pnpm versions.

Each scanner ships as its own pip package, and three of them need a model key

You do not have to run the web service at all. Each scanner is published separately on pip and runs from the command line. The infrastructure scanner takes a domain, IP or URL and matches fingerprints and vulnerabilities:

pip install aig-infra-scan
aig-infra-scan -t https://example.com

The model scanner evaluates anything that exposes an OpenAI-compatible API. --scenarios picks what is tested and --techniques picks how prompts are transformed, with --max_concurrent capping parallel requests:

pip install aig-model-scan
aig-model-scan \
  --model "gpt-4o-mini" \
  --base_url "https://api.openai.com/v1" \
  --api_key "your-api-key" \
  --max_concurrent 10 \
  --scenarios Bias \
  --techniques Raw

The MCP, skill and agent scanners all read LLM_API_KEY, because the scanner itself calls a model. That key is separate from the agent you are testing:

pip install aig-mcp-scan
export LLM_API_KEY="your-api-key"
aig-mcp-scan --repo /path/to/mcp-server -o result.sarif.json

pip install aig-agent-scan
export LLM_API_KEY="your-api-key"
aig-agent-scan --agent_provider target.yaml -o result.json

The practical cost: these three cannot run offline or without a provider account, and every scan spends tokens. MCP and skill results come out as SARIF, which code scanning tools can ingest, while agent scan writes plain JSON. The agent target is described in a target.yaml file, whose format lives in agent-scan/README.md rather than on the front page.

Detection is only as wide as the rule files under data/

A.I.G treats its checks as data rather than code. Fingerprints are YAML files in data/fingerprints/, vulnerability rules go in data/vuln/, MCP security rules in data/mcp/, and model evaluation datasets in data/eval. Contributors add a file following the existing format and open a pull request.

This layout has two effects. First, coverage has a hard edge: the infrastructure scan matches fingerprints, so an AI service with no fingerprint file is not identified, and a clean report means no rule matched, not that the target is safe. Second, the compose file mounts ./data into the webserver at /app/data, so a team can drop in its own fingerprint or vulnerability rule for an internal component and have the running container see it, without rebuilding the image. That is useful for in-house services the public rule set will never cover. The catch is that local rule files live inside the git checkout, so a later git pull that touches the same paths can conflict with your additions, and keeping private rules in a separate branch is the safer habit.

Editorial conclusion

A.I.G suits security teams that want one internal console for jailbreak evaluation, MCP and skill audits, agent probing and AI infrastructure fingerprinting, or that only need one of those as a pip-installed CLI. It does not suit anyone who would need to expose it beyond a trusted network, since it has no authentication. Before deploying, decide whether you accept a SYS_ADMIN, seccomp-unconfined agent container on that host, and whether you have a model API key for the MCP, skill and agent scanners.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes