Agent Governance Toolkit（AGT）已知限制与设计边界：透明化治理边界的权威技术指南

• 人工智能
• AI Agent
• AI 安全治理
• 策略引擎
• Agent 沙箱
• 认证鉴权

导读：AI Agent 治理框架并非无所不能，明确"它不做什么"与知道"它能做什么"同样关键。本指南以仓库官方文档 docs/LIMITATIONS.md 为骨架，逐条拆解 Agent Governance Toolkit（AGT）在动作治理、审计、性能、凭证、流式数据、物理智能体等 13 个维度上的已知限制与设计边界，并结合仓库源码（PromptDefenseEvaluator、KillSwitch、策略回放引擎、agtCLI 等）验证每一项缓解措施的真实实现，帮助你基于事实做出架构决策、规避误用风险。

1. 治理边界全景：AGT 只管"动作"，不管"思维"

AGT 治理的是智能体做了什么——工具调用、资源访问、智能体间消息；它不治理智能体想了什么、说了什么。这一条是理解后续所有限制的总纲。

实践含义：

• ✅ 策略禁止delete_file时，AGT 会拦截该工具调用
• ❌ AGT不检测传入被允许工具的参数内容是否为幻觉产物
• ❌ AGT不检测污染智能体推理的间接提示注入（indirect prompt injection）
• ❌ AGT不关联多个单看都合法的动作，去识别一个恶意工作流

示例缺口：若策略同时允许read_database与send_slack_message，智能体可以读取客户列表并发布到公开频道——两个动作单独看都合规。

1.1 跨会话变体：持久化状态下的攻击链

同样的缺口会跨越会话边界放大：当持久化记忆或持久化工具（笔记、文件、日历）在权限隔离下于会话之间携带攻击状态时，一个被后门化或被提示注入的模型可以在会话 A 写入攻击状态，在会话 B（其工具集允许下一阶段动作）中从该状态继续——每个会话内的单个动作都策略合规，但完整攻击链只在会话序列的维度上成立。原文档引用 Dai et al.（2026 年 5 月预印本）的外部分析指出，在供应链 SFT 交付场景下，四个基础模型上的攻击成功率高达 80–95%，且该攻击可推广到分支合并（branch-and-merge）等替代拓扑以及用 note-tool 替代记忆的持久化组件形态。

现成缓解措施：

• 使用内容策略（blocked patterns，正则）拦截输出中的 PII
• 使用PromptDefenseEvaluator在部署前测试系统提示词的提示注入防御缺口
• 叠加模型层安全组件（如 Azure AI Content Safety 一类的输入/输出过滤层）
• 使用max_tool_calls上限约束动作序列长度

正在构建：评估动作序列（包括持久化记忆下的跨会话序列）的工作流级策略；智能体在行动前声明意图（intent declaration）、由策略引擎校验计划的机制。

1.2 源码验证：PromptDefenseEvaluator 的真实能力

文档提到的 PromptDefenseEvaluator 可在 agent-compliance/src/agent_compliance/prompt_defense.py 找到。它是一个纯静态分析器：不调用 LLM、无网络访问、无外部依赖，同一输入恒有同一输出。

• 覆盖17 个攻击向量：12 个映射到 OWASP LLM Top 10（角色边界、指令覆盖、数据泄露、输出操控、多语言绕过、Unicode 攻击、上下文溢出、间接注入、社会工程、有害内容、滥用防护、输入校验），5 个映射到 OWASP Agentic Top 10 / ASI（跨智能体授权边界、金融交易护栏、技能来源证明、最小代理权/目标劫持抵抗、编码感知注入）；
• 每条规则由若干正则模式组成，多数要求min_matches=2——避免仅出现攻击词汇（如 "Ignore all previous instructions"）就被误判为"已防御"；
• 输出 A–F 字母评级（阈值 90/70/50/30/0），is_blocking(min_grade)可判定是否低于部署门槛；
• 对超长提示（>100,000 字符）直接抛ValueError，作为对抗 ReDoS 的纵深防御；
• 报告可经to_audit_entry()写入 Merkle 审计链，或经to_compliance_violation()转换为合规违规条目。

需要注意：它验证的是防御性语言是否存在于提示词文本中，不是运行时行为——这与"AGT 治理动作而非推理"的边界完全一致。

2. 审计日志记录"尝试"，不记录"结果"

AGT 的审计轨迹记录智能体尝试了什么、治理层是放行还是拒绝，但不验证动作在外部世界是否真的成功。

示例缺口：智能体调用某个返回200 OK的 Web API，但数据已过期。AGT 记录"动作已允许、已执行"，而智能体的目标实际并未达成。

