项目辨析：本文介绍的是 aiconnai/agentshield，不是其他同名的 AgentShield 项目。官方仓库当前 README 标注版本为 v1.0.1，核心定位是离线优先的 Rust 安全扫描引擎。

一句话结论

AgentShield 适合放在 MCP Server、AI Agent 工具仓库和 Agent 配置进入团队或生产环境之前：它在本地分析源码、工具描述、依赖和配置，识别命令注入、凭证外泄、SSRF、不安全文件访问、动态代码执行、提示注入面和依赖风险，并可输出 SARIF 接入 GitHub Code Scanning。

它的稳定能力是发布前静态扫描和策略评估；运行时 Guard 和 MCP Proxy 目前仍是实验性功能，不能把它当作已经成熟的在线 Agent 防火墙或沙箱替代品。

AgentShield 解决什么问题

MCP Server 和 Agent 扩展通常同时具备网络访问、文件操作、命令执行、依赖安装和外部数据读取能力。传统 SAST 工具可以覆盖部分代码问题，但未必理解 MCP 工具描述、Agent 配置、提示注入面和工具调用链。

AgentShield 将这些对象放到同一份扫描报告中，主要检查：

• 命令执行：Shell、子进程和动态命令拼接。
• 凭证泄露：环境变量、密钥文件、Token 和外发请求之间的关联。
• SSRF 与元数据访问：包括云实例元数据服务等高风险目标。
• 文件访问：不安全路径、越权读取和敏感文件访问。
• 动态代码执行：危险的解释执行和下载后执行链。
• 不安全反序列化：例如不安全的 YAML 反序列化器。
• 提示注入面：工具响应、日志、外部内容和 Agent 指令混用的风险。
• 依赖卫生：未固定版本、危险依赖和供应链相关问题。
• MCP 配置：Server Manifest、工具名称、工具 Schema 和传输配置。
• 路径间数据流：在 Python、TypeScript 等代码中跨函数跟踪不可信输入到危险 Sink 的流向。

官方 README 当前列出 37 个内置上下文规则，并支持通过 YAML 声明自定义规则。规则数量和覆盖范围会随版本变化，实际项目应以运行时 agentshield list-rules 的结果为准。

支持的对象和开发框架

语言支持并不等同于“所有语言都做同等深度的源码分析”。当前项目将 Python、TypeScript/TSX 和 Shell 列为主要扫描对象；官方 README 明确说明，Go、Ruby、Java 和 Rust 源文件在当前版本中不做执行级解析或统一执行面分析，可以与其他扫描器组合使用。

安装方式

方式一：下载官方安装脚本

macOS 和 Linux 可以使用项目 README 给出的安装命令：

curl -fsSL https://aiconnai.github.io/agentshield/install.sh | sh

生产环境不建议盲目执行远程脚本。更稳妥的做法是先下载脚本、审查内容，再在固定版本或经过校验的环境中运行。

方式二：Homebrew

brew tap aiconnai/tap
brew install agentshield

方式三：Cargo 从指定 Release 构建

项目官方 README 给出的版本安装命令是：

cargo install --git https://github.com/aiconnai/agentshield \
  --tag v1.0.1 --features full --force

full 特性会包含 Python、TypeScript、运行时代理和实验性 Runtime Guard。需要注意，AgentShield 是 Rust 项目，安装 Cargo/Rust 工具链后才能使用此方式。

方式四：从源码构建

git clone https://github.com/aiconnai/agentshield.git
cd agentshield
cargo build --features full --release
./target/release/agentshield scan /path/to/agent-extension

Windows 用户可以使用对应的 .exe 文件路径。官方 Release 页面提供 x86_64-pc-windows-msvc 等平台制品，优先使用与目标平台匹配的已发布二进制，可以减少本地编译依赖。

第一次扫描

进入待扫描的 Agent 或 MCP 项目目录，先运行：

agentshield quickstart

quickstart 会生成首次使用所需的配置建议、推荐 CI 设置、执行第一次扫描并解释结果。

也可以直接扫描当前目录：

agentshield scan . --ignore-tests --fail-on high --explain

参数含义如下：

建议第一次不要直接使用过于严格的门禁阻断所有提交，先用 --explain 理解项目发现，再决定哪些等级进入 CI 阻断策略。

选择报告格式

AgentShield 支持以下输出格式：

# 默认控制台输出
agentshield scan . --format console

# JSON，供脚本或其他平台处理
agentshield scan . --format json --output agentshield.json

# SARIF，接入 GitHub Code Scanning
agentshield scan . --format sarif --output results.sarif

# 独立 HTML 报告，便于分享和人工查看
agentshield scan . --format html --output report.html

格式选择建议：

接入 GitHub Actions

AgentShield 官方 README 和 docs/mcp-security-scanner.md 提供了以下工作流示例：

name: Agent Security

on: [push, pull_request]

permissions:
  actions: read
  contents: read
  security-events: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: aiconnai/agentshield@main
        with:
          path: '.'
          fail-on: 'high'
          ignore-tests: true
          upload-sarif: true

在组织级生产流水线中，建议进一步固定 Action 到经过审核的版本或 Commit SHA，而不是长期直接跟随 main。同时确认仓库确实需要 security-events: write，避免为了上传 SARIF 而授予多余权限。

如果希望同时启用通用代码和密钥扫描，可以使用：

agentshield ci install --suite

官方说明该模式会生成包含 CodeQL、Gitleaks、Semgrep CE 和 AgentShield 的 GitHub Actions 工作流。实际启用前仍应检查生成文件中的 Action 版本、权限和触发范围。

配置项目策略

在项目根目录执行：

agentshield init

这会生成 .agentshield.toml 起始配置。官方示例中，策略可以设置扫描门禁和路径过滤：

[scan]
ignore_tests = true
include = ["src/**", "server/**"]
exclude = ["docs/**", "examples/**"]

[policy]
fail_on = "high"

路径过滤需要结合 --explain 检查实际生效范围。当 include 和 exclude 同时匹配时，官方文档说明 exclude 优先。

自定义声明式规则

将自定义规则放入 .agentshield/rules/，例如：

id: "ORG-002"
name: "Banned Deprecated Library"
description: "Disallow telnetlib in agent tools"
severity: "medium"
attack_category: "supply_chain"
match:
  banned_dependencies:
    - name: "telnetlib"
      reason: "Insecure unencrypted remote protocol"
  tool_name_regex: "^telnet_"

再运行：

agentshield scan . --explain

自定义规则应当先在非阻断模式验证命中范围，避免规则过宽导致整个 Agent 仓库无法提交。

处理已知发现：Baseline 和 Suppression

Baseline

已有安全问题的老项目不必一次性修完所有历史结果，可以先生成 Baseline：

agentshield scan --write-baseline .agentshield-baseline.json
agentshield scan --baseline .agentshield-baseline.json --explain
agentshield ci install --baseline .agentshield-baseline.json

Baseline 的作用是记录已知发现，让 CI 更关注新引入的问题。Baseline 文件本身应当纳入代码审查，避免有人通过重新生成文件把新增问题全部隐藏。

Suppression

对于确认是误报、且有明确业务理由的发现，可以按 fingerprint 抑制：

agentshield suppress <fingerprint> \
  --reason "该工具只接收固定枚举值，已通过额外校验"

agentshield list-suppressions

抑制项应当设置负责人、理由和可选过期时间。不要用 suppression 代替修复真实的命令注入、凭证泄露或 SSRF 风险。

自动修复

AgentShield 的 fix 命令用于修复部分确定性问题，例如不安全反序列化器和未固定依赖版本。先预览差异：

agentshield fix . --dry-run

确认变更范围后再执行：

agentshield fix .

官方 README 还提供 VS Code 扩展，支持在编辑器中显示诊断，并通过灯泡操作执行部分一键修复。自动修复后仍应运行测试和重新扫描，因为安全工具不能替代业务语义验证。

运行时 Guard：当前应如何理解

AgentShield 的稳定契约是离线静态扫描和策略评估。runtime-guard 是可选特性：

cargo run --features runtime-guard -- guard --stdin

它可以读取一个 Runtime Event JSON，返回 allow、warn 或 block 判定。官方文档规定：allow 和 warn 返回退出码 0，block 返回退出码 3；无效 JSON、超过 1 MiB 的输入和不支持的调用会 fail-closed。

构建完整特性：

cargo build --features full --release

MCP Proxy Guard

实验性的 MCP Proxy 位于 Agent Host 和 MCP Server 之间，检查 tools/call：

Agent Host → AgentShield Proxy → MCP Server
                 ↓
          allow / warn / block

它只在工具请求进入下游 Server 前做策略判断，不执行工具逻辑。允许或警告的请求会继续转发；阻断请求不会到达下游 Server，并返回安全的 JSON-RPC 错误。使用时需要明确：

• Proxy Guard 仍是实验性实现。
• 兼容性和运行时保证尚未达到静态扫描的稳定程度。
• 它不是完整沙箱，也不能替代网络隔离、凭证最小化和人工审批。
• Runtime Event、工具参数、路径和 URL 可能包含敏感数据，日志前必须完成脱敏。

实际部署建议

发布前

1. 在 MCP Server 和 Agent 扩展仓库中执行 agentshield scan。
2. 检查 High/Critical 发现的证据、文件位置和数据流。
3. 对外部可控输入与 Shell、文件、网络 Sink 的链路做人工复核。
4. 生成 SARIF 并接入 Pull Request 检查。
5. 为已确认的历史问题建立 Baseline，而不是降低全部规则等级。

安装第三方 MCP Server 前

1. 固定仓库 Commit、Release 或镜像摘要。
2. 扫描 Manifest、工具 Schema、源码和锁文件。
3. 检查它需要的环境变量、文件目录和网络目的地。
4. 审查是否存在动态下载、任意 Shell、广泛文件读取和外发请求。
5. 使用最小权限的运行身份，在隔离环境中做首次运行。

进入生产前

1. 将 Agent 身份与开发者身份分离。
2. 使用任务范围内的短时凭证。
3. 对公网出站、云元数据、内部 API 和高影响写操作设置独立策略。
4. 对提示注入和工具响应投毒做对抗测试。
5. 将扫描结果、工具调用、审批和最终变更通过会话 ID 关联到审计系统。

项目边界

与同名项目的辨析

GitHub 上存在多个名为 AgentShield 的仓库。本文目标项目是：

• 仓库：aiconnai/agentshield
• Crate：agent-shield
• 主要语言：Rust
• 许可证：MIT OR Apache-2.0
• 核心能力：离线静态扫描、策略评估、SARIF 输出、可选实验性运行时 Guard

站内已有文章提到的 Yassin-H-Rassul / AgentShield 是另一个项目，不能将其功能、版本、许可证或使用方式套用到本文介绍的仓库上。

项目状态

截至 2026-09-08 核验：

• 官方仓库 Star：18
• Fork：2
• 仓库公开 Commit：342（GitHub 页面数据，动态指标）
• 当前 Release：v1.0.1，2026-08-19 发布
• License：MIT OR Apache-2.0
• 默认分支：main
• 仓库创建时间：2026-02-14

GitHub API 在本次核验时触发了限流，因此 Star、Fork 和 Commit 数量以 GitHub 页面提取结果与搜索结果为准；版本、许可证、目录和命令则通过官方仓库页面、Release 页面和源码克隆交叉核对。项目主页和 Release 下载页可能随时间变化，使用时应以官方仓库为准。

结语

AgentShield 的实际价值在于把 Agent 特有的安全检查前移到“安装和发布之前”：先扫描 MCP Server、工具实现、Agent 配置和依赖，再决定是否允许进入 CI、编辑器或生产环境。

最推荐的使用方式不是单独依赖它，而是将它放进一条分层流水线：AgentShield 负责 Agent/MCP 语义相关的静态检查，CodeQL、Gitleaks、Semgrep 和依赖扫描器负责通用代码与供应链问题，运行时再用最小权限、网络控制、沙箱和审批策略限制实际影响范围。

参考资料

• AgentShield 官方 GitHub 仓库
• AgentShield v1.0.1 Release
• MCP Security Scanner 文档
• Runtime Guard 文档
• AgentShield LICENSE
• AgentShield Cargo.toml
• AgentShield 官方项目主页

来源字段：2026-09-08｜aiconnai/agentshield 官方仓库及 Release｜https://github.com/aiconnai/agentshield｜介绍 AgentShield 的离线静态扫描、MCP/Agent 框架适配、GitHub Action、自动修复、SARIF 输出和实验性运行时 Guard｜适合在 Agent 工具安装、代码提交和发布前建立安全门禁，但不能替代运行时隔离、最小权限、网络控制和人工审批。

