DecodingTrust-Agent Platform (DTap): A Controllable and Interactive Red-Teaming Platform for AI Agents

Paper: arXiv:2605.04808 Code: AI-secure/DecodingTrust-Agent Code reference: main @ f37a6f88 (2026-05-15)

1. Motivation（研究动机）

当前 AI agents 已经不只是回答文本问题，而是在 Gmail、Slack、PayPal、CRM、代码仓库、浏览器、OS 文件系统等外部环境中调用工具、读取第三方内容、执行多步操作。安全风险也因此从“模型是否会说出有害内容”变成“agent 是否会在真实工作流中执行有害动作”：泄露 API key、删除用户数据、发起未授权交易、把敏感 CRM 数据发给攻击者等。

现有 red-teaming 方法主要有三类缺口。第一，很多 LLM red-team 仍停留在静态 prompt 或内容生成层面，无法覆盖 tool call、MCP server、skill、环境数据等 agentic attack surface。第二，AgentDojo、AgentHarm、SHADE-Arena、ST-Web 等 benchmark 覆盖面有限：有的只做直接 prompt injection，有的只做工具输出污染，有的没有 50+ realistic environments、1000+ tools、policy-following risk assessment、autonomous red-teaming agent 与 environment-level verifiable judge 的完整组合。第三，真实服务不能随意被攻击或重置；如果没有可控、可复现、可并行的仿真环境，就很难大规模比较不同 agent harness / backbone 的安全性。

本文要解决的具体问题是：构建一个能在真实形态的 agent 工作流中安全复现攻击、自动生成高质量攻击序列、并用环境状态而非 LLM judge 验证结果的平台。它不是只问“模型会不会拒绝”，而是问“agent 在多步环境交互后，最终有没有真的完成恶意目标”。这很值得研究，因为 agent 安全部署的关键瓶颈往往出现在 harness、MCP/tool trust boundary、外部内容可信度、工具执行顺序和状态验证上；这些问题无法通过普通文本安全 benchmark 充分暴露。

2. Idea（核心思想）

核心 insight：agent red-teaming 必须同时控制“环境、注入面、执行轨迹、最终状态验证”四件事。DTap 把真实应用复制成 sandboxed GUI/MCP environments，让攻击可以被精确注入、重复 replay、并用 judge.py 直接检查环境最终状态；DTap-RED 再在这个闭环里搜索 prompt/tool/skill/environment 及其组合攻击。

关键创新可以概括为三层：DTap 是 14 个高风险领域、50+ 仿真环境和 MCP/GUI 双接口的可控平台；DTap-RED 是一个带 attack skill library、multi-layer memory、verifiable judge feedback 的 autonomous red-teaming agent；DTap-Bench 是 6,682 个任务的 benchmark，其中 2,806 个 benign tasks、1,998 个 indirect red-teaming tasks、1,878 个 direct red-teaming tasks，并为每个 red-teaming task 配置可复现 attack sequence 与 verifiable judge。

与 AgentDojo 的根本区别在于，AgentDojo 更偏静态、受限的工具输出注入 benchmark；DTap 强调 dynamic/stateful environments、tool/skill/environment/direct prompt 多注入面、policy-grounded risk categories、可重置 sandbox 和 environment-state judge。与只做 prompt-level jailbreak 的 AgentHarm 相比，DTap 评估的是 agent harness 是否会在上下文、工具链和环境状态共同作用下执行真实有害动作。

3. Method（方法）

3.1 Overall framework：DTap / DTap-RED / DTap-Bench 闭环

Figure 1 解读：DTap 的核心是把 victim agent 放进可控仿真世界中，而不是只给它一段 adversarial prompt。左侧是 14 个 domains 与 50+ environments；中间是可被攻击的 agent execution pipeline，包括 prompt、MCP tools、skills、environment payloads 等注入点；右侧是 DTap-RED 自动优化攻击，并将成功攻击固化为 DTap-Bench 任务。这个图体现了本文的安全观：风险不是单个输入触发的，而是由外部环境、工具接口、agent harness 和多步状态变化共同产生的。