现成缓解措施：

• 使用SRE 模块与 SLO 长期跟踪动作成功率
• 对多步骤工作流使用saga 编排与补偿动作
• 在智能体代码中实现应用层结果校验

正在构建：动作执行后由用户注册校验器检查世界状态（world-state）的后动作验证钩子；审计日志中的结果证明（outcome attestation：succeeded/failed/unknown）。

仓库中的审计实现（如 agent-os/src/agent_os/audit_logger.py）与策略回放引擎 policy_test.py 都印证了这一点：回放引擎断言的是"动作应被允许/拒绝"（expected_verdict），而不是"动作执行后外部世界变成什么样"——结果验证必须由上层业务逻辑补齐。

3. 性能边界：策略评估 vs 端到端开销

官方公布的 <0.1ms 策略评估基准，仅指策略引擎本身——确定性规则求值这一步，它是准确且可复现的。但在分布式多智能体部署中，完整治理开销包含多个组件：

单智能体、单进程部署：<0.1ms 就是全部开销。

多智能体 mesh 部署：每次受治理的智能体间交互预计5–50ms，大头是密码学验证与网络延迟——而非策略引擎本身。

这提示了一个重要的容量规划原则：如果你的延迟预算紧张，应先优化签名验证与网络拓扑，而不是盯着策略引擎做微优化。

4. 复杂度谱系：从单文件策略到全栈安装

AGT 面向企业级治理设计。对于简单用例，完整技术栈（mesh 身份、执行环、SRE）可能过重。

最小路径（无 mesh、无身份）：

from agent_control_specification import AgentControl runtime = AgentControl.from_path("policies/manifest.yaml") # 原生 ACS 策略评估，不依赖 mesh 或身份体系。

全量路径（全部组件）：

pip install agent-governance-toolkit[full]

你不需要采纳整个技术栈。每个包都可独立安装、独立使用。仓库结构（agent-governance-python/下 agent-os、agent-hypervisor、agent-compliance、agent-sre、agent-marketplace 等独立包）正是这一设计的具体体现——例如仅做策略回放 CI 门禁时，只需agent_compliance.policy_test.replay(policies_dir, fixtures_dir)或agt test policies/ fixtures/即可，见 policy_test.py。

5. 供应商独立性：零云依赖的核心包

AGT 采用 MIT 许可，核心包零 Azure/Microsoft 依赖。策略引擎、身份系统、信任评分、执行环完全离线运行，不需要任何云服务。

• 云集成确实存在（Azure AI Foundry 部署指南、Entra ID 适配器），但都是可选且位于独立包中。你可以把 AGT 部署在 AWS、GCP、本地机房或气隙（air-gapped）环境。
• 验证方式：运行agt doctor——它会列出所有已安装包，且均不要求云连接。该命令在 agt.py 中与verify、lint-policy、test、version等子命令一同注册，属于统一 CLI 的诊断入口。
• 迁移路径：所有治理状态（策略、审计日志、身份密钥）都以标准格式存储（YAML、JSON、Ed25519 密钥），无专有格式、无云锁定状态。

6. AGT 是什么，以及它"不是什么"

这张表是选择治理方案时的定位工具：当你的诉求是"阻止未授权动作"时，AGT 是正确选择；当诉求是"内容是否安全"或"结果是否正确"时，需要与其它层配合。

7. 推荐架构：分层纵深防御

生产部署官方推荐分层防御：

┌─────────────────────────────────┐ │ Model Safety Layer │ Azure AI Content Safety, Llama Guard │ (input/output filtering) │ ← 拦截幻觉、有害内容 ├─────────────────────────────────┤ │ AGT Governance Layer │ 策略引擎、身份、信任、审计 │ (action enforcement) │ ← 拦截未授权动作 ├─────────────────────────────────┤ │ Application Layer │ 你的智能体代码、框架适配器 │ (business logic validation) │ ← 拦截领域特定错误 ├─────────────────────────────────┤ │ Infrastructure Layer │ 容器、网络策略、IAM │ (OS/network isolation) │ ← 拦截逃逸尝试 └─────────────────────────────────┘

AGT 是纵深防御策略中的一层，而不是整个策略。模型安全层解决"说得对不对"，AGT 解决"做没做错"，应用层解决"业务结果对不对"，基础设施层解决"跑不跑得出去"。

8. 知识治理缺口：RAG 与数据溯源不可见

AGT 治理智能体的动作，不治理智能体消费的知识——推理期间检索的文档、数据库、嵌入向量与上下文。

实践含义：