本文根据 Northflank 文章《AI-agent sandbox security checklist: What enterprises should evaluate》整理。原文由 Deborah Emeni 撰写，发表于 2026 年 9 月 3 日。本文保留其企业评估框架，并补充面向安全团队的落地检查方式。

一句话结论

企业评估 AI Agent 沙箱时，不能只接受“已经隔离”这一句产品描述；真正需要验证的是：沙箱能否把恶意代码、提示注入、恶意依赖和工具响应的影响限制在预期边界内，以及身份、凭证、网络、数据、资源、生命周期和审计控制是否能独立于 Agent 生效。

Northflank 原文的重点不是推荐某一种沙箱技术，而是要求企业把沙箱当成一条完整的执行边界来审查。微虚拟机或 gVisor 可以增强运行时隔离，但不能替代授权、网络策略、密钥管理、审计和上线前的对抗测试。

为什么 Agent 沙箱不能只看“容器化”

AI Agent 可能执行代码、安装依赖、读取文件、访问 API、调用工具，甚至修改基础设施。只要 Agent 能接触到不可信输入或不受控的工具响应，攻击者就可能通过直接或间接提示注入，诱导它执行超出原始任务的操作。

需要纳入威胁模型的不可信对象包括：

• Agent 生成的命令和代码。
• 用户上传的文件。
• 外部代码仓库和 Pull Request。
• 安装脚本、软件包和构建依赖。
• 网页、搜索结果和检索内容。
• 工具返回值和第三方 API 响应。
• Agent 的持久化记忆、缓存和工作目录。

需要保护的对象则包括宿主机和内核、编排服务、云凭证、挂载文件、内部 API、其他租户、控制平面、生产数据和审计系统。

因此，“Agent 能否运行代码”不是唯一问题，更关键的是：一旦 Agent 或其依赖被操纵，代码还能触达哪些系统？

十项企业级检查清单

1. 明确威胁模型和信任边界

在选择沙箱前，先画出数据流和信任边界，而不是先选择某个产品。

至少应记录：

红队应当能够根据这份图和假设，测试沙箱内代码可以到达什么位置，以及一个泄露的平台凭证可以改变什么。

2. 让隔离强度匹配工作负载

隔离边界应当由代码信任程度、租户数量、可访问数据和潜在影响决定。

评估供应商时，不要只问“是不是 microVM”。还要问：

• Guest 是否拥有独立内核？
• 宿主设备和文件系统暴露了什么？
• 默认移除了哪些 Linux capabilities 和特权？
• 宿主机、运行时和基础镜像如何打补丁？
• 已运行的沙箱是否必须重启才能获得修复？
• 如何验证容器逃逸、设备访问和跨租户访问？

Northflank 文档将其 Sandboxes 描述为微虚拟机支持的容器服务，并提供 gVisor 等运行时隔离选项；具体可用运行时取决于提供商和区域，企业不应把文档中的能力直接视为所有部署位置的默认配置。

3. 分离人、Agent 和工作负载身份

Agent 不应继承开发者登录会话，也不应使用共享管理员 Token。一次执行至少应当能够追溯到：

• 发起人。
• Agent 或工作负载身份。
• 策略版本。
• 目标资源和租户。
• 请求参数。
• 授权时间窗口。
• 最终执行结果。

从测试环境进入生产环境时，应重新做一次授权决策，而不是沿用测试阶段的授权上下文。

如果使用平台 API，应为自动化程序创建来自最小 RBAC 角色的 API Token，并设置过期时间。Northflank 文档明确说明 API Token 继承其 RBAC 角色权限，Token 密文只在创建时显示一次，不能提交到代码仓库。

4. 将密钥限制在单个任务

给沙箱注入密钥，不等于给 Agent 授予业务权限。密钥应当同时满足：

• 只注入当前任务需要的值。
• 绑定到指定工作负载或服务。
• 具备明确的撤销时间窗口。
• 尽可能是短时、窄权限和受众绑定的凭证。
• 不出现在命令行、日志、错误消息和模型上下文中。
• 任务结束后能够撤销或失效。

安全团队需要分别审查“谁可以把密钥注入沙箱”和“持有该密钥的程序可以执行什么业务操作”。这两者不能用同一个权限开关代替。

5. 默认拒绝网络访问

推荐从无公网入站、默认拒绝出站开始，只放行任务明确需要的目的地。

网络检查应覆盖：

• 入站端口是否默认关闭。
• 出站域名是否使用 allowlist。
• DNS 查询是否可被滥用为隐蔽通道。
• 是否能访问云实例元数据服务。
• 是否能访问内部控制平面、数据库和管理 API。
• 是否可以直接向任意公网地址上传文件。
• 不同租户和不同任务之间是否能互相通信。

如果域名级控制无法验证请求内容，应在出口增加网关，对目标、方法、参数和载荷进行校验。Northflank 的 BYOC 网络策略文档提醒：如果某个方向没有配置规则，流量可能仍然被允许，因此“配置了网络策略”不等于“已经默认拒绝”。

6. 把文件、记忆、缓存和持久化存储单独治理

存储状态不是计算资源的附属品，而是另一条安全边界。

应当分别回答：

• Agent 能读取工作目录之外的哪些文件？
• 不同任务是否共享缓存？
• 暂停、恢复和重启后哪些数据仍然存在？
• 持久化卷是否跨租户复用？
• 删除沙箱时是否同时删除快照、卷和临时文件？
• 是否有数据保留期限和人工清理流程？
• 任务输出是否可能把密钥或内部数据带出沙箱？

短任务优先使用临时根文件系统。只有确实需要跨重启保存工作区时，才启用持久化卷，并单独设计访问授权、加密、备份和销毁策略。

7. 控制镜像、依赖和工具供应链

沙箱只能限制运行边界，不能自动证明镜像、软件包和工具是安全的。以下对象都应纳入供应链审查：

• 基础镜像和镜像标签。
• 启动脚本和初始化组件。
• Agent 安装的 npm、PyPI 或系统软件包。
• 外部仓库中的构建脚本。
• MCP Server、插件和工具适配器。
• 沙箱平台自身的运行时和宿主组件。

上线前至少应测试恶意软件包、依赖混淆、被替换的镜像标签和恶意工具响应。镜像扫描是必要控制，但扫描结果不能证明运行时行为安全；还需要固定来源、锁定版本、验证签名或摘要，并保留构建和部署证据。

8. 限制资源并验证生命周期清理

没有资源限制的 Agent，即使没有逃逸，也可能通过死循环、并发任务或超大输出造成拒绝服务和成本失控。

应当为每次任务设置：

• CPU 和内存上限。
• GPU 配额（如适用）。
• 磁盘和输出大小上限。
• 运行时长和空闲超时。
• 子进程和并发数限制。
• API 调用次数和费用上限。
• 创建、暂停、恢复和删除权限。

生命周期必须可追踪：创建时记录发起身份和策略版本，运行时记录状态变化，结束时确认资源释放，异常终止时执行兜底清理。不要只观察“页面上已经删除”，还要核对底层卷、快照、临时凭证和网络资源是否一并处理。

9. 建立平台审计和 Agent 遥测

审计日志的目标是重建一次运行“为什么被允许、做了什么、影响了什么、如何结束”，而不是收集模型的私密思维过程。

建议分成两层：

两层日志需要使用共同的会话 ID 或运行 ID 关联。Northflank 的审计日志文档说明，其平台事件包含事件类型、触发用户、事件来源、时间戳、父事件、子事件和受影响资源；应用仍需要自行记录 Agent 的模型、工具和业务数据活动。

日志系统本身也要防止被 Agent 修改或删除，并限制敏感数据落盘。应优先记录可审计的操作事实，而不是把完整提示词、客户数据和模型内部推理过程无差别写入日志。

10. 用对抗测试证明隔离有效

安全审批应建立在失败行为已经被测试的基础上，而不是建立在供应商的“安全”标签上。

建议至少覆盖以下测试：

测试时要验证控制是否独立于 Agent 和 Agent 能够修改的系统。否则，攻击者一旦控制了应用层，就可能同时修改安全策略、日志或审批状态。

哪些回答应当阻止上线

以下问题如果无法回答，至少应阻止生产授权，直到有补偿控制和明确负责人：

• 沙箱是否与宿主机、其他租户或控制平面共享关键安全边界？
• Agent 能否访问未列入任务范围的文件、网络和 API？
• 凭证是否长期存在、权限过大或无法撤销？
• 网络是否默认允许出站？
• 任务结束后是否能证明数据、凭证和运行资源已经清理？
• 是否可以把平台审计和应用 Agent 行为关联起来？
• 是否做过提示注入、跨租户、外传、权限升级和逃逸测试？
• 发生失败时，是否有独立于 Agent 的停止、隔离和回滚机制？

“文档没有写清楚”本身未必等于漏洞，但“不承认边界、不提供证据、无法复现控制”应当被视为上线风险。补偿措施必须写明负责人、有效期、验证方式和退出条件。

对企业落地的建议顺序

不要一开始就追求最高规格的沙箱平台，建议按以下顺序建立最小可用控制面：

1. 先分类任务：区分可信代码、生成代码、用户代码、多租户代码和生产操作。
2. 先收窄权限：为人、Agent、任务和工作负载分别建身份，不共享管理员 Token。
3. 先隔离运行时：对不可信代码采用独立内核或更强隔离边界。
4. 先关闭默认网络：只放行任务需要的入口、出口和内部服务。
5. 先使用临时存储：持久化必须有明确业务理由和独立生命周期策略。
6. 再接入 AI 模型：先让确定性授权和网络策略生效，再启用更高自治能力。
7. 最后扩大生产权限：以对抗测试、审计证据和故障演练结果作为放权条件。

结语

AI Agent 沙箱的核心价值不是让 Agent“可以运行代码”，而是让企业能够在可控范围内允许它运行不可信代码。判断一个方案是否适合生产，不能只比较容器、微虚拟机或 gVisor 的名词，而要检查完整的执行边界：谁发起、拿到什么凭证、能访问什么网络和数据、消耗多少资源、结束后是否清理、操作能否追溯，以及在被提示注入和恶意依赖操纵后是否仍然成立。

对于安全团队来说，最有价值的交付物不是一句“已隔离”，而是一份可复核的边界说明、授权矩阵、网络策略、数据保留方案、审计证据和对抗测试报告。

参考资料

• Northflank：AI-agent sandbox security checklist: What enterprises should evaluate（2026-09-03）
• Northflank Sandboxes 文档
• Northflank API Token 与 RBAC 文档
• Northflank Audit Logs 文档
• OWASP GenAI：LLM06:2025 Excessive Agency

来源字段：2026-09-03｜Northflank，Deborah Emeni｜https://northflank.com/blog/ai-agent-sandbox-security-checklist｜企业 AI Agent 沙箱安全检查清单，覆盖隔离、身份、凭证、网络、数据、供应链、资源、审计和对抗测试｜适合作为 Agent 代码执行、云端沙箱和多租户平台上线前的安全评估框架。

本文根据微信公众号文章《33500行代码，47个情报源，这个AI威胁情报平台开源了》整理，并以 ArgusWatch AI 官方仓库文档为准。官方仓库 README 当前标注版本为 v16.4.7。本文中的命令和配置来自项目官方文件；由于本次写作环境未安装 Docker，未将部署命令描述为本地实测结果。

一句话介绍

ArgusWatch AI 是一个面向 MSSP 和安全运营团队的自托管威胁情报平台：它通过 Docker Compose 启动一组服务，汇聚公开和商业威胁情报源，将 IOC 与客户资产关联，再在 Dashboard 中展示发现、威胁演员、攻击活动、暴露面和修复动作。

如果你的需求是“把多个情报源集中起来，并按客户或资产查看关联结果”，它值得试用；如果只是偶尔查询一个 IP、域名或文件哈希，直接使用专门的 IOC 查询服务会更轻量。

它能做什么

根据官方 README，ArgusWatch AI 主要提供以下能力：

• 威胁情报采集：内置多个 Collector，对接 NVD、CISA KEV、MITRE ATT&CK、ThreatFox、Feodo、OpenPhish、URLhaus、MalwareBazaar、crt.sh 等来源；部分高级来源需要 API Key。
• IOC 识别与匹配：从原始情报中识别多种 IOC 类型，并通过域名、子域名、IP、CIDR、关键词、技术栈、相似域名和云资产等策略关联客户。
• 客户与资产管理：为客户登记域名、IP、邮箱域、技术栈等资产，随后将新采集的情报与这些资产关联。
• 发现与证据链：在 Findings 页面查看关联发现、严重性、客户、原始证据和来源链接。
• 威胁演员与 Campaign：查看威胁组织、攻击活动以及多个发现之间的关联。
• 暴露面评分：在 Exposure 页面查看客户维度的暴露面评分和组成项。
• 修复动作：根据 IOC 类型生成修复步骤、SLA、所需证据和责任角色。
• 本地或云端 AI：默认可以使用 Ollama；也可以在 Dashboard 中切换到 Claude、GPT 或 Gemini，前提是配置对应 API Key。
• 多租户部署：项目定位包含 MSSP 场景，数据库配置中使用 PostgreSQL 的 Row Level Security 进行租户隔离。

