当 AI Agent 理解其自身的 Guardrails 时会发生什么？
Source: Dev.to
信任代理——为何防护栏不足
在本系列的 第 1 部分 中，我指出每个主要的 AI‑代理框架都 信任代理。
它们会验证输出、过滤响应并限定工具范围。
但它们都没有回答真正的问题：
谁授权这个代理执行操作？
隐藏的问题：代理可以读取防护栏
目前大多数 AI 防护栏的工作方式如下：
| 防护栏 | 实施方式 |
|---|---|
| 系统提示 | “不要做 X” |
| 输出过滤器 | 检查是否匹配 X 的模式 |
| 工具白名单 | 限制代理可以调用的函数 |
一个足够强大的代理会知道：
- 它可以读取（或推断）系统提示。
- 它可以测试输出过滤器捕获的模式。
- 它可以枚举可用工具及其参数。
- 它可以推理出预期与实际执行之间的差距。
这并非理论上的假设。任何能够进行多步规划的模型都可以对自身约束进行建模。
问题不在于它 是否 会理解防护栏——而在于 何时 会理解。
AI 代理的 Kerckhoffs 原则
1883 年，Auguste Kerckhoffs 提出了一个每位密码学家都视为金科玉律的原则：
系统应当在除密钥之外的所有信息都已知的情况下仍保持安全。
应用到 AI 代理上： 你的 授权系统 应当在代理对其工作原理了如指掌的情况下仍保持安全。
主要框架在 Kerckhoffs 原则下的表现
| Framework | Agent knows the rules? | Still secure? |
|---|---|---|
| System‑prompt restrictions | 是（它收到提示） | 否 – 可以构造边缘案例 |
| Output filtering (Guardrails AI) | 可以通过试错进行探测 | 部分 – 预言机攻击会削弱其效果 |
| Tool allowlists | 是（它能看到可用工具） | 否 – 可以将允许的工具链式组合成意外结果 |
| Rate limiting | 可以观察自己的吞吐量 | 否 – 在限制内最大化破坏 |
| K‑of‑N threshold authorization | 是（了解协议） | 是 – 知识并不能帮助伪造 K 个独立批准 |
关键洞见： 阈值授权 是唯一在 Kerckhoffs 原则下仍然安全的机制。
代理可以完全理解 Shamir 秘密共享的工作原理，研究 K‑of‑N 协议，并记住代码。但这些都无法帮助它伪造它不控制的 K 个独立批准。
逻辑约束 vs. 结构约束
| 类型 | 示例 |
|---|---|
| 逻辑约束 | if "transfer" in action and amount > 10000: block() |
| 结构约束 | “需要来自独立节点的 3‑of‑5 阈值签名。” |
逻辑约束 可以通过拆分转账、使用同义词或发现未预料的边缘案例来绕过。
结构约束 在不破坏所需独立节点的前提下无法被绕过——仅仅了解规则是无用的。
Source: …
IC‑AGI：四（实际上是五）结构防御
每一层都设计为 即使代理完全了解防御机制 仍能保持有效。
第 1 层 – 阈值授权
关键操作需要 K‑of‑N（K ≥ 2）独立批准。阈值在初始化时强制执行：
if threshold = 2 (no unilateral authority)代理不能批准自己的请求；它必须同时控制 K 个独立批准者，可能分布在不同组织或司法辖区。这是一个协同问题，而非智力问题。
第 2 层 – 反 Oracle 检测
系统使用滑动窗口跟踪每个实体的查询模式。重复或系统性变化的查询会提升怀疑分数；当分数超过阈值时，该实体将被阻断。
@dataclass
class AntiOracleConfig:
window_seconds: float = 120.0
max_identical_queries: int = 5
max_similar_queries: int = 15
suspicion_threshold: float = 0.8即使代理知道此检测机制的存在，它也只能放慢探测速度。所需的预算（见第 3 层）会在其收集足够数据之前耗尽。
第 3 层 – 可消耗预算令牌
每个能力令牌都有 有限预算，使用一次即减少——这是硬性上限，而非速率限制。
{
"scope": "crm.update",
"budget": 50,
"ttl": "3600s"
}使用 50 次后令牌失效。快速探测会被第 2 层阻止；慢速探测则被预算上限终止。两者结合使得 Oracle 攻击在任何策略下都在经济上不可行。
第 4 层 – 断路器隔离
如果工作者表现异常（高错误率、意外模式），断路器会触发并将其隔离。
CLOSED (healthy) → failure rate > threshold → OPEN (blocked)
↑
recovery timeout |
↓
CLOSED ← probe succeeds ← HALF_OPEN (one probe allowed)了解断路器的工作原理并无帮助：它响应 行为，而非意图。正常行为保持断路器闭合；异常行为触发隔离。
第 5 层 – 沙箱执行
当代理代码运行时，它会在一个执行 AST‑级白名单 的沙箱中运行。在任何字节代码执行之前，所有 AST 节点都会与白名单进行检查，确保只有被允许的构造能够运行。
（原始代码片段被截断；沙箱实现遵循相同原理。）
为什么这样有效
这些结构性防御为代理创建了一个 占优策略均衡：
- 对代理来说，最佳行动是正常行为，因为任何试图颠覆系统的尝试要么失败（阈值、预算），要么导致被隔离（断路器、沙箱）。
- 对防御的了解并不会降低攻击成本；它只是确认防御是坚固的。
要点
逻辑防护栏（系统提示、输出过滤器、工具白名单）对能够读取和探测它们的智能代理是 易受攻击的。
结构性防御——阈值授权、反‑oracle 检测、可消耗预算、断路器隔离以及沙箱执行——即使在 Kerckhoffs 原则下仍然 安全。
通过层叠这些机制，我们可以构建在 即使代理了解所有防护栏 的情况下仍能受控的 AI 代理系统。
# Security Architecture Overview
> This isn't a filter that can be bypassed with creative encoding. It's a whitelist.
> If it's not explicitly in the safe set, it doesn't run. Period.
```python
# Whitelisted names – no imports, no exec, no eval, no filesystem, no network.
_FORBIDDEN_NAMES = frozenset({
"import", "__import__", "exec", "eval", "compile",
"open", "input", "os", "sys", "subprocess", "socket",
"pathlib", "io", "ctypes", "signal", ...
})
## 核心论点（重新表述自博客 #1）
每个单独的层都可以被足够强大的代理击败，**但整体组合则不行**。
- 一个了解阈值认证的代理可以尝试探测系统。
*anti‑oracle detector 捕获探测行为。*
- 一个放慢探测速度以避免被发现的代理会耗尽预算令牌。
*budget‑token limiter 阻止它。*
- 一个尝试利用 worker 的代理会被断路器拦截。
*circuit‑breaker 中止该利用。*
- 一个尝试运行恶意代码的代理会触及 AST 白名单。
*whitelist 阻止该代码。*
> 每条从一个层逃出的路径都会进入另一个层的执行区。
> 这不是巧合——这就是架构本身。
## 为什么现在很重要
- **当前模型**（GPT‑4、Claude、Gemini）已经能够对代码和博弈论进行推理，建模约束，并发现边缘情况。
- **未来模型**将在这方面表现得更好，而不是更差。
如果你的代理控制系统依赖于代理*不*了解其工作原理，那么你的时间已经不多了。模型能力与防护栏复杂度之间的差距每个季度都在缩小。
## 行动号召
- 问题不在于**是否**采用结构化授权，而在于**何时**——在第一次重大事故之前还是之后。
### IC‑AGI 项目
- 开源，遵循 Apache 2.0 许可证
- **273 个测试**、**159 项正式验证**、**零安全违规**
- 从头开始设计，针对能够完美理解系统的对手
如果您对系统组合出现问题的地方有想法，请**提交 issue**或留下评论。
## 系列下一篇：可消耗预算令牌：AI 代理的 OAuth