• ✅ 策略禁止send_email时，AGT 会拦截
• ❌ AGT不验证RAG 检索文档的溯源、新鲜度或授权
• ❌ AGT不跟踪哪些知识源影响了智能体的决策
• ❌ AGT不在检索到的上下文上强制数据分类标签

示例缺口：智能体经搜索工具检索到机密 HR 文档（策略允许），再在 Slack 消息中总结（也被允许）。两个动作都单独受治理，但"机密数据到达未授权渠道"这条知识流对 AGT 不可见。（该缺口由外部分析方 Mojar AI 指出。）

现成缓解措施：

• 使用**出口策略（egress policies）**限制智能体可发送数据的域名
• 使用blocked_patterns拦截工具参数中的 PII/机密模式
• 叠加数据分类层，在上下文进入智能体之前打标签

正在构建：外部知识治理系统的集成点；审计日志中的上下文溯源跟踪。

9. 凭证持久化缺口：会话内令牌的"幽灵"

AGT 治理智能体对工具的使用，不管理也不观察智能体在会话内各任务之间持有哪些凭证。

实践含义：

• ✅ AGT 会拦截智能体调用未授权工具
• ❌ AGT不跟踪智能体当前持有哪些 API Key、OAuth 令牌或密钥
• ❌ AGT不在会话内任务边界撤销凭证
• ❌ AGT不检测超出当前任务所需的凭证累积

示例缺口：智能体为任务 A 收到邮件 API 令牌，随后进入不需要邮件权限的任务 B，令牌仍然有效。若智能体在任务 B 期间被攻陷，攻击者就获得了本应已失效的邮件访问权。（该缺口由外部分析方 Moltbook 指出。）

现成缓解措施：

• 在 Agent OS 策略中使用作用域能力（scoped capabilities），按任务上下文限制可用工具
• 使用外部密钥管理器（如 Azure Key Vault、HashiCorp Vault）的短期凭证与基于 TTL 的轮换
• 在 AgentMesh 中使用信任衰减（trust decay），随时间降低信任分

正在构建：任务级凭证生命周期钩子；上下文切换时的自动凭证撤销。

10. 初始化与配置绕过风险：未加载策略 = 默认放行

AGT 的治理强制要求正确初始化。如果导入了治理中间件但未正确配置，智能体可能在无有效策略执行的情况下运行。

实践含义：

• ✅ 正确加载策略并初始化后，AGT 在执行前强制所有规则
• ⚠️ 若策略求值器未加载任何策略，默认动作是allow——所有动作未经治理直接通过
• ⚠️ 若误用permissive模式而不自知其放行一切，智能体等于裸奔
• ✅ 策略求值运行时错误时，AGT失败关闭（fail closed，拒绝访问）——这是正确行为

示例缺口：开发者导入agent_os并接入框架，但忘记加载策略文件。治理面板显示"已治理"状态，实际没有任何规则生效。（该风险由外部红队分析方 Periculo 指出，共归纳了 15 类绕过向量。）

现成缓解措施：

• 生产环境使用strict 模式（默认拒绝）——每个允许动作都要显式放行规则
• 使用agt audit命令验证已加载策略、发现 permissive 默认值
• 使用MCP 安全扫描器校验工具配置
• 运行agt doctor检查所有组件是否正确初始化

正在构建：未加载策略时告警的启动校验；面板显示有效执行状态（而非仅导入状态）的指标。

11. 物理 AI 与具身智能体治理：不做硬件安全

AGT 治理通过 API、MCP 或智能体间协议调用工具的软件智能体，不提供面向物理智能体（机器人、无人机、自动驾驶、工业执行器）的治理原语。

实践含义：

• ✅ AGT 可以治理机器人智能体的软件决策层（例如拦截"启动机械臂"的 API 调用）
• ❌ AGT不提供硬件急停、力限制或执行器安全联锁
• ❌ AGT不建模物理世界状态、碰撞边界或安全区域
• ❌ AGT不满足实时控制回路的延迟要求（通常 <10ms）——策略求值 <0.1ms 足够快，但完整治理栈（身份、信任、审计）可能跟不上

示例缺口：受 AGT 治理的仓库机器人的move_to_location调用被策略批准，但目标位置正站着人——AGT 没有空间感知能力来发现这一点。

现成缓解措施：

• 用 AGT 策略引擎治理决策层——在执行器层之前拦截不安全指令
• 叠加领域专用机器人安全框架（如 ROS 2 Safety Controller、ISO 10218 / ISO 15066 合规层）
• 用**执行环（execution rings）**把物理执行器调用隔离到 Ring 0，并要求人在环审批