这些能力中，Collector、正则识别、匹配策略和评分属于确定性工程；AI 主要用于 IOC 调查路径、自然语言查询和分析文字生成。项目仓库提供了 AGENTIC-AI-HONEST-ASSESSMENT.md，可以用来了解哪些功能确实需要 LLM，哪些功能使用规则就足够。

部署前准备

官方 README 给出的基本前提是：

Windows 安装 Docker Desktop

项目 README 建议 Windows 使用 Docker Desktop，并启用 WSL 2 后端。Docker Desktop 的官方下载地址是：

https://www.docker.com/products/docker-desktop/

安装 Ollama

项目推荐在宿主机原生安装 Ollama，这样更容易使用 GPU。Windows 官方 README 给出的安装命令是：

winget install Ollama.Ollama

安装后拉取项目默认模型：

ollama pull qwen3:8b

检查模型是否能够正常运行：

ollama run qwen3:8b "say hello" --verbose

项目 README 将 eval rate 大于 40 tokens/s 作为 GPU 工作的参考，将低于 10 tokens/s 视为 CPU 推理参考。这个数值会受到硬件、模型版本和运行环境影响，适合用来做粗略判断，不应当当作固定性能承诺。

如果显存有限，可以在 .env 中改用项目列出的轻量模型，例如：

OLLAMA_MODEL=qwen3:4b

四步启动 ArgusWatch

以下步骤来自仓库根目录的 README.md、.env.example 和 docker-compose.yml。

1. 克隆仓库

git clone https://github.com/3sk1nt4n/arguswatch-ai.git
cd arguswatch-ai

2. 创建环境配置

cp .env.example .env

Windows 用户也可以直接复制文件：

Copy-Item .env.example .env

至少要修改以下配置。不要把真实密码和 API Key 提交到 Git 仓库：

OLLAMA_URL=http://host.docker.internal:11434
OLLAMA_MODEL=qwen3:8b

POSTGRES_USER=arguswatch
POSTGRES_PASSWORD=请替换为强密码
POSTGRES_DB=arguswatch

AUTH_DISABLED=true
JWT_SECRET_KEY=请替换为随机字符串
ADMIN_USER=admin
ADMIN_PASSWORD=请替换为强密码

AUTH_DISABLED=true 适合本地试用，但不建议直接用于暴露在公网的生产环境。正式部署前应重新检查认证配置、反向代理、TLS 和访问控制。

3. 按需填写情报源 API Key

ArgusWatch 可以在没有任何高级 API Key 的情况下先使用部分公开来源。需要更广覆盖时，在 .env 中填写对应 Key，例如：

GITHUB_TOKEN=
OTX_API_KEY=
URLSCAN_API_KEY=
CENSYS_API_ID=
CENSYS_API_SECRET=
ABUSEIPDB_API_KEY=
VIRUSTOTAL_API_KEY=
SHODAN_API_KEY=
HIBP_API_KEY=

不要为了“启用更多 Collector”一次性收集所有 Key。建议先启用公开来源和自己已有账号的来源，确认数据质量、请求配额和合规范围后再增加配置。

4. 启动服务

docker compose up -d --build

首次启动会构建服务、初始化数据库并启动后台任务。根据官方 Compose 文件，核心服务包括：

• Backend：FastAPI API 和业务处理，容器端口 8000。
• Intel Proxy：情报源采集和 IOC 处理，容器端口 9000。
• PostgreSQL：数据存储，宿主机映射端口 5433。
• Redis：Celery 消息队列和缓存，宿主机映射端口 6380。
• Ollama：本地模型服务，宿主机映射端口 11435。
• Recon Engine：子域名、DNS 和证书相关发现。
• Celery Worker：后台处理任务。
• Celery Beat：定时任务。
• Nginx：边缘入口。
• Prometheus：指标和健康监控。

项目当前 Compose 文件将 Backend 映射到 localhost:7777：

Dashboard: http://localhost:7777
API Docs:  http://localhost:7777/docs

项目还定义了 Nginx 入口：

HTTP:       http://localhost:8080
HTTPS:      https://localhost:9443
Prometheus: http://localhost:9091

以实际 docker compose ps 输出为准。如果端口被占用，应修改 Compose 文件的宿主机映射端口，而不是修改容器内部端口。

启动后怎么用

1. 先检查服务状态

docker compose ps

查看 Backend 日志：

docker logs arguswatch-backend --tail 50

查看情报采集服务日志：

docker logs arguswatch-intel-proxy --tail 50

查看 Ollama 日志：

docker logs arguswatch-ollama --tail 20

确认服务通过健康检查后，再打开：

http://localhost:7777

2. 在 Customers 中登记客户

ArgusWatch 的主要使用顺序不是先搜索 IOC，而是先建立客户和资产范围：

1. 打开 Customers 页面。
2. 创建客户并填写行业等基本信息。
3. 添加客户域名、IP、邮箱域或其他资产。
4. 运行客户 Onboarding。
5. 等待资产发现、情报匹配和暴露面计算完成。
6. 返回 Overview、Findings 和 Exposure 页面查看结果。

项目提供了 POST /api/customers/onboard 作为一站式客户接入接口。如果使用 API 而不是 Dashboard，可以先打开 /docs 查看当前版本的 OpenAPI 参数定义，不建议凭旧文章或二手教程猜测请求体。

3. 查看 Overview

Overview 适合快速判断当前环境的总体情况，官方 Dashboard 页面包括：

• Threat Pressure Index。
• 严重性分布。
• Detection 时间线。
• IOC 类型分布。
• 客户和发现数量。

这里适合做每日巡检，但不应把总量直接当作风险结论。继续下钻到 Findings 查看具体客户、证据和来源。

4. 查看 Findings 和证据

Findings 页面是日常使用的核心页面。建议按以下顺序查看每条发现：

1. 确认关联客户和资产是否正确。
2. 查看 IOC 类型和原始情报。
3. 打开证据来源，例如 NVD、VirusTotal 或其他 Collector 提供的链接。
4. 查看匹配策略和匹配依据。
5. 判断是否是真实暴露、误报或需要人工复核。
6. 进入 Remediations 查看后续处理步骤。

项目强调每条发现都要能够回到来源和匹配依据。实际运营时，仍应由分析师确认资产归属和业务影响，不能只依据 AI 生成的文字自动关闭或升级告警。

5. 使用 AI Bar 和 Chat

AI Bar 用于从一个 IOC 出发进行调查。根据项目的官方说明，它会先识别 IOC，再检查相关情报源，随后由模型决定是否继续查询客户发现、暴露面、关联邮箱、威胁演员、暗网或修复记录，最后生成分析摘要。

Chat Agent 用于用自然语言查询实时数据库，例如查询某个客户的高危发现、某类 IOC 的数量或近期相关威胁。使用本地 Ollama 时，第一次 AI 请求可能需要等待模型加载；如果模型没有 GPU 加速，响应时间会明显增加。

在 Dashboard 顶部切换模型前，先确认对应配置已经写入 .env：

ANTHROPIC_API_KEY=
OPENAI_API_KEY=
GOOGLE_AI_API_KEY=

本地模型适合处理对隐私敏感、调用量较大的分析；云端模型适合临时提升响应速度或推理能力。无论使用哪种模型，都要检查其输入是否包含不应外发的客户数据、凭证或内部资产信息。

6. 查看 Exposure、Actors 和 Campaigns

• Exposure：查看客户暴露面评分及各维度组成，用来确定优先处理对象。
• Actors：查看威胁演员、所属国家、TTP 等信息。
• Campaigns：查看多个发现是否被归为同一个攻击活动。
• Dark Web：查看勒索软件、Paste 和其他暗网相关结果。
• Remediations：查看技术处置步骤、SLA、状态和责任角色。

这些页面适合做调查上下文补充，最终处置仍应结合资产负责人、漏洞验证、日志和业务影响进行判断。

常用运维命令

# 启动
docker compose up -d

# 代码或镜像变化后重新构建
docker compose up -d --build

# 查看服务状态
docker compose ps

# 停止服务，但保留数据
docker compose down

# 查看日志
docker logs arguswatch-backend -f --tail=50
docker logs arguswatch-intel-proxy -f --tail=50
docker logs arguswatch-ollama -f --tail=20

# 重新构建 Backend
docker compose build --no-cache backend && docker compose up -d

# 清空数据并重新部署，谨慎使用
docker compose down -v && docker compose up -d --build

最后一条命令会删除 Compose 数据卷，适合实验环境重置，不适合生产环境日常维护。

API 快速入口

官方 README 列出了部分常用接口：

不同版本的请求字段可能变化。使用前请访问 http://localhost:7777/docs，以当前运行版本的 OpenAPI 文档为准。

适合谁，不适合谁

适合

• 需要自建威胁情报工作台的 MSSP。
• 希望将多个公开情报源和已有商业情报源统一管理的安全团队。
• 需要按客户、资产和租户隔离查看发现的服务商。
• 想让 AI 辅助 IOC 调查和报告撰写，但仍保留人工判断环节的 SOC 团队。
• 希望研究一个完整 Docker Compose 安全平台的人。

不太适合

• 只需要临时查询 IOC 的个人用户。
• 没有 Docker、数据库和基础运维能力的团队。
• 需要厂商正式 SLA、商业支持和成熟合规交付的生产环境。
• 希望开箱即用获得全部高级情报源的人：不少 Collector 需要单独申请 API Key，且受供应商配额约束。
• 不能接受初始数据采集、模型下载和多服务维护成本的环境。

使用前的三个检查

1. 先确认数据合规：公开情报源、暗网采集、客户资产扫描和第三方 API 的使用范围需要符合组织政策与当地法律。
2. 先用测试客户验证误报：项目预置或示例中的客户资产不等于你的授权范围，接入真实客户前应使用自有、明确授权的资产进行验证。
3. 先锁定版本和备份策略：项目 README、Compose 文件和模型配置会变化；升级前保存 .env、数据库卷和自定义配置，避免直接使用 down -v。

项目状态与许可证

截至本文核验时：

• 官方仓库：https://github.com/3sk1nt4n/arguswatch-ai
• README 标注版本：v16.4.7
• 主要语言：Python
• 默认分支：main
• GitHub API 返回许可证：MIT License
• GitHub API 返回仓库 Star 数：68（动态数据，核验时间为 2026-09-08）
• GitHub API 返回 Fork 数：17（动态数据，核验时间为 2026-09-08）
• 仓库创建时间：2026-03-05

Star、Fork、版本和 Collector 数量都可能随仓库更新变化，使用时应以官方仓库当前内容为准。

结语

ArgusWatch AI 的价值不只是把若干情报源放在一个页面中，而是把“采集—匹配—发现—调查—评分—修复”的工作流串起来，并为 MSSP 场景提供客户和租户维度的组织方式。

实际落地时，建议先从最小配置开始：原生 Ollama、公开情报源、一个明确授权的测试客户，先验证 Dashboard、匹配结果和误报处理流程，再逐步接入 VirusTotal、Shodan、Censys 等需要 Key 的服务。这样比一开始启用全部 Collector，更容易判断项目是否真正适合你的运营流程。

参考资料

• 微信公众号原文：33500行代码，47个情报源，这个AI威胁情报平台开源了
• ArgusWatch AI 官方 GitHub 仓库
• 官方 README
• 官方环境变量示例
• 官方 Docker Compose 配置
• AI 能力诚实评估
• MIT License

来源字段：2026-09-08｜微信公众号文章、ArgusWatch AI 官方 GitHub｜https://mp.weixin.qq.com/s/7JJV4fdCG2mH55xm3YPceQ｜介绍 ArgusWatch AI 的定位、部署和使用流程｜适合需要自建威胁情报工作台的 MSSP 与 SOC 团队，但应先验证数据合规、误报率和运维成本。

相关系统：BAIZE SEC（白泽）网络攻击行为综合智能分析研判系统

一、演讲主题与总体判断

本次演讲围绕“AI 原生的网络攻击行为综合研判分析”展开，核心观点是：传统网络安全分析高度依赖规则、人工专家和大量分散工具，难以应对多阶段、复杂化、持续变化的网络攻击；应当以大模型、多智能体、知识库和攻击链推理为基础，重构网络安全分析流程。

演讲展示了华安云科的 BAIZE SEC 系统：通过 AI 智能体对流量、终端日志、代码/木马、威胁情报等多源数据进行分析，完成攻击行为识别、关联研判、攻击链推理、威胁溯源和取证报告生成。