DTap 平台有三个设计原则：

Realistic but sandboxed：每个环境复制真实 GUI、HTML/accessibility observation、后端和数据库，例如 Gmail、Google Calendar、Slack、PayPal、Salesforce、Browser、Windows/macOS、Finance、Legal、Medical 等；但所有动作都在 sandbox 中执行，可回滚、可重置，不会影响真实账户。
MCP-native agent integration：平台为每个环境提供 MCP-based tool interface，并尽量一对一复制真实 MCP/tool schema。任何支持 MCP 的 agent harness 都可以接入；论文实验接入 OpenAI Agents SDK、Claude Code、Google ADK、OpenClaw 等。
Stateful reproducibility：不同于只记录最终回答的 benchmark，DTap 保留多轮中间状态，支持 deterministic replay、reset endpoint、container isolation 和 parallel execution。攻击成败由环境状态检查，而不是由 agent 自述或 LLM judge 决定。

从直觉上看，DTap 有效的原因是它把“攻击是否被模型拒绝”转化成“攻击是否穿过 trust boundary 并改变了系统状态”。很多 agent 失败不是因为模型不知道某个内容有害，而是因为 malicious instruction 被包装成来自工具、同事、文档、评论、日历备注或 skill 的可信上下文；一旦 harness 批量调用工具、缺少执行前 consequence reasoning，agent 可能先执行有害动作、再在文本里拒绝。

3.2 DTap 平台：环境、MCP 与注入面

DTap 覆盖 Workflow、CRM、Customer Service、Travel、Code、Browser、Research、OS-Filesystem、Windows、macOS、Finance、Legal、Telecom、Medical Service 共 14 个 domains。每个 domain 由一个或多个仿真环境组成；论文列举了 Google Workspace、PayPal、Zoom、Atlassian、WhatsApp、Salesforce CRM、ServiceNow、Browser、E-Bay、Booking.com、Expedia、United/Southwest Airlines、Enterprise、arXiv、Yahoo Finance、Robinhood、GitHub、Snowflake、Databricks、X、Reddit、DoorDash 等。

平台支持四类注入面：

Prompt injection：攻击者直接控制 user prompt，主要用于 direct threat model。
Tool injection：修改 MCP tool description 或 tool metadata，让 agent 在工具选择/参数理解阶段被污染。
Skill injection：插入、追加或创建 agent skill，使 agent 在调用技能时执行恶意逻辑。
Environment injection：通过 Gmail email、Slack message、Calendar note、website review、CRM note 等外部数据源注入 payload；这是 indirect threat model 的核心。

Released code 与这一设计对应：dt_arena/config/mcp.yaml 在 main@f37a6f88 下定义 44 个 MCP server 配置，并映射到 46 个环境名；dt_arena/config/injection_mcp.yaml 定义 30 个 injection MCP server；dt_arena/config/env.yaml 定义 Docker/port/environment orchestration。论文称平台级规模为 50+ environments / 1000+ tools，公开 repo 中能直接看到的是 benchmark task configs、MCP config、injection MCP config 与环境 orchestration 代码。

3.3 DTap-RED：自动红队 agent

Figure 2 解读：DTap-RED 的输入是 malicious goal 和可验证 judge。它先从 multi-layer memory 检索相似 risk category / malicious goal / threat model 的成功或失败经验，再从 attack skill library 选择 jailbreak、encoding、fake conversation、phishing、skill/tool/environment injection 等策略；随后把 payload 注入到 prompt、MCP tool、skill 或 environment 中，让 victim agent 执行任务。每轮结束后，verifiable judge 检查真实环境状态；失败时 refinement judge 分析“未被观察到、被拒绝、工具顺序错误、状态条件未满足”等原因，指导下一轮优化。

DTap-RED 的关键组件：

Policy-following attack generation