状态：物理 AI 治理不在 AGT 当前路线图范围内，官方欢迎社区贡献探索该领域。

12. 流式数据与实时保障：逐动作求值，不做流内检查

AGT 在调用时刻逐动作求值策略，不对流式数据、实时传感器馈送或长时数据管道提供连续保障。

实践含义：

• ✅ AGT 可治理智能体订阅数据流的决策
• ❌ AGT不检查活跃流内的单条消息
• ❌ AGT不保证流式场景下的数据新鲜度、完整性或一致性
• ❌ AGT不检测订阅批准之后、经治理流到达的过期或被投毒数据

示例缺口：智能体订阅实时行情源（策略允许）。上游故障导致流开始返回过期数据。AGT 记录订阅已批准，但对数据质量退化毫无可见性。

现成缓解措施：

• 用SRE SLO在流层面监控数据新鲜度与错误率
• 用**断路器（circuit breakers）**在上游数据质量恶化时暂停智能体动作
• 在智能体代码中实现应用层流校验

13. 跨 SDK 一致性（一）：DID 方法前缀不统一

AGT 在多个 SDK 中使用两种 DID（去中心化标识符）方法前缀：

实践含义：

• 两种格式使用相同的密码学原语（Ed25519），功能等价
• 只要双方正确解析 DID，跨 SDK 智能体交互即可工作
• 按 DID 前缀匹配的策略规则（如did:mesh:*）不会匹配使用did:agentmesh:*的智能体，反之亦然

现成缓解措施：

• 策略中使用通配 DID 匹配（如did:*）兼容两种格式
• 在应用边界把 DID 归一化后再交给策略引擎
• 构建跨 SDK 系统时，身份生成使用同一 SDK 家族

正在构建：计划在 v4.0 将全部 SDK 的 DID 方法标准化为did:agentmesh:*；配套的存量身份注册表迁移工具。

14. 跨 SDK 一致性（二）：Kill Switch 语义差异

kill switch一词目前不描述一个跨 SDK 统一的终止契约。一次已记录的 kill 或激活的开关，本身不应被当作"执行进程已停止"的证明。

14.1 Python 语义

hypervisor/security/kill_switch.py 中的KillSwitch把进程终止委托给register_agent()注册的回调：

• 若未注册回调，kill()仍然返回并记录一个KillResult，但terminated为False；
• 回调抛异常或超过默认5 秒回调超时，同样产生terminated=False（回调在守护线程中运行，超时即放弃，保证 kill 流程本身不被卡死）；
• 每次 kill 尝试后（包括失败或超时）都会无条件移除目标智能体的回调注册。想重试terminated=False的调用者，必须重新注册智能体再调kill()；
• 进行中的步骤交接/补偿（saga step handoff）与进程终止是两回事，handoff 成功不意味着终止回调成功。

14.2 跨 SDK 对比

14.3 操作指引

• Python：在把遏制视为已确认之前，检查result.terminated；重试失败或超时的 kill 前先重新注册智能体。
• TypeScript：检查result.terminated以确认每个已注册终止处理器都跑完。这不独立证明外部进程已停止。抛异常、reject 或超过callbackTimeoutMs的处理器会被报告为"未执行"而非传播异常，因此kill()总会结束并总会记录这次尝试；卡死的处理器会被放弃并保持 pending（JavaScript 无法取消它，Python 端口因同样原因放弃守护线程）。
• Go：把Activate()当作协作式断路器。它改变DecisionFor()的返回值，但正在运行的工作必须查询该决策，开关才会影响执行。

15. 结语：透明边界是可靠架构的前提

AGT 的边界清单（docs/LIMITATIONS.md）不是缺陷列表，而是一份设计契约：它明确了治理层在哪里止步、上层需要补什么、哪些能力在路线图上。实践建议归纳如下：

1. 动作治理 + 模型安全 + 业务校验 + 基础设施隔离四层齐备，才构成完整的纵深防御；
2. 生产环境使用strict 模式，并用agt doctor、agt audit持续验证加载状态；
3. 涉及凭证、知识流、流式数据或物理执行器时，把 AGT 视为决策层组件，在其上叠加领域专用控制；
4. 跨 SDK 混用时，先归一化 DID、明确 kill switch 语义，再谈身份与遏制的一致性。

该文档与代码库同步维护。若你在使用中发现清单之外的新限制，可在仓库中提交 issue 反馈，帮助社区持续完善这份边界地图。

• 人工智能
• AI Agent
• AI 安全治理
• 策略引擎
• Agent 沙箱
• 认证鉴权