二、现有安全分析的主要痛点

1. 传统检测依赖规则

• 流量、终端和恶意代码分析往往依赖固定规则与人工经验。
• 规则难以覆盖未知威胁、变种攻击和复杂攻击链。
• 容易出现误报、漏报，且攻击技术变化后需要持续维护规则。

2. 分析工具和流程碎片化

恶意代码分析通常需要反编译、调试、资源分析、IAT 重建、网络封包分析、行为监控等多类第三方工具，整个过程复杂，人工成本和时间成本高，也很难把不同工具的结果进行深度关联。

3. 多源数据难以统一关联

安全分析涉及流量、终端文件、进程、注册表、网络连接、日志、IOC、攻击组织画像等多种数据。数据维度多、格式不一，跨数据源关联困难，难以还原完整攻击链。

4. 通用大模型直接用于安全分析存在局限

演讲归纳了通用大模型的几个痛点：

• 回答可能产生幻觉；
• 内容难以证伪、难以追溯依据；
• 难以回答安全分析中的特殊细节；
• 缺少网络安全行业知识、攻击事件和 IOC 的专业背景。

三、BAIZE SEC 的总体架构

1. 多智能体分工

系统将复杂的安全研判任务拆分给不同专业智能体，主要包括：

• 流量数据分析智能体：解析网络流量与数据包，识别协议、通信行为和异常流量。
• 终端日志数据分析智能体：分析 Windows 等终端取证日志、进程、注册表、文件和网络服务信息。
• 代码静态分析智能体：分析恶意代码、文件结构、字符串、导入导出表等静态特征。
• 木马动态分析智能体：动态执行样本，捕获运行行为、文件操作、进程活动和网络活动。
• 情报深度关联分析智能体：关联 IOC、攻击事件、攻击技战术、APT 组织画像和知识库。
• 逆向/恶意代码分析助手、APT 知识问答助手、IOC 关联拓线助手：以对话方式辅助分析师进一步探索。

2. LangChain + Agent Blackboard

技术框架采用 LangChain 与 Blackboard（黑板）机制实现多 Agent 协作：

• LangChain 为大模型应用提供模型、Prompt、工具调用、记忆和外部数据接入等通用能力。
• Blackboard 提供中央共享状态存储，多个领域专家智能体围绕黑板读写信息。
• 控制器根据黑板的当前状态，动态决定下一步调用哪个智能体，而不是执行固定流程。
• 支持条件分支、并行执行、异步协作和长时间运行的复杂工作流。
• 分析过程可回溯、系统高度可观测，领域专家模块能够解耦。

这一架构的关键价值在于：把复杂安全分析从“单一模型的一次性回答”转变为“多个专业智能体基于共享状态的协同研判”。

四、人机交互与分析模式

系统提供智能体中心和技能中心，分析人员可以选择专业智能体或直接创建分析任务。主要交互方式包括：

1. 对话聊天模式

白泽智能体可以回答安全问题、解释攻击活动、介绍恶意样本或攻击组织，并支持围绕上下文连续追问。

2. AI Agent 智能体模式

面向复杂、具体的分析研判任务。系统可以自主选择工具和智能体，多轮执行分析，并实时回显思考过程与工具调用过程。

3. 数据分析模式

分析人员选择数据、任务名称和分析模式后启动任务，系统展示任务进度、分析状态和历史任务，最终生成结构化的综合分析报告。

五、典型能力一：网络流量与数据包分析

1. 目标与痛点

系统面向“AI 原生的流量数据包深度分析”，重点解决：

• 规则检测覆盖不足；
• 误报与漏报率高；
• 加密流量导致异常检测困难；
• 数据包分析流程和方法论需要重构；
• 需要定制化工具进行预处理；
• 分析结果与威胁情报、攻击溯源经验关联困难。

2. 分析方式

系统可对 PCAP 等数据进行综合分析，结合预处理工具、流量分析引擎和安全知识库，识别 C2 通信、DNS 隧道、异常网络活动及可能的横向移动、数据窃取行为，并输出综合分析摘要和威胁情报报告。

演示案例中，系统对一组网络样本进行分析，识别出包含 C2 通信、DNS 隧道、远程控制木马、挖矿程序和蠕虫活动的多阶段复合攻击迹象，并给出攻击组织/家族线索和处置建议。该部分属于演示样本的分析结论，不应直接视为本论坛现场真实事件的确认。

六、典型能力二：终端日志与取证分析

终端数据分析的难点包括数据维度和种类多、数据量大、依赖规则、误报漏报以及系统化分析困难。

系统支持上传 Windows 取证日志 JSON，自动解析进程、注册表、网络、服务、文件、计划任务等多个安全数据块，再由多个分析智能体逐类研判，最终生成综合取证报告。

七、典型能力三：恶意代码反编译与行为分析

1. 从人工工具链转向 AI 辅助

传统恶意代码分析需要使用 EXE 信息分析、PE 结构分析、反编译、调试、资源和导入表处理、行为监控等工具；流程非常复杂，依赖人工专家，且难以进行深度关联分析。

BAIZE SEC 尝试把静态分析、动态分析、反汇编结果、样本数据和攻击溯源经验统一起来，辅助分析师理解恶意代码行为。

2. 演示样本：键盘记录木马

演示页面将样本识别为能源行业相关高级持续性威胁组织 ENERGETIC BEAR（IRON LIBERTY） 使用的 Karagany（XFrost） 恶意软件，属于高危键盘记录木马（Trojan:Win32/Keylogger）。页面展示的行为包括：

• 伪装为合法系统组件或文件名以逃避检测；
• 通过互斥体实现单实例运行；
• 设置全局键盘钩子窃取键盘输入；
• 获取窗口标题和剪贴板内容；
• 执行文件清理以消除痕迹；
• 可能通过注册表或其他机制实现持久化。

系统可以从反编译代码中提取函数关系和行为链，例如初始化路径、伪装与持久化、安装键盘钩子、捕获键盘数据、窃取剪贴板以及数据写入与清理。

八、典型能力四：专业安全知识库与情报关联

1. 网络安全专业 RAG

系统建设面向网络攻击事件和 IOC 情报数据的专业知识库，用于弥补通用大模型在安全领域知识、可验证性和细节回答方面的不足。

知识库内容包括：

• 网络攻击事件；
• IOC 与关联拓展数据；
• 攻击组织及组织画像；
• 攻击技战术（TTP）；
• 恶意软件与样本分析结果；
• 攻击链、溯源经验和安全报告。

2. APT 情报知识体系

情报关联分析能力的目标是建立 APT 全息情报知识体系，形成可研判、可追溯、基于因果关系的精准情报体系。系统通过自研的攻击线索关联分析及溯源模型，将 IOC、攻击事件、TTP、组织画像和关联拓展数据连接起来，生成关联关系图和可追溯的研判依据。

九、案例分析中体现的研判方法

演示页面展示了从 IOC、样本、流量、终端证据到攻击组织画像的逐层分析方法，强调：

1. 先采集和规范化样本、流量、日志及情报数据；
2. 再调用不同专业智能体进行静态、动态、日志和关联分析；
3. 把各智能体结果写入共享黑板，形成统一分析上下文；
4. 通过知识库匹配已知攻击组织、家族、TTP 和事件；
5. 对未知或复杂样本开展多轮工具调用与深度推理；
6. 生成综合分析、取证和威胁情报报告，并保留依据和过程。

十、未来展望与业务规划

1. AI 重构网络安全防御体系

演讲提出，AI 技术将深度重构网络安全防御体系。未来防御体系不应只依靠单点产品，而应把已知威胁情报、沙箱、杀毒/EDR、蜜罐或欺骗、流量、终端和情报分析等能力连接起来，覆盖攻击生命周期的多个阶段，例如初始接入、执行、权限提升、防御规避、凭据访问、发现、横向移动、命令与控制和信息渗漏等。

2. 系统优化方向

• 持续扩大 AI 智能体系统分析数据的覆盖面；
• 提升攻击检测效率与研判质量；
• 进一步完善现有分析流程与效果；
• 建立 AI 智能体的长期记忆机制，让系统具备“越用越聪明”的持续学习能力；
• 继续强化情报知识库、攻击链推理和多智能体协同。

十一、核心结论

1. 网络攻击正在变得多阶段、复合化、隐蔽化，单一规则或单一工具难以完成高质量研判。
2. 安全智能化的关键不是简单接入一个通用大模型，而是构建专业知识库、工具链、多智能体和可回溯的工作流。
3. LangChain 负责模型应用编排与工具接入，Blackboard 负责多智能体之间的共享状态和动态协作。
4. BAIZE SEC 的产品思路是把流量、终端、代码、木马和情报分析统一到一个 AI 原生研判体系中。
5. 对安全领域而言，可验证、可追溯、可观测和能关联攻击链，比单次回答的语言流畅度更重要。
6. 长期方向是让 AI 智能体覆盖更多数据类型和防御环节，并通过长期记忆不断积累分析经验。

一、核心结论

AI 的快速演进正在将网络安全风险从“工具辅助型”推向更强的自动化、隐蔽化与自适应攻击。大模型与智能体可明显压缩攻击开发和漏洞利用周期，使攻击链的构建、执行与迭代能力增强；与此同时，超算系统既是 AI 创新的关键算力底座，也是高价值、复杂异构的安全运维对象。

演讲提出的应对路径可概括为三层：

1. 以智能化安全运维守护超算底座：将异构多源数据、异常检测、根因分析、知识库与多智能体协作结合，形成“感知—研判—执行—验证—复盘”的安全自治闭环。
2. 建设 AI 安全攻防训练基地：汇聚算力、模型、数据、算法、靶场、平台与人才，开展安全大模型、安全智能体、红蓝对抗与实战化测评训练。
3. 形成全栈 AI+安全体系：安全不应只盯住基础设施或模型，而应覆盖硬件/算力、模型基座、数据与 API 链路，以及上层 Agent 应用，构建纵深防御闭环。

二、演讲内容梳理

1. AI 变革及其安全影响

• 演讲先回顾人工智能从早期 AI、机器学习、深度学习到生成式 AI / 大模型阶段的发展脉络。
• 页面以全球标志性模型数量等图表说明 AI 模型能力和产业竞争的快速发展；页面文字引用的图表信息显示，美国与中国均在前沿模型发布中占据重要位置。
• AI 已不再只是效率工具，而正在成为可影响安全攻防节奏的“破坏性创新”变量。

2. AI 带来的网络安全破坏性挑战

页面强调：AI 已能够辅助、甚至在一定范围内独立完成复杂攻击链中的漏洞利用开发等环节，从而大幅压缩攻击开发周期。

主要风险特征包括：

• 攻击自动化：攻击者可借助 AI 提升漏洞挖掘、攻击代码生成、攻击链编排等工作的效率。
• 攻击隐蔽化与自适应：AI 驱动的攻击可以更快调整策略，增加检测与响应难度。
• 攻防博弈升级：传统以规则、人工分析和静态边界为主的防护方式面临更强压力。
• AI 自身安全风险：页面列举了漏洞挖掘、数据投毒、深度伪造、反向诱导、供应链攻击、提示词注入、思维链劫持、越狱攻击等方向。
• 开发工具与供应链风险：页面援引“工信部 NVDB 平台提示 Claude Code 安全后门隐患”的案例性文字，意在提示 AI 编程工具、模型/插件与软件供应链需纳入安全治理。

3. 超级计算：驱动 AI 创新的算力引擎

• 超级计算机被定位为电子信息技术发展的基础驱动，是全球科技竞争的重要制高点之一。
• 超算系统需要同时突破性能、访存、通信、能耗与可靠性等“墙”，并兼顾实用性能、可编程性、可移植性、系统鲁棒性和经济可行性。
• 从传统 CPU 计算到 CPU+GPU 等异构架构，超级计算为高性能计算、深度学习与大模型创新提供了关键基础。
• 因超算集群规模大、异构性强、资源价值高，安全运营不仅是外围防护问题，更关系到算力系统的持续、可靠和可信运行。

4. 超算传统网络安全基础设施

演讲展示了超算安全运营的既有基础能力：

• 一体化全机监控：实时监测运行时指标和安全事件日志，支持秒级根因分析。
• 资产与配置统一纳管：通过配置管理数据库等方式，关联变更、故障、工单与 IT 资产，构建业务关联知识图谱。
• 可视化与告警治理：统一告警、可靠性与安全监控、海量数据可视化、变更审计，以及万级设备纳管。
• 纵深防御与分区隔离：涉及租户/业务分区隔离、主机安全、高速网络、用户行为分析、流量监控、蜜罐、漏洞扫描、态势感知、WAF、堡垒机、日志审计、数据库审计、防火墙、抗 DDoS 与零信任等控制措施。