攻击目标不是任意“越狱成功”，而是从 domain policies、regulations 与 use-case risks 中抽取严重风险类别，再生成对应 malicious goals。例如 CRM 会引用 GDPR / Salesforce AUP，Finance 会引用 FINRA 相关约束。这样得到的 attack 不只是文本上有害，而是与真实业务规则、合规边界和平台安全政策对齐。

Diverse attack skill library

论文称 DTap-RED 配备 200+ attack strategies，分为 attack algorithms 与 injection strategies。Attack algorithms 包括 GCG、ArtPrompt、AutoDAN、base64 / leetspeak / typographic image injection 等使 payload 更隐蔽的变换；injection strategies 则决定把 payload 放在哪里、怎么包装，例如伪造多轮邮件线程、同事确认消息、public review 中的 phishing link、tool description suffix、skill body backdoor 等。

Flexible injection action space

Action space 同时有空间维度和时间维度。空间维度包括 prompt、tool、skill、environment；时间维度允许多轮、多处注入组合。例如先在 skill 中植入“看到触发词就删除文件”的规则，再在 email 中放入触发词，最后让 agent 处理正常邮件。这类组合攻击中的单个片段可能看起来 benign，但组合后会达成恶意目标。

Multi-layer memory 与 iterative optimization

Memory 按 risk category、malicious goal、threat model 等层次组织成功轨迹和失败模式。论文描述 DTap-RED 采用 $ϵ$ -greedy policy：早期更偏探索 attack space，后期更多利用已有成功经验。这里没有给出完整优化公式；可将每轮选择理解为： $a_{t} = {e x t E x pl ore (A), e x t w i t h p ro babi l i t y ϵ, e x t E x pl o i t (M, g, a u), e x t w i t h p ro babi l i t y 1 - ϵ,$ 其中 $A$ 是可用注入动作/技能集合， $M$ 是 memory， $g$ 是 malicious goal， $a u$ 是 threat model。攻击执行后，verifiable judge 产生 success / partial / failure 反馈，refinement judge 将失败原因转化为下一轮 search hint。

论文公式与 released code 实现差异：论文描述了完整 DTap-RED optimizer（multi-layer memory、 $ϵ$ -greedy、attack skill library、refinement loop），但 AI-secure/DecodingTrust-Agent 在 main@f37a6f88 中主要发布 DTap-Bench 的 task configs、injection replay、evaluation runner、agent wrappers、MCP/Docker orchestration 和 judge；没有定位到完整的 DTap-RED autonomous optimizer / memory search loop。因此下面的 pseudocode 和 code mapping 以公开 repo 中可复现的 benchmark replay/evaluation path 为准，而不是把论文中的 optimizer 伪装成已发布代码。

3.4 DTap-Bench：任务结构与 verifiable judge

Figure 3 解读：DTap-Bench 的任务分布不是单一 domain 或单一攻击类型。左图展示 14 个 domain 的任务覆盖；中图展示 prompt、tool、skill、environment 及组合注入的分布；右图用 minimum tool calls 作为 task complexity proxy，说明很多任务需要多步工具调用，而不是一次文本回复即可完成。

每个任务目录包含三类关键文件：config.yaml、setup.sh、judge.py。config.yaml 定义 Task / Agent / Attack / RedTeamingAgent：包括 domain、task instruction、MCP servers、risk category、policies、threat model、malicious goal、attack_turns 和可用注入面。setup.sh 重置并 seed 初始环境，例如 CRM customer records、Gmail inbox、Slack channels、PayPal balances。judge.py 直接读取最终环境状态：对于 benign task 检查用户目标是否完成；对于 malicious task 检查攻击目标是否真正生效。

核心指标可以写成： $ASR = \frac{# { e x t a tt a c k t a s k s w h ose ma l i c i o u s g o a l i s f u ll y a c hi e v e d }}{# { e x t re d - t e amin g t a s k s }} im es 100%,$ $BSR = \frac{# { e x t b e ni g n t a s k ss u ccess f u ll yco m pl e t e d }}{# { e x t b e ni g n t a s k s }} im es 100%.$ 作者强调 verifiable judge 不依赖 agent 输出或 LLM judge，而是检查 concrete environment outcomes。例如 CRM 危险动作任务中，judge 会检查两个高价值机会是否真的从 Salesforce 中删除；PayPal payout 任务会同时检查收款人、金额和状态是否为 COMPLETED。这降低了“agent 声称拒绝但已经执行”或“LLM judge 被轨迹文本误导”的误判。

3.5 Released-code-grounded pseudocode

下面 pseudocode 映射公开 repo 的 evaluation / replay 实现，而不是论文中未完整开源的 DTap-RED optimizer。

from pathlib import Path
from typing import Dict, List, Optional
 
async def run_dtap_benchmark(task_list: Path, agent_type: str, model: str, max_parallel: int = 5):
    task_specs = parse_task_list_or_directory(task_list)
    scheduled_tasks = [
        ScheduledTask(
            task_dir=spec.task_dir,
            environments=frozenset(get_task_environments(spec.task_dir)),
            original_index=i,
            domain=spec.domain,
            task_type=spec.task_type,
            threat_model=spec.threat_model,
            risk_category=spec.risk_category,
            task_id=spec.task_id,
        )
        for i, spec in enumerate(task_specs)
    ]
 
    executor = TaskExecutor(max_parallel=max_parallel)
 
    async def run_one(task, env_instances):
        return await run_single_task_subprocess(
            task=task,
            instances=env_instances,
            agent_type=agent_type,
            model=model,
        )
 
    return await executor.run_all(scheduled_tasks, run_one)

from dt_arena.src.types.task import AttackConfig
 
async def replay_attack_turns(task_dir: Path, agent_type: str, model: str):
    config_path = task_dir / "config.yaml"
    agent_cfg = AgentConfig.from_yaml(str(config_path))
    task_cfg = TaskConfig.from_yaml(str(config_path))
    attack_cfg: Optional[AttackConfig] = AttackConfig.from_yaml(str(config_path))
 
    task_setup(task_dir)
    mcp_manager = start_task_mcp_servers(agent_cfg)
 
    tool_injections = build_tool_injections_from_config(attack_cfg)
    skill_injections = build_skill_injections_from_config(attack_cfg)
    env_injections = get_env_injections_from_attack(attack_cfg)
 
    injection_urls = start_needed_injection_mcp_servers(env_injections)
    instruction = apply_prompt_injections(task_cfg.original_instruction, attack_cfg)
 
    runtime = RuntimeConfig(
        model=model,
        max_turns=200,
        mcp_injection=tool_injections,
        skill_injection=skill_injections,
    )
    agent = build_agent(agent_type=agent_type, agent_cfg=agent_cfg, runtime_cfg=runtime)
 
    async with agent:
        for turn_id, turn_instruction in enumerate(as_turn_list(instruction), start=1):
            turn_env_injections = get_env_injections_from_attack(attack_cfg, turn_id=turn_id)
            await apply_environment_injections_async(turn_env_injections, injection_urls)
            result = await agent.run(turn_instruction, metadata={
                "task_id": task_cfg.task_id,
                "domain": task_cfg.domain,
                "risk_category": attack_cfg.risk_category if attack_cfg else None,
            })
 
    return run_judge(task_dir, response=getattr(result, "final_output", ""))

class VerifiableJudge(BaseJudge):
    def eval_task(self, agent_responses=None):
        state = read_environment_state()
        return check_benign_goal_completed(state)
 
    def eval_attack(self, agent_responses=None):
        state = read_environment_state()
        critical_conditions = [
            condition_1_harmful_action_happened(state),
            condition_2_target_and_amount_match(state),
            condition_3_state_is_finalized_not_pending(state),
        ]
        if all(critical_conditions):
            return True, {"message": "ATTACK SUCCESS"}
        return False, {"missing_conditions": critical_conditions}

Code reference: main @ f37a6f88 (2026-05-15) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
DTap-Bench task lists	`benchmark/<domain>/*.jsonl`（例如 `benchmark/crm/indirect.jsonl`）	domain/type/threat_model/risk_category/task_id records
Task / Attack schema	`dt_arena/src/types/task.py`	`TaskConfig`, `AttackStepConfig`, `AttackTurn`, `AttackConfig`
Agent / MCP schema	`dt_arena/src/types/agent.py`	`AgentConfig`, `RuntimeConfig`, `MCPServerConfig`, `ToolInjection`, `SkillInjection`
Benchmark runner	`eval/evaluation.py`	`_run_all_tasks`, CLI args `--task-list`, `--max-parallel`, `--agent-type`, `--model`
Single-task replay	`eval/task_runner.py`	`run_single_task`, prompt/tool/skill/env injection application, `run_judge`
Environment pooling	`utils/task_executor.py`	`TaskExecutor`, `get_task_environments`, Docker compose instance reuse
Injection replay	`utils/injection_helpers.py`	`build_tool_injections_from_config`, `apply_prompt_injections`, `apply_environment_injections_async`
Skill injection	`utils/skill_helpers.py`	`create_injected_skills_directory`, `apply_injection_to_content`
Verifiable judges	`dataset/**/judge.py`, `utils/judge_helpers.py`	class-based `Judge.eval_task`, `Judge.eval_attack`, `run_judge`
MCP/environment config	`dt_arena/config/mcp.yaml`, `dt_arena/config/injection_mcp.yaml`, `dt_arena/config/env.yaml`	44 MCP servers, 30 injection MCP servers, Docker/port config observed in repo

4. Experimental Setup（实验设置）

Datasets and scale

DTap-Bench 总计 6,682 tasks，覆盖 14 domains：Workflow 520、CRM 405、Customer Service 361、Travel 355、Code 616、Browser 201、Research 404、OS-Filesystem 600、Windows 347、macOS 133、Finance 600、Legal 600、Telecom 447、Medical 1,093。按任务类型划分：2,806 benign tasks、1,998 indirect red-teaming tasks、1,878 direct red-teaming tasks；论文 benchmark overview 将 3,876 red-teaming tasks 对应为 3,876 unique malicious goals。正文贡献处写 “4K+ malicious goals”，而表格与 released benchmark JSONL 计数对应 3,876；本笔记的精确实验数值以 Table / released benchmark 计数为准。

Figure 4 解读：论文用 Claude Code trajectories 的 t-SNE 对比 DTap 与 AgentDojo，意图说明 DTap 任务轨迹覆盖的操作空间更宽。它不是主要性能图，而是 benchmark diversity 的补充证据：DTap 不只是在少数固定工具调用模板上做安全评估。

Evaluated agents / baselines

平台层面的比较对象包括 AgentHarm、AgentDojo、RedTeamCUA、SHADE-Arena、ST-Web；论文的 Table 1 逐项比较 realistic environments、realistic tools、diverse threat models、environment/tool/skill/direct prompt injections、diverse red-teaming algorithms、policy-following risk assessment、autonomous red-teaming agent、environment-level verifiable judge，DTap 是唯一全覆盖者。

主实验评估的 agent/model 配置为 8 个：OpenAI Agents SDK + GPT-5.4 / GPT-5.2 / GPT-OSS-120B，Claude Code + Sonnet-4.5，Google ADK + Gemini-3-Pro，OpenClaw + GPT-5.5 / GPT-5.2 / DeepSeek-V4-Pro。论文正文有一处写 “six agent configurations”，但 ASR/BSR 表实际报告 8 个配置。

Metrics

ASR（Attack Success Rate）：red-teaming task 中 malicious goal 被完全达成的比例；indirect 与 direct threat model 分开报告。
BSR（Benign Success Rate）：benign task 中用户合法目标被完成的比例，用来衡量 agent utility。
Minimum tool calls：appendix 用每个 task 的最少工具调用数衡量任务复杂度。
Optimization iterations / attack-skill ASR：用于评估 DTap-RED 搜索攻击的效率和 attack skill library 覆盖度。

Evaluation config / compute notes

论文没有给出传统“训练”设置，因为本文是平台和 benchmark 工作，不训练新模型。实际评估配置包括：最大 10 次 attack optimization iterations 生成成功攻击；released repo 的 eval/evaluation.py CLI 默认 --max-parallel=5，eval/task_runner.py 的 run_single_task 默认 max_turns=200，README 示例展示 --max-parallel 4/8/16 作为运行规模参数。硬件/GPU 类型没有在论文中详细说明；作者报告数据构建投入约 16,000 human hours、17 名 red-teaming experts、20 个月和约 $120,000 API credits。

5. Experimental Results（实验结果）

Main ASR / BSR numbers

Figure 5 解读：横轴是 benign capability（BSR），纵轴是 attack vulnerability（ASR）。理想 agent 应该在右下角：高 BSR、低 ASR。图中没有任何主流 agent 同时做到极高 utility 和极低 vulnerability；Claude Code / Sonnet-4.5 相对更稳健，但仍有 25% 以上 ASR，说明 prompt-level safety 或模型 alignment 不能单独解决 agentic execution 风险。

Agent / Model	Indirect ASR	Direct ASR	BSR	主要结论
OpenAI Agents / GPT-5.4	40.0	51.0	85.3	utility 高，但 direct prompt misuse 仍高
OpenAI Agents / GPT-5.2	46.7	58.8	80.5	同 backbone 换 harness 可显著影响 ASR
OpenAI Agents / GPT-OSS-120B	28.5	46.5	36.2	能力弱导致 BSR 低，ASR 解释需谨慎
Claude Code / Sonnet-4.5	25.2	26.9	80.8	两种 threat model 下最稳健的主表配置
Google ADK / Gemini-3-Pro	55.7	47.9	87.0	BSR 最高，但 indirect ASR 最高
OpenClaw / GPT-5.5	17.7	28.9	86.3	强 harness + closed model 组合较稳健
OpenClaw / GPT-5.2	35.6	38.6	78.5	相比 OpenAI Agents / GPT-5.2，ASR 明显更低
OpenClaw / DeepSeek-V4-Pro	41.7	59.6	83.3	direct misuse 最脆弱，体现 open-source backbone instruction-following 风险

关键数值：Google ADK / Gemini-3-Pro 在 indirect threat model 下最高 ASR 为 55.7%，同时 BSR 最高为 87.0%；OpenClaw / DeepSeek-V4-Pro 在 direct threat model 下最高 ASR 为 59.6%；Claude Code / Sonnet-4.5 的 indirect/direct ASR 为 25.2% / 26.9%，BSR 为 80.8%。

Injection-surface analysis

工具和 skill 注入通常比环境注入更危险，因为 agent harness 往往把内部化的 tool/skill metadata 当作更可信上下文。具体来说，OpenAI Agents / GPT-5.4 的 skill injection ASR 为 83.3%，environment injection ASR 为 22.2%；Google ADK / Gemini-3-Pro 的 tool injection ASR 为 63.4%，skill injection ASR 为 83.3%。组合注入会放大风险，例如 OpenAI Agents / GPT-5.2 的 tool injection ASR 为 50.1%，env+tool 组合升至 65.6%。OpenClaw / GPT-5.5 的 tool injection ASR 只有 21.1%，说明 harness 的 tool trust calibration 可能比单纯换 backbone 更关键。

Harness design matters more than model-only alignment

论文给出一个直接对照：同样使用 GPT-5.2 backbone，从 OpenAI Agents SDK 换到 OpenClaw 后，direct ASR 从 58.8% 降到 38.6%，indirect ASR 从 46.7% 降到 35.6%，combined ASR 约降低 31%，BSR 只下降约 2%。这说明 agent 安全不能只靠模型拒答；tool-call sandboxing、pre-execution consequence reasoning、trusted-input isolation、sequential tool invocation 等 harness-level 设计会显著改变结果。

Figure 6 解读：CRM domain 的 per-category radar 显示，Data Exfiltration、Dangerous Actions 等 context-aware 风险更容易成功，因为它们通过多步工具调用和业务上下文伪装成合法操作；General AI Restrictions、Fraud / Impersonation 等更接近内容层面的风险，模型 alignment 更容易拒绝。这个图支持作者的核心判断：agent 风险的难点在信息流和状态变化，而不是单句有害内容识别。

DTap-RED ablations

Figure 7 解读：CRM domain 中，DTap-RED 通常在 2–5 次优化迭代内找到成功攻击；Fraud & Impersonation 这类复杂类别可到 6.3 次，Misinformation & Hallucination / Data Exfiltration 可低至 1.4 / 1.8 次。右图显示第一轮 ASR 约 37%，3 次迭代内超过 85%，10 次迭代接近 100%。这证明 verifier feedback 对 attack search 有明显帮助。

Figure 8 解读：不同 attack skills 的有效性高度依赖 risk category。Multi-turn fake conversation 和 general-misinformation 在 CRM 中 ASR 超过 50%；stealthy email injection、AutoDAN-turbo 在 30%–40% 区间；fake-email-thread、leetspeak-attack 等在某些 risk categories 可接近 100%。这说明 attack library 的价值不在单个“万能 jailbreak”，而在能按 domain / risk / injection surface 组合选择。

Limitations and caveats

作者没有单列 limitations，但从论文与 released code 可见几个边界：第一，DTap 是高保真仿真平台，仍不等价于真实生产系统；其优势是 controllability 和 reproducibility，而不是证明真实服务上的绝对 ASR。第二，ASR/BSR 衡量的是 judge 定义的任务完成与攻击完成，不能覆盖所有潜在 harm severity 或长期后果。第三，攻击序列是用 surrogate agent 优化后 zero-shot transfer 到其他 agents；因此结果反映 transferability，但也依赖 surrogate、task construction 和人工筛选。第四，公开 repo 在 main@f37a6f88 中没有完整发布 DTap-RED optimizer 的 memory / strategy-search loop，复现论文 attack generation 细节仍需要更多实现或数据资产。

总体结论：DTap 表明当前 frontier agents 在真实形态的 tool-use / environment-use 工作流中仍有系统性漏洞。最重要的发现不是某个模型排名，而是三点：组合注入显著更危险；context-aware 多步状态风险比内容安全更难；agent harness 的 tool execution policy、trust boundary 和 consequence reasoning 会显著改变安全-能力 trade-off。

Paper Notes

探索

DecodingTrust-Agent Platform (DTap): A Controllable and Interactive Red-Teaming Platform for AI Agents

DecodingTrust-Agent Platform (DTap): A Controllable and Interactive Red-Teaming Platform for AI Agents

1. Motivation（研究动机）

2. Idea（核心思想）

3. Method（方法）

3.1 Overall framework：DTap / DTap-RED / DTap-Bench 闭环

3.2 DTap 平台：环境、MCP 与注入面

3.3 DTap-RED：自动红队 agent

Policy-following attack generation

Diverse attack skill library

Flexible injection action space

Multi-layer memory 与 iterative optimization

3.4 DTap-Bench：任务结构与 verifiable judge

3.5 Released-code-grounded pseudocode

4. Experimental Setup（实验设置）

Datasets and scale

Evaluated agents / baselines

Metrics

Evaluation config / compute notes

5. Experimental Results（实验结果）

Main ASR / BSR numbers

Injection-surface analysis

Harness design matters more than model-only alignment

DTap-RED ablations

Limitations and caveats

目录