AI-Infra-Guard: why agent red teaming needs one method per layer
A framework released on 30 June 2026 argues the agent attack surface is stratified — infrastructure, tools, behavior, model — and no single detection method fits all four.
What is this?
On 30 June 2026, researchers from Tencent Zhuque Lab published a technical report describing AI-Infra-Guard, an open-source red-teaming platform for AI systems. The paper’s organising claim is worth pausing on: the attack surface of a modern AI agent is not a single flat target but a stack of distinct layers — the underlying infrastructure, the protocol and tool integrations, the agent’s runtime behavior, and the model itself — and no single detection paradigm covers all of them well. The contribution is defensive and methodological: it maps a testing method to each layer rather than pretending one scanner can catch everything. The code is public on GitHub under the Tencent organisation, so this is a released tool with an accompanying paper, not a paper describing a private capability.
How it works
The framework’s design follows the layered thesis directly. For the infrastructure layer, where problems tend to be concrete and enumerable, it uses deterministic rule matching — the report describes coverage of 75+ AI components and more than 1,400 vulnerability rules, the kind of signature-based checking that suits known software flaws and misconfigurations. For the protocol and tool layer, it applies LLM-driven agentic auditing of MCP servers and agent-skill packages, because those artifacts are semi-structured and their risks (over-broad permissions, hidden instructions, unsafe tool descriptions) are semantic rather than purely syntactic. For agent behavior, it runs multi-turn black-box red teaming, interacting with the agent as an adversary would over a conversation rather than inspecting a single response. For the model layer, it ships a jailbreak evaluation harness described as covering 26+ attack operators across sixteen datasets, so alignment robustness is measured against a spread of known techniques rather than a single prompt.
The important idea is not any one of these components but the reason they are separated. Signature rules are precise but blind to novel semantic abuse; LLM-based auditing catches semantic issues but is nondeterministic and can miss a known flaw that a rule would flag instantly; multi-turn probing surfaces behavioral drift that a static scan never sees. Collapsing them into one tool tends to inherit the weaknesses of whichever paradigm dominates.
Why it matters
Most teams securing an agent deployment reach for a single instrument — a prompt-injection classifier, or a dependency scanner, or a jailbreak test set — and implicitly treat that as coverage. The layered view makes the gap visible. A hardened model behind a jailbreak-resistant guardrail still fails if its MCP server exposes an unauthenticated tool; a locked-down infrastructure still leaks if an installed skill package carries an embedded instruction the agent obeys. Framing the surface as four layers with different failure physics is a useful planning tool even for teams that never run this specific software, and it lines up with the direction of OWASP’s agentic-security work and MITRE ATLAS, which likewise decompose agent risk rather than treating it as one monolithic problem. It also reflects a maturing ecosystem: red-teaming AI is moving from ad hoc prompt fiddling toward structured, tooled programs.
Defenses
The practical takeaway is to test the way the surface is actually shaped. Cover each layer with a method suited to it rather than assuming one control generalises: signature and dependency scanning for infrastructure and known component flaws; semantic auditing of every MCP server and skill package you install, with attention to tool descriptions and requested scopes; multi-turn behavioral probing of the assembled agent, not just single-prompt checks; and a jailbreak/alignment test set run against the specific model and system prompt you ship, refreshed as new operators appear. Treat a green result in one layer as evidence about that layer only. Where you adopt an open framework like this one, review what it does and does not exercise, keep its rule sets updated, and pair automated scanning with human review — automated auditing narrows the search space but does not certify safety. Finally, record which layer each finding belongs to, so remediation lands with the right owner instead of being filed as a generic “AI risk.”
Status
This is a released open-source tool with a technical report, not a vulnerability disclosure; it introduces no CVE. The value to track is the layered methodology and whether your own testing covers all four layers.
| Item | Detail |
|---|---|
| Publication | arXiv technical report, 30 June 2026 |
| Origin | Tencent Zhuque Lab (Tencent Security Platform Department) |
| Layers | Infrastructure, protocol/tool, agent behavior, model |
| Components | 75+ AI components, 1,400+ vulnerability rules; 26+ jailbreak operators, 16 datasets |
| CVE | None (defensive red-teaming framework) |