5. 面向超算系统的智能安全运维

目标是实现面向 E 级超算算力系统的智能化、安全自治与可靠运行。其关键技术路线包括：

• 异构多源、跨维数据联动整合：整合日志、指标、配置、告警、命令/API/Web 等多类数据和操作接口。
• 异常检测与根因分析：从多类异常中识别问题，定位故障和安全事件根因，并支撑运维诊断。
• 系统状态驱动的多智能体协作：以多个专业 Agent 分工协作，连接工具、知识库和执行接口。
• 全链路自治闭环：实现高精度决策、任务执行、结果验证及持续改进；同时保持工具生态和场景扩展能力。

多源数据异常检测与故障注入

• 支持灵活、可控、脚本化的故障注入，以持续迭代异常检测、根因定位和运维诊断能力。
• 通过多集群/多节点日志与指标自动采集，结合知识库、因果分析、异常检测模型与根因排序，完成诊断和验证。
• 在处置后自动恢复环境，沉淀数据样本，形成可训练、可验证、可回归的闭环。

多智能体安全事件自动处理

页面给出的典型流程可概括为：

1. 任务拆解 / 意图识别：接收用户请求、监控告警等输入，识别事件及处置目标。
2. 安全事件自动处理：生成结构化响应方案和任务计划，调用脚本、API、Shell 等工具执行处置，例如恶意 IP 封禁。
3. 结果检查 / 回环验证：结合规则、白名单/黑名单等机制复核结果，避免误报或越权处置。
4. 记录 / 复盘：保留日志和处置结果，写入知识库或经验库，生成报告并持续优化。

页面主张该模式可显著缩短相对传统人工运维的响应时间，但照片中用于支撑具体性能对比的小字指标无法可靠识别，因此未转述具体数值。

多智能体运维自身的安全保障

演讲特别指出：赋予 Agent 感知、规划和执行能力后，Agent 本身必须受控。页面以 Harness Engineering 为关键词，强调通过约束、观测、审计与人工参与保障自治运维安全。

可辨认的安全控制包括：

• 在超算集群多节点上搭建 沙箱，作为 Agent 的“安全试验场”；
• 对资源和网络进行双重隔离，将故障影响限定在最小范围；
• 对未授权操作进行拦截，对越权访问直接阻断；
• 保持全程可审计、可回滚；
• 引入 Human-in-the-Loop（人工在环），在关键操作中保留人工确认与干预能力。

6. 构建一体化 AI 安全攻防训练基地

演讲提出建设“算力—模型—数据—算法—靶场—平台—人才”一体化 AI 安全攻防训练基地。

建设目标

• 打造训练与推演平台，筑牢信创攻防基础设施；
• 强化安全基座大模型能力，构建多模态安全知识库；
• 突破协同对抗的多智能体安全技术；
• 建设对抗性安全专项测评靶场；
• 建设人才培养和标准管控体系；
• 依托国家科技力量与京津冀产业优势开展协同建设。

实施基础

页面展示了基地应具备的资源基础，主要包括：

• 算力与存储：国产超算与智算基础设施、云计算和大数据环境；
• 安全数据集：安全日志、公开数据集、网络流量、威胁情报、漏洞、恶意样本、产品/测试数据与报告等；
• 智能运维与合规能力：支持数据治理、跨域数据访问及安全合规运维；
• 合作资源：与科研机构、高校、企业等合作单位形成攻防场景、数据和评测支撑。

照片中部分数据集规模和设备参数模糊，未在本整理中引用具体数值。

研究内容与技术体系

基地拟输出安全大模型、安全智能体、AI 攻防靶场等系列安全服务与基础设施，面向高性能计算、工业仿真、电力网络、金融服务、物联网、生物医药、农业生产等场景提供支撑。

主要研究方向包括：

• 安全数据治理、多智能体知识库与日志关联分析；
• 集群运维监控与安全模型敏捷开发；
• 系统实战化安全测评训练平台；
• 智能体攻防推演、智能渗透测试、文件篡改攻击判定、调度与多模型裁决等技术；
• 大规模 AI 对抗样本生成、对抗样本库与持续靶场资源池；
• 威胁情报/舆情监测、文件异动监测、流量检测与攻击路径预测、攻击链溯源；
• 大语言模型、漏洞代码识别模型、攻击意图研判模型、安全事件摘要模型、恶意流量分类模型等安全模型能力。

红蓝多智能体攻防模拟

• 页面展示了基于 DefenderBench 的红蓝多智能体攻防系统架构，并提及 CyberBattleSim 环境。
• 设计核心是将“策略推理”与“具体动作执行”解耦：红方规划/执行、蓝方分析/执行分别协同；动作受到约束和验证，并通过失败记忆机制提高过程可控性。
• 示例描述红方通过 RDP 连接并控制 Windows 节点，蓝方在同轮扫描检测该节点并执行 reimage（重置/重建）处置，呈现持续红蓝交互与状态演化。
• 实验关注“成功到达目标攻击”与“预算内未完成攻击”等长程现象，并强调完整过程记录和决策轨迹分析能力。

7. 超算 AI+安全方案展望

演讲最后提出全栈安全观：

• 基础设施可信化，为前端应用提供底层安全，并实现服务器与算力环境可信度量；
• 部署超算安全智能运维系统，守护基础设施与数据链路；
• 构建 AI 安全攻防训练基地，提升模型、系统和智能体的攻防与测评能力；
• 覆盖业务终端与前端应用、API 通信、智能体应用、模型基座、数据链路与基础设施等层次。

其核心表述是：安全不能只聚焦基础设施或大模型本身，必须建立全栈视角，覆盖从硬件基础设施到模型基座、数据接口，再到上层 Agent 智能体应用的完整链条，形成纵深防御闭环。

三、对安全治理的启示

1. 将 AI 视为攻防能力放大器：治理重点需从单点模型安全扩展到 AI 赋能攻击后的完整攻击链风险。
2. 以数据和可观测性支撑自治：没有统一资产、日志、指标、告警、变更和知识库，智能体很难安全可靠地执行运维任务。
3. 自治必须与约束并行：Agent 的权限最小化、沙箱隔离、工具调用控制、审计回滚与人工在环是安全自治的前提。
4. 从单系统防护走向攻防训练与验证：通过靶场、红蓝对抗、故障注入、仿真环境和失败记忆机制，把安全能力转化为持续可验证的工程能力。
5. 建设贯穿底座到应用的全栈体系：基础设施、模型、数据、API、工具和 Agent 应用必须纳入统一风险视角，避免治理断层。

一、核心观点

当AI智能体代表组织执行查询、调用工具、修改数据和触发业务动作时，安全治理要从“防攻击”扩展为“管行为”。智能体应被视为继人之后的第二类操作主体，必须配置身份、任务、边界、权限和责任，并对关键行为形成可审计、可追溯的记录。

信创环境下的AI安全应嵌入从基础设施到业务动作的全链路，实现从“系统可控”到“AI做出的每一次业务决策可控”，让信创从“可用”走向“可信”。

二、从防攻击到管行为

传统安全以人为主要操作主体，重点是守边界、防入侵；智能体参与业务后，治理必须回答：它是谁、谁派它来、谁委托谁审批谁负责、能调用哪些工具、访问哪些数据。安全能力应从底座内生，在身份、任务、执行和审计各层形成约束。

三、智能体信任体系的六个能力维度

1. 身份可信：识别用户、智能体、工具和服务，建立委托绑定。
2. 行为可控：依据任务上下文进行运行时策略判定和动作约束，可采用ABAC。
3. 责任可溯：记录委托、审批、调用和结果，支持追责与合规举证。
4. 委托可验证：将委托关系绑定到会话和具体任务，明确授权范围与结束条件。
5. 风险可分级：按风险等级差异化控制，避免一刀切。
6. 体系可演进：持续适配新模型、工具、协作方式和威胁。

四、智能体安全五步闭环

1. 身份验证；2. 上下文装配（任务、资源、环境、委托和会话范围）；3. 策略与风险判定；4. 执行决策：ALLOW允许、DENY拒绝或HITL转人工审批；5. 审计留痕：记录身份、策略命中、工具调用、审批和结果。

该闭环使智能体调用可解释、可复核、可追责。

五、组合风险与人机共治

“查工资+发外部邮件”说明单独合规的动作组合后可能变成高风险：查询工资和发送邮件各自在授权范围内，但组合执行会导致薪资数据出域。风险评估应考虑任务上下文、动作顺序、数据流向和组合结果。

中低风险可自动执行；高风险需通知负责人或事前审批、人工执行；极高风险必须人工审批并由人亲自操作。

六、AI安全走向工程与合规

智能体已从演示走向真实业务流程，安全要求应工程化，重点包括身份注册、可信标识、委托和权限管理、高风险动作阻断或人工审批、完整审计，以及智能体互联和工具调用治理。现场还展示了智能体安全基本要求、互联安全指引等标准建设动向；具体发布状态不作额外断言。

七、信创环境下的安全融合

把安全策略、SDK或网关能力融入OA及既有业务系统，覆盖业务动作本身，实际改造范围以客户架构和PoC为准。适配国产密码算法用于认证、签名和防篡改日志；适配国产CPU、服务器和操作系统；对接国产大模型与推理框架并纳入治理平面；对齐信创目录和安全可靠测评要求。

八、治理落地路线图

• 0—3个月：资产盘点（智能体、模型、工具、接口、数据和委托关系），选真实场景建立身份注册、策略、审计和高危介入最小闭环。
• 3—6个月：接入核心业务场景，持续运营策略和授权边界，完善审批、阻断、通知和异常处置。
• 6—18个月：开展跨部门、跨系统、跨智能体治理，对齐组织、流程、标准及信创验收，沉淀常态化体系。

九、总结

“当AI替我们做事，出了事谁负责？”是智能体治理的核心问题。可信智能体应当持证上岗、按责办事、全程可溯。建议从一个真实业务场景开始，共建治理最小闭环PoC，再扩展到跨域治理和体系化运营。

一、核心结论

大模型安全主要关注训练、输入输出和单轮回答是否无害、可靠；而智能体安全的对象已变为一个会读取外部信息、调用工具、改变环境状态并跨会话保留记忆的混合执行系统。当模型输出开始驱动真实动作时，风险便从内容风险升级为系统风险。

演讲提出“可信执行”的三个转向：

1. 保护对象：从大模型扩展到完整的智能体系统；
2. 控制边界：从输出审核扩展到对每一步行动的行为管控；
3. 优化轨迹：从结果监督扩展到过程级风险定位、纠偏与训练反馈。

其核心架构是：模型/规划器只提出动作，模型外的可信运行时（Trusted Runtime / TCB）逐步仲裁能否执行。 可信执行并非要求智能体永不出错，而是要求出现问题时可定位、动作发生前可拦截、后续优化中可纠正。

二、从大模型安全到智能体系统安全

1. 大模型安全的基本范式及局限

演讲回顾了大模型能力形成的三阶段训练流水线：

• 预训练：学习语言与世界知识，获得通用能力；
• 监督微调：学习任务格式和指令遵循；
• 偏好与安全对齐：学习人类偏好与安全边界。

传统大模型安全主要围绕“训练 + 输入输出护栏”，评价对象是最终 Response，目标是让回答有用、无害、可靠。这一范式是起点，但当系统从“会回答”变为“会执行”时，仅评估单轮文本输出已不足够。

2. 语义安全仍可能存在共同盲区

演讲以 VacuousAttack（页面标注 IJCAI 2025 Challenge、团队工作）说明，多重约束可能留下共同语义盲区。页面涉及商业护栏、长度限制、字符集限制（例如仅中文）等约束，以及通过中性填充、提示引导的意图恢复等方式绕过约束的思路。

页面展示的材料性结论是：在若干模型和较少攻击次数条件下，攻击成功率仍可能达到较高水平（页面可辨识范围为 66.4%—94.5%），并获得 IJCAI 2025 决赛榜第 2 的成绩。演讲借此强调：多层防护并不必然等于稳健的语义安全，不同机制可能具有共同盲区。

3. 将拒绝能力下沉到模型内部

演讲以 DeepRefusal（页面标注 EMNLP 2025、团队工作）介绍模型内生拒绝机制：

• 通过模拟不同深度的越狱状态，分析/消除拒绝方向；
• 重构拒绝损失，促使模型形成更深、更鲁棒的拒绝机制；
• 目标不是只学会拒绝，而是在拒绝方向受扰动时，仍能维持或恢复安全行为。

页面展示：在基本保持模型能力的情况下，针对四个模型、六类攻击的平均攻击成功率（ASR）降幅约 95%；示例中 CodeAttack 和 VacuousAttack 的攻击成功率显著降低。演讲同时强调：模型本身足够稳健仍不够，模型外的工具、权限、环境与状态仍可能发生安全问题。

三、智能体执行带来的系统性风险

1. 真实智能体已从“会回答”走向“会执行”

页面将典型智能体任务拆分为：

理解目标 → 任务规划 → 工具调用 → 环境执行 → 结果交付

智能体可处理自然语言需求，拆解步骤和依赖，调用搜索、代码、业务工具，读取/写入/修改系统状态，并交付报告、代码或任务结果。其应用场景包括企业业务、办公与研究、编程与桌面操作等。

安全含义在于：模型输出已进入工具、权限和环境，开始产生现实副作用。

2. 大模型安全与智能体安全的区别

关键变化不是风险类型简单增多，而是模型输出开始驱动真实动作、改变环境状态、影响后续会话。

3. 能力与后果同步放大

演讲将智能体能力演进概括为：

1. LLM：生成文本；
2. RAG：读取外部知识；
3. Tool LLM：调用外部工具；
4. Agent：规划并连续执行；
5. Persistent Agent：拥有记忆与后台运行能力。

相应后果从错误输出，演变为不可信上下文、错误动作、权限扩大和跨会话持久状态污染。多个局部输出连接后，可能形成持续改变系统状态的执行链。

4. 智能体是混合执行系统

演讲从系统视角提出，智能体一次错误能走多远，取决于四个核心变量：

• 读到什么 / 信任什么：上下文、网页、外部 RAG、记忆、其他 Agent 等信息来源；
• 能够调用哪些工具：工具能力、领域环境和工作流；
• 以谁的身份执行：权限、凭据和委托授权；
• 记住并改变什么：会话状态、长期存储、工作区或应用状态。

因此，智能体安全首先是系统安全问题，大模型安全只是其中一部分。

四、风险如何沿系统链传播

1. 用户任务与攻击目标可能同时实现

演讲展示了邮件摘要场景：用户希望智能体汇总会议邮件并发送给上级，而不可信邮件内包含提示注入，诱导智能体泄露受害者账户信息。此时，用户任务的完成度（Utility）与攻击目标是否得逞（Security）必须被同时评估。

结论是：智能体安全需要关注整个 Agent 系统，而非仅判断最终回答是否看起来正常。

2. 风险传播链

页面将风险传播概括为：

不可信上下文 → 模型规划 → 工具与状态 → 现实副作用 → 错误级联 / 现实伤害

典型不可信来源包括网页、邮件、RAG、工具输出、文件和其他 Agent；典型后果包括远程代码执行（RCE）、外泄、越权、读取/外发文件、写入记忆、持久污染等。

系统风险的三个关键属性是：

• 输入不可控：模型无法天然区分“可读信息”和“行动指令”；
• 执行有副作用：模型输出可触发工具、外发和文件修改，一次误判会造成真实后果；
• 状态可持续：恶意影响可能被写入并在后续会话重载，当前调用安全不代表长期状态安全。

3. 风险放大公式：行动影响力 × 状态寿命

演讲提出：

系统风险 / 风险放大 ≈ 行动影响力 × 状态寿命

• 行动影响力：一段信息能否改变下一步动作；
• 状态寿命：这种影响能否被保存并在后续重新加载。

四象限中，低行动影响力、短状态寿命的信息风险较低；而右上角“高行动影响力 + 长状态寿命”最危险：不可信信息既能驱动行动，又可跨会话持续存在，因而成为持续有效的控制信号。

4. 智能体安全建模

页面以对 247 篇论文的矩阵性综述说明，智能体风险应建模为 Agentic 环境中：

• 信息流（用户提示、网页内容、工具输出、检索内容、文件等）；
• 委托权限；
• 持久状态；
• 规划、决策、执行、监控与协调生命周期

之间的交互。单次模型判断能触发真实动作，错误影响也可以跨步骤、跨会话保留。

五、典型攻击案例：只读也可外泄，单次污染也可跨边界持久化

1. EchoLeak：只读检索也可形成高危外泄

演讲以公开披露的 EchoLeak / Copilot 场景说明，邮件进入检索上下文后，即使系统表面上是“只读”检索，仍可能形成数据外泄链：

1. 攻击者投递包含恶意指令的“特洛伊邮件”；
2. AI 在检索或处理时将该内容带入上下文；
3. 恶意指令劫持 AI，收集敏感信息；
4. 将数据通过链接查询参数等方式包装；
5. 浏览器加载或预览图片/链接，触发到攻击者 Webhook 的请求，形成渲染侧信道外泄。

演讲的关键判断是：权限是否危险不能只看当前动作，还要看读取的数据能够驱动哪些后续行为。

2. DuneSlide：工具参数污染可跨越多层系统边界

页面以 Cursor Desktop / MCP 工具调用界面相关案例说明：不可信内容进入上下文后，可能控制工作目录和符号链接，进而覆盖 sandbox 配置并逃逸到宿主机。演讲强调：提示过滤无法替代系统级隔离、授权和完整性保护。

3. XPSI：持久状态让攻击跨会话延续

页面以 XPSI（标注 arXiv 2026、团队工作）说明：网页、邮件、RAG 或工具返回等外部内容，一旦既能驱动动作又被写入 Memory、工作区文件或应用状态，便可能在下一步或下一会话自动重新加载，再次获得影响力。

页面展示端到端攻击成功率（E2E-ASR）为 41.9% 的材料性结果。其结论是：外部内容一旦兼具行动影响力和持久状态，就可能形成跨会话存储型提示注入。

六、可信执行：模型提议，可信运行时仲裁

1. 操作系统式的安全边界

演讲提出借鉴操作系统参考监控器（Reference Monitor）的设计：

可信运行时的关键组件包括：

• Action Gate：对工具、对象、参数以及外部发送等行动作出允许、拒绝或请求确认的决定；
• State Gate：对状态写入、重载和持久化内容进行检查；
• Sandbox：限制影响范围；
• Audit & Recover：记录、补偿和接管，实现可审计、可恢复。

核心原则是：模型负责提出动作，最终执行权必须由模型外的可信运行时掌握。

2. AgentSpec：逐步仲裁阻断危险动作

页面引用 AgentSpec（ICSE 2026）实验，展示模型外的逐步运行时仲裁可将多个危险指令类别（如跌落/破损、财产损坏、小物件损坏、电器误用、滑倒、中毒/误食、触电、液体泼洒）的危险执行比例降至 0。

页面同时显示，安全任务完成率相对无约束配置有小幅下降（约 4.36 个百分点）。演讲的解释是：固定规则擅长阻断已知危险动作；面对开放任务，还需要结合真实执行轨迹判断动态影响。

3. CanaryRAG：以模型外完整性证据抑制 RAG 窃取

演讲以 CanaryRAG（ACL 2026、团队工作）介绍对 RAG 知识库窃取攻击的模型外检查机制：

• 不只在输入端判断内容是否危险；
• 在知识真正被使用时，构造正/反两条验证路径；
• 验证“应当泄露 Canary”与“不应泄露 Canary”等条件，共同决定放行或阻断。

页面显示，该方法将相对平均块恢复率（CRR）从 1.00× 压至 0.04×，约减少 96%，并具有较低假阳性率。演讲也明确其边界：模型外证据可显著降低 RAG 知识库窃取收益，但不覆盖工具越权和持久状态风险。

七、过程监督与轨迹级安全诊断

1. 只看最终答案不能判断执行过程是否可信

演讲用两个答案相同的 Agent 轨迹对比说明：即使最终答案一样，执行过程中仍可能存在：

• 调用了不必要的工具或证据；
• 中间推理脱离证据而产生幻觉；
• 工具失效时不能自适应切换；
• 推理冗余、效率低下。

所以，只看最终答案和单步动作，无法观察完整执行过程的问题。

2. AgentDoG：从轨迹判别到细粒度风险诊断

页面介绍 AgentDoG（标注 arXiv 2026）的轨迹安全判别框架：输入完整执行轨迹，判定是否存在不安全行动或不安全决策模式，并进一步识别：

• 风险来源（如用户、工具、环境、记忆或上下文）；
• 触发因素；
• 失效模式；
• 现实世界危害；
• 判定依据。

它可以将轨迹先判为 Safe / Unsafe，再开展细粒度的风险诊断。页面列出两种应用方式：

1. Training-Based Safety Alignment：作为 Verifier，参与数据筛选和 SFT / RL 反馈；
2. Training-Free System Guardrail：在最终回复（Pre-Reply）前汇聚完整轨迹进行运行时安全检查，决定告警、放行或阻断。

演讲指出其局限：该类方法主要是轨迹级防御，难以直接进行步骤归因，也较难转换为工具调用的奖励信号或动作前门控。

3. AttnPO：将结果级优势重分配到每个步骤

演讲以 AttnPO（ACL 2026、团队工作）介绍过程监督方法：

• 不额外训练过程奖励模型；
• 利用注意力估计步骤必要性，计算步骤分数；
• 对结果级优势进行逐步重标：抑制冗余步骤的正向优势，减轻关键步骤被错误负向削弱的情况；
• 在低开销下获得步骤级信用分配，为安全归因提供基础。

页面展示的实验结果表明，过程监督可将平均响应 Token 大幅压低（约 55%—61%），同时提高 Macro Pass@1（约 +2.9 至 +7.3 个百分点）。演讲说明，正在探索把这类信用分配用于智能体安全：定位危险起点，将信号转化为奖励或控制依据。

八、总结：可信执行的三项工程要求

演讲最后将智能体安全方法论压缩为三个维度：

由此得到“可信执行”的可操作定义：

出现问题时能定位，动作发生前能拦住，后续优化中能纠正。

对系统建设而言，应同时做到：

1. 将模型视作动作提议者，而不是最终授权者；
2. 在模型外设置逐步的策略、权限、状态和工具仲裁；
3. 对输入、工具输出、RAG、Memory 和跨 Agent 通道建立端到端信息流治理；
4. 用可恢复的状态管理、沙箱和审计降低现实副作用；
5. 用完整轨迹诊断与过程监督，持续把风险信号反馈给训练与运行时控制。

一、核心结论

智能体安全的风险重心正在从“说错话”的内容合规问题，转向“做错事”的行为安全问题。具备文件读写、代码执行、跨软件协同和自动化处理能力的智能体，可能将数字空间中的语义失范转化为现实世界或业务系统中的高影响行为失误。

演讲提出一套能力—风险双驱动的三层治理模型：

1. 基础能力层：以模型规约、动作拦截、断路器、行为白名单和日志漂移检测处理意图编排、记忆与行为边界风险；
2. 工具交互层：通过 AI 网关、协议治理、零信任认证、最小权限、即时授权和人机回环，控制 MCP、A2A、SDK、插件与私有协议的工具调用风险；
3. 应用生态层：通过可信分级、上架审核、签名验证、行为审计、责任约定和异常熔断，构建多方协同的生态治理机制。

其主线是：能力与规制同步演进，而不是等风险显现后再被动应对。

二、为什么现在必须讨论智能体安全

演讲以开源 AI 智能体项目 OpenClaw 为背景，指出自主智能体能够执行文件读写、代码执行、跨软件协同与邮件自动化等操作。页面展示了以下风险提示性信息：

• 审计样本中存在恶意 Skill；
• 智能体可 7×24 小时无人值守自主运行；
• 在配置不当时，可能发生邮件被删除等高影响行为。

因此，以内容审查为核心的既有安全范式已不足以覆盖智能体风险。治理对象需要从模型输出内容扩展为：意图、权限、工具调用、执行过程、结果和回滚能力。

三、能力—风险双驱动的三层治理模型

演讲给出的三层模型如下：

模型强调：每一项能力突破都携带伴生风险，治理不是事后补丁，而是在各层同步建立约束。

四、基础能力层：约束目标、记忆和行为边界

1. 主要风险

基础能力层关注运行时的行为问题，而非只关注上线前的内容问题。页面列出了四类核心风险：

• 目标漂移：执行过程中因理解偏差发生目标替换。例如“删除冗余文件”被扩大为大范围清除。
• 过度授权：缺少权限边界时，智能体可能按其认为的“最优路径”执行超出预期的高影响操作。
• 级联错误：多步任务中早期偏差被后续步骤链式放大，最终可能产生不可逆后果。
• 记忆投毒：攻击者向记忆库注入虚假信息，并以个性化服务等形式潜伏、延迟触发。

2. 治理方案：软法与硬约束结合

模型规约：内生规训

页面提出以模型规约作为“软法”机制：

• 以 6 项高阶原则明确核心导向；
• 以 46 条准则指导训练和输出；
• 建立 4 层冲突解决位阶：根准则 > 系统 > 开发者 > 用户；
• 将安全能力开源开放，积累生态反馈。

页面称其为“中国首份开源模型规约”；这一表述按演讲材料记录，未在本整理中独立核验。

动作拦截与断路器：硬约束

• 动作看门狗：独立于主推理过程的安全验证模块；
• 预定义规则库：实时拦截高危动作；
• 断路器：发现短时间内大量跨系统写操作时，自动暂停并上报人工审核；
• 行为白名单：非白名单行动强制确认；
• 持续日志分析：识别意图或行为漂移信号。

五、工具交互层：把工具权限纳入协议化控制

1. 主要风险

工具交互层的风险集中在协议、插件供应链和权限扩张：

• 协议漏洞：页面以 MCP 本地连接缺少身份验证为例，指出攻击者可能伪造请求、冒用智能体身份操控工具。
• 供应链投毒：恶意 Skill 可伪装为正常工具，动态代码加载还可能逃避初次审核。
• 权限蔓延：在“默认允许”逻辑下，调用权限不断扩展，远超实际任务需要。

页面援引 ClawHub 审计信息：在 2,857 个 Skill 中有 341 个含恶意功能，例如窃取凭证、记录键盘。该数字按演讲材料转述。

2. 治理方案：AI 网关统管四类协议

演讲主张以 AI 网关对四类协议/接入方式进行统一治理：

共性能力包括：身份认证、流控和全链路审计。

3. 人机回环、最小权限与即时授权

• 将高危动作的分类标准写入协议规范；
• 在执行前强制触发人工审批；
• 将结果写入不可篡改审计日志；
• 执行 最小权限 + 即时授权：按任务临时授予，不预申请；任务结束即回收。

演讲认为，这种设计可使安全要求从依赖产品自觉，转化为协议强制。

六、应用生态层：把安全变成合作基础和生态准入货币

演讲提出在多方合作生态中建设：MCP 市场 + 可信分级、API 优先 + B-8 握手协议、行为可审计。

1. 生态准入与安全治理

• 工具上架前接受安全审核和签名验证；
• 持续检测恶意 Skill，并支持快速下架；
• 坚持最小权限，不触碰对方安全机制；
• 通过协议明确身份、能力、数据和责任边界。

2. 协议应约定的四项内容

1. 身份标识与能力声明；
2. 数据使用范围与留存期限；
3. 异常行为通报与熔断；
4. 安全事件责任共担。

3. 可信分级机制

演讲将安全定位为“合作基础 + 生态准入货币”。

七、阿里实践：分层安全保障体系

页面将实践路径概括为：

• 基础层：模型规约（6 原则、46 准则、4 层解决机制）+ 危险指令拒绝 + 记忆防投毒；
• 交互层：AI 网关统管四类协议 + 双重授权即时回收 + 循环检测熔断；
• 生态层：API 优选 + B-8 握手 + 身份透明 + MCP 市场可信分级。

整体主线包括：

• 端侧优先、云端最小；
• 从零信任走向可信合作；
• 安全能力开源开放。

八、我国智能体安全的多方协同治理

演讲将治理责任划分为政府、标准体系与企业三方：

标准名称、状态与时间点均按页面 OCR 归纳，需以正式发布渠道为准。

九、五条落地建议

1. 治理重心前移：从内容合规扩展到行为安全，纳入动作授权、拦截与回滚。
2. 重构风险分级维度：以“权限等级 × 后果可逆性”分级，而不是只按应用场景分级。
3. 运行时动态监测：持续检测意图漂移和记忆投毒，备案不能止于静态材料。
4. 明确代理链授权与责任：谁掌握控制力谁承担责任；高风险情形适用更严格的举证责任要求。
5. 安全即代码：把安全约束当作系统内置组件，与业务功能同优先级开发和迭代。

十、总结

演讲以“为智能体装上安全带”作结：治理并非遏制创新，而是让创新能够更快、更稳地发展。

其可归纳的治理方法论是：

基础层内建规约与动作约束，交互层固化身份、权限和审批，生态层建立可信准入与责任协同；以运行时治理覆盖智能体从理解、规划到调用工具和产生现实影响的全链路。

一、核心结论

智能体已由“用户提问—模型回答”的对话工具演化为可自主感知、规划、调用工具并操作外部系统的行动主体。风险因此从“说错话”的信息与内容风险，扩展为“做错事”的权限、执行、记忆、供应链和现实世界副作用风险。

演讲提出以 AIOS（AI Operating System，AI 操作系统） 为技术底座，构建内生安全的企业级智能体体系：

1. 全生命周期治理：从开发态、运行态到运维态覆盖事前预防、事中管控、事后追溯；
2. 分层内生安全：将安全能力嵌入智能体控制器、运行时、资源管理、工具/技能、记忆、模型与基础设施；
3. 生态协同治理：政府指导、供应链与应用领域合作伙伴共建，统一标准、接入、审计、应急和运营机制；
4. 安全与体验并重：通过白名单、动态策略、行为检测和 DevSecOps 门禁，在风险可控的同时尽可能保持用户无感体验。

二、背景：人工智能+推动智能体爆发式增长

演讲以国家“人工智能+”发展背景说明智能体应用扩张。页面引用 2025 年 8 月国务院《关于深入实施“人工智能+”行动的意见》，强调统筹发展与安全，推进重点领域融合、智能终端与智能体普及，并从模型、数据、算力、应用环境、开源生态、人才、政策法规和安全能力等方面建设支撑体系。

页面同时引用 IDC 报告式数据，称 2025 年全球活跃智能体约 2,860 万、2026 年预计约 7,940 万、2030 年约 22.16 亿。具体统计口径以原始 IDC 报告为准；演讲借其说明智能体规模快速扩张，安全治理必须同步建设。

三、从大模型应用到自主行动者：安全范式为何改变

1. 核心差异：自主行动能力

传统大模型应用的交互模式是：

用户提问 → 模型回答

其输出主要限于文本，风险集中在信息准确性、内容合规、输入过滤和输出审核。

智能体则具备自主规划、工具调用和多步执行能力，可直接操纵外部系统：

感知 → 规划 → 执行操作 → 改变环境 → 交付结果

因此，安全风险从信息层扩展到操作层，治理也必须从模型安全升级为覆盖全生命周期的智能体安全体系。

2. 攻击面扩展

智能体的攻击面不再局限于 Prompt 和模型输出，还包括：

• 记忆模块与上下文；
• 执行权限；
• API 调用链；
• 工具、技能和第三方插件；
• 多智能体通信与协同；
• 模型、数据及供应链。

四、智能体风险洞察

1. OWASP 风险从 LLM 应用延伸到 Agent 系统

页面对比 OWASP 2025 LLM 应用风险与 2026 Agentic 风险，指出提示词注入和敏感信息泄漏仍是基础风险，但智能体场景新增或显著强化了：

• 智能体目标劫持；
• 记忆与上下文投毒；
• 工具滥用与误用；
• 身份与权限滥用；
• 不安全的智能体间通信；
• 智能体供应链漏洞；
• 人机信任滥用；
• 非预期代码执行（RCE）；
• 失控智能体；
• 记忆持久化攻击、多模态注入等。

演讲结论是：智能体的高度自主性、多智能体协同和复杂任务执行，使风险呈现组合叠加特征。

2. 仅凭对话也可形成攻击闭环

演讲将攻击路径概括为三个阶段：

这意味着攻击者不一定需要直接入侵底层系统；若能操纵智能体的上下文、规划或执行链，也可能通过正常对话完成渗透或越权行为。

五、建立智能体安全生态：协同治理与系统化能力

演讲主张在政府统一指导下，联合供应链和应用领域合作伙伴，建立统一安全管控机制，保障智能体系统稳定、安全运行。

1. 各方角色

2. 生态所需安全能力

• DevSecOps；
• 交互安全；
• 技能安全、App 安全、工具安全；
• 安全策略引擎；
• 身份与接入管理；
• 大模型安全与数据保护；
• 管理与监控、审计与追溯；
• 响应与处置。

六、AIOS：面向企业智能体的技术底座

1. AIOS 的定位

演讲将 AIOS 定位为支撑“人工智能+”目标的应用内核和企业级智能体平台底座。它服务于系统设备、个人终端、云场景、家庭社区和政企场景等多类应用，并支撑文本、语音、视频、图像等通用 AI 业务能力。

页面提出应用形态从“你问我答”走向“你说我做”，由界面操作走向无界交互，并以 AIOS 构筑企业智能体平台能力。

2. AIOS 分层架构

其中：

• 智能体控制器：统一管理接入通道、消息路由、会话及节点资源；
• 智能体运行时：管理工作空间、上下文、任务、多智能体编排等生命周期能力；
• 智能体资源管理：管理技能、工具、记忆和智能体安全等资源。

七、基于应用场景的威胁建模

演讲提出应结合消息平台、家庭、运营商、企业等不同场景开展威胁建模。智能体在云服务、终端、Agent Loop、模型、RAG、记忆、技能工具、插件和 API 等组件上都可能受到攻击。

页面可辨认的攻击方式包括：

• 身份与权限滥用、权限提升；
• 提示词注入与命令绕过；
• 恶意代码执行、深度伪造；
• 恶意插件与行为劫持；
• 供应链投毒与内存/记忆投毒；
• 模型窃取与模型投毒。

关键判断是：这些风险可能组合叠加，不能只靠单点防护，需要全生命周期、体系化安全方案。

八、AIOS 安全框架：构建内生安全的智能体技术底座

AIOS 安全框架将安全能力嵌入各个层次，以支撑智能体安全应用和安全运营。

1. 分层安全能力

2. 内生安全的含义

内生安全不是在系统完成后简单叠加安全产品，而是将规划、工具、插件、记忆、模型、执行和审计安全作为 AIOS 技术底座的组成部分，使安全能力能够伴随智能体全生命周期运行。

九、全生命周期安全管控

演讲提出覆盖开发、运行和运维阶段的闭环治理。

1. 事前预防：开发态

• 智能体源码开发规范；
• 技能安全扫描、审核上架；
• 安全统一加固；
• 配置基线化；
• 开发阶段安全门禁。

2. 事中管控：运行态

• 高危命令自动拦截；
• 安全策略集中管控与动态更新；
• 基线核查与定时修复；
• 运行监测和安全运营。

3. 事后追溯：运维态

• 安全风险一键止血；
• 异常事件追溯定位；
• 态势分析与运营看板；
• 应急响应与审计。

演讲强调该体系通过纵深防御实现多层次攻击拦截，提高攻击成本并降低单点失效风险。

页面还称：中兴基于 AIOS 的企业级桌面智能体已有超过 6.5 万内部用户，数据 100% 本地化运行，过程可控、可视、可审计；并通过中国信通院智能体平台风险管理能力专项评测。上述均按演讲材料记录。

十、Co-Claw 企业智能体实践

1. 规模化应用场景

页面将 Co-Claw 定位为拥有用户记忆、理解用户习惯、掌握用户数据、调用用户工具以完成工作的“数字分身”。页面展示其已打通 20+ 核心业务系统，在云、地、多端部署下服务企业员工实际工作。

典型场景包括：

页面展示的规模信息为日活峰值 1 万+、总用户数 6.5 万+。这些数值为演讲材料所列。

2. 外部与内部安全要求

页面强调：

• 严格遵守《网络安全法》《数据安全法》及《生成式人工智能服务管理暂行办法》等法规要求；
• 禁止安装未经审批的外部 OpenClaw 类智能体；
• 严禁将涉密信息上传至外部 OpenClaw 类智能体或企业 Co-Claw；
• OpenClaw 类工具安装使用需完成安全加固，并对高危配置和漏洞风险实施预警与防范。

3. 将安全治理纳入 DevSecOps

演讲提出平台与开发者共建安全：

• 开发者：规范编写 Skill；
• 平台：筑牢安全屏障，实施发布门禁；
• Skill 发布到内部技能市场时，CI 自动触发安全扫描；
• 以本次变更的 Skill 目录为输入，递归扫描 SKILL.md、references、scripts 等；
• 按严重级别判定，失败则阻断发布并保留报告；
• 作者按报告整改、重新提交并复测，通过扫描后方可合并或发布。

由此形成“发布—扫描—整改—复测”的自动化闭环。

4. 安全与体验的平衡

页面展示其应用成果包括“双零安全记录”、安全加固、审计看板、风险拦截和无感防护体验等。可清晰辨认的材料性指标包括 1 万+ 次中高危拦截、80 万次中高危累计等，但图中文字与指标关联存在局部 OCR 不清，因此不作精确的完整指标解释。

演讲强调目标是在 AI 原生安全底座上实现“风险可控”与“体验无感”并重，为企业智能体规模化落地提供可复制实践路径。

十一、场景实践：智慧家庭与自智网络

1. 智慧家庭安全

页面展示家庭智慧中屏的安全应用：

• 家庭安防：视频监控、AI 异常行为识别、异常报警联动；
• 儿童照护：科学育儿、视力保护、坐姿识别等；
• 健康照护：健康体征监测、跌倒识别预警、远程陪伴；
• 全屋智能互联：门锁、温湿度传感器、烟雾报警器、摄像头、音箱、灯光、扫地机器人、插座、空调、空气净化器、窗帘等多品牌设备协同。

其安全架构依托端云协同：AIOS 智能体防护体系保障 AI 决策到行为的一致性，大模型安全平台保障内容合规，机密云计算系统满足算力与隐私双重要求。

2. 网络智能体安全

页面展示网络故障处理场景中，监控人员、故障排查人员与故障处理平台通过网络智能体协同完成：

故障发现 → 诊断分析 / 预处理 → 故障闭环 / 处置

安全底座包括安全网关、认证授权、短期/长期记忆、RAG、大模型、技能与工具，以及贯穿 Agent Loop 的感知、规划、执行能力，目标是保障自智网络稳健运行。

十二、展望：原生智能 + 内生安全

演讲最后指出，AI 风险主要出现在认知层，形态多样且业务复杂，传统以“堵”为主的静态安全手段已难以应对。

重点发展方向是面向垂直领域，结合：

• 内生白名单机制；
• 基于 AI 的意图与行为检测分析；
• 业务感知、资产智能识别与自适应防护；
• 动态安全策略与防护；
• 研发态白名单学习、运行态白名单导入；
• 思维链推理审计与纠偏；
• 智能安全管理和运营。

总体转变是：从静态规则驱动、工具堆砌，走向 AI 动态驱动、能力内建与智能安全运营，以构建与智能体发展相适应的新型安全体系。

一、核心结论

网络安全智能体正在由“辅助分析”走向能够连续执行漏洞发现、验证与利用构造的“自主攻防”。这会让攻击更快、更隐蔽、更易规模化，也会明显压缩发现漏洞到实施攻击之间的防御窗口。

演讲的核心主张是：不能只评估智能体“会不会做事”，还必须确保其认知可信、行动可控。网络安全智能体的能力来源——Skill、长期 Memory、多智能体协同、模型规划和工具调用——同时也是认知操纵的主要攻击面。防护应形成从 Skill 准入扫描、形式化验证、运行时审计，到 Memory 投毒/抽取防御，再到独立控制面约束执行权限的体系化闭环。

二、从能力跃迁到自主攻防

1. 演讲对能力跃迁的判断

页面引用 Anthropic 披露的 Mythos 相关案例，用于说明 AI 安全研究智能体可连续完成真实漏洞的发现、验证和利用生成。页面举例提到：

• 在 OpenBSD 中发现长期遗漏的远程崩溃漏洞；
• 在 FreeBSD NFS 中发现存在多年的远程代码执行漏洞；
• 在初始提示后，智能体可在数小时内生成可工作的利用；
• 在 Firefox 目标上可多次生成可工作的利用。

页面还提到英国 AI Safety Institute（页面缩写为 AISI）的专家级 CTF 任务成功率信息。上述案例意在强调：AI 已能把漏洞发现、验证和利用连续推进，安全防御的时间窗口正在被压缩。

2. 网络安全智能体改变的不只是攻击速度

演讲将网安智能体带来的变化概括为四个方向：

因此，演讲提出：当发现和利用提速时，修复、验证与治理也必须同步提速。

3. “扫地僧”网络安全智能体：可验证的漏洞挖掘闭环

天津大学的“扫地僧网络安全智能体”被描述为不是简单给出答案，而是持续完成：

理解 → 分析 → 构造 → 验证 → 可复核证据输出

其结构要点包括：

• 以代码与系统、攻击面与约束、任务目标为输入；
• 通过 Skill 指导长程执行，通过 Memory 保存中间状态；
• 由多智能体协同开展探索、分析、构造和验证；
• 输出漏洞证据、验证样例与风险路径，形成可复核成果。

4. 演讲展示的阶段性能力效果

页面称其在两个月内覆盖 134 个开源项目，形成规模化、多类型的漏洞发现与自动验证能力；页面还列出了“300+ 自动化发现漏洞”“200+ CNVD/CVE”“高危/严重漏洞”等信息，但图中不同数字与标签的对应关系部分不清晰，故不将其组合为精确统计结论。

可清晰辨认的能力覆盖包括：

• 文件与路径安全；
• 注入类漏洞；
• 身份认证与访问控制；
• 权限与业务逻辑；
• 信息泄露；
• 代码执行、二进制漏洞与服务端风险。

5. 支撑长程任务的三类核心能力

演讲认为，网安智能体要持续完成自主漏洞挖掘等长程任务，需要三类支撑：

1. 专业知识 / 网安知识：回答“会什么”，支撑信息感知、分析研判与构造验证。
2. 长期 Memory 管理：回答“记住什么”，实现知识沉淀、检索复用、复盘修复与持续迭代。
3. 多智能体协同机制：回答“如何持续完成”，支持分工协作和交叉验证。

能力、知识、记忆与协同共同决定了智能体能否完成可靠的长程安全任务。

三、认知安全：阻断错误认知转化为越权行动

1. 认知安全的定义与攻击面

演讲将“认知安全”定义为：确保智能体的能力、知识与协同可信，并阻断错误认知进一步转化为越权行动。

页面给出的关键逻辑链为：

外部输入 → 模型与规划 → 工具行动 → 反馈与写回

在该链条中：

• Skill 和多智能体协同提供能力，也可能遭投毒、恶意节点影响或协同机制操控；
• Memory沉淀知识和经验，也可能面临投毒、泄露与约束丢失；
• 一旦目标可信度下降、规划出现错误，可能导致错误决策、越权调用乃至现实世界影响；
• 错误经验写回后还会持续放大，形成自强化风险。

四、Skill 供应链：从单文件检查走向链、数据流与执行过程

1. 开源 Skill 的供应链风险

演讲指出，开源 Skill 将供应链风险带入智能体的能力入口。页面基于对 31,132 个公开 Skill 样本的系统分析，给出如下材料性统计：

材料列出的潜在影响包括敏感数据外传、凭据窃取、远程代码执行和智能体行为操纵。其关键提醒是：Skill 即使能正常完成表面任务，也可能在后台执行用户未授权的高风险操作。

2. 新型 Skill 链攻击：单点无害、组合有害

页面以 ColluSkill：Multi-Skill-Chain Attack 描述一种链式组合攻击：

1. 将完整恶意目标拆解为多个相互依赖的子载荷；
2. 将子载荷分别植入看似正常的 Skill；
3. 单独检测时，任何单个 Skill 都未呈现完整恶意行为，因而可能通过检查；
4. Agent 运行时借助上下文关联与执行交接重新组合载荷并触发攻击。

该案例的结论是：Skill 安全分析不能停留在“单个文件”，必须扩展到 Skill 链、数据流和完整执行过程。

3. Skill 三层防御：准入扫描、形式化验证、运行时审计

准入扫描：识别“有没有可疑”

• 检查 Skill 描述、自然语言指令、脚本、依赖和权限声明；
• 识别危险模式、隐藏语义风险、提示词注入、数据外传、权限提升和供应链风险；
• 页面展示的检测效果为精确率 86.7%、召回率 82.5%（按页面可辨认文字记录）。

形式化验证：证明“安全边界是否始终成立”

• 为关键 Skill 建立行为契约；
• 验证敏感数据流、高风险操作前置条件及多 Skill 组合约束；
• 将安全要求从“看起来正常”提升为可验证的持续约束。

运行时安全审计：观察真实行为并阻断

即使通过形式化验证，动态生成、环境依赖与真实组合行为仍可能引入建模外风险。页面提出在隔离沙箱中：

• 执行可疑 Skill；
• 捕获运行时生成或解码的新指令；
• 跟踪敏感数据在上下文、文件、进程与网络之间的流动；
• 按真实行为判定数据外传、越权写入与恶意执行。

页面展示“现有实验：检出率 96.7%、误报率 2%”的结果性文字；由于图中实验条件与完整定义无法从照片完全核验，本整理仅按演讲材料转述。整体上，三层机制形成“发现—证明—阻断”的防线。

五、Memory 安全：防投毒、防抽取、防约束丢失

1. 多维 Memory 风险

演讲指出，Memory 风险既可能来自外部对话中的恶意写入，也可能来自压缩、摘要和遗忘造成的约束丢失。错误记忆一旦被再次检索，会跨轮次影响推理与行动。

材料强调两类问题：

• 对抗安全：攻击者用对话形式注入有害信息，诱导错误行为；
• 内生安全：记忆压缩可能丢失原始指令、意图或限制条件，导致安全边界退化。

页面以公开报道式案例说明，自动化清理邮箱等具备执行权限的 Agent，若在记忆/上下文处理中丢失“不执行”的限制，可能造成批量删除等不可逆后果。该案例用于说明风险机制，不作为本整理的独立事实核验。

2. Memory 投毒：一次写入，跨会话持续控制

Memory 投毒跨越两个阶段：

• 写入阶段（Write Session）：攻击载荷进入长期记忆；
• 检索阶段（Retrieval Session）：后续正常任务中召回被投毒的 Memory，影响行为。

页面列出的投毒类型包括：

• 显式命令插入；
• 条件命令插入；
• 显著性驱动的压缩投毒；
• 策略一致型虚假事实注入；
• 虚假先例注入；
• Skill 程序注入。

页面以 ASR（写入成功率）衡量恶意目标是否进入长期 Memory，以 RSR（检索成功率）衡量已写入投毒 Memory 是否在后续会话被召回并影响行为。关键风险在于：攻击载荷只需出现一次，恶意影响却可以跨会话持续并被正常任务重新激活。

3. Memory 抽取：由辅助上下文变成隐私外泄通道

Memory 抽取不一定修改 Memory；攻击者可通过黑盒查询诱导 Agent 检索并输出历史交互记录。演讲展示的攻击路径是：原本用于辅助当前任务的历史记忆，被带入搜索/API 等工具调用，从而被导出到外部工具界面。

因此，隐私风险不仅来自 Memory 的存储本身，也来自检索结果进入工具后的越权使用。

4. Memory 防御：自检与自纠错

演讲提出两类防御机制：

共识验证：让 Memory 自检

• 同一查询召回多条相关记忆，形成平行推理路径；
• 比较路径间的一致性，识别偏离多数共识的异常路径；
• 过滤异常路径对应的记忆，避免其进入最终决策。

双 Memory 结构：让 Memory 自纠错

• 将异常推理蒸馏为负面 Lesson，与正常经验分开存储；
• 行动执行前检索相关 Lesson，命中时触发计划修正；
• 将已发现攻击转化为防御经验，避免同类错误重演。

其目标不仅是识别异常记忆，更是阻断错误经验在“检索—执行—写回—持续放大”循环中自我强化。

六、高风险行业：认知偏差会被执行环节放大

演讲以医疗和能源基础设施说明，认知偏差一旦进入执行环节，可升级为生命伤害、设备事故和系统停摆。

演讲要求高风险场景同时验证：知识来源、版本、判断依据和执行边界，并引入权威知识版本、时效/冲突检查、业务规则硬约束和专业人员复核。

七、可信行动架构：认知可信，行动可控

演讲的最终架构将系统分为两部分：

1. 认知层：负责形成方案，包括可信能力（Skill）、可信 Memory/经验/约束、模型、工具与参数建议以及任务计划。
2. 独立控制面：负责最终授权，不能由模型自我判断，应独立施加任务级最小权限、执行权限边界、参数约束、独立验证、沙箱与网络控制、人工审批等机制。

总结性观点是：

可信不是永不出错，而是认知可校验、行动可阻断、状态可恢复。

八、主要启示

1. 把 AI 安全能力提升视为攻防时钟加速器：漏洞发现、验证和利用已趋于连续化，防御流程必须同步自动化和前移。
2. 把 Skill、Memory、协同机制纳入关键供应链治理对象：它们不只是增强能力的组件，也是可被投毒和利用的认知入口。
3. 分析对象从单点扩展到运行全链路：应同时审查 Skill 链、上下文连接、数据流、实际执行行为和反馈写回。
4. 将 Memory 视为可持续攻击面：需要覆盖写入、压缩、检索、工具调用和回写各环节，防止跨会话持续控制与隐私外泄。
5. 模型决策与行动授权必须分离：模型可以提出建议，但高风险权限、参数、网络和现实系统操作需由独立控制面校验和授权。
6. 高风险行业要落实可恢复性与人工复核：在医疗、能源等领域，版本控制、规则约束、隔离和人工审批不是可选项。