AL1 监督内建于设计
结构化的计划、可追溯的工具调用，以及由人来决定的清晰交接点。
智能体系统的安全方法
关于监督、能力边界、安全工具使用与鲁棒拒绝行为的研究。
一个系统：对良性请求始终乐于相助，对恶意请求始终可靠把守。
监督 边界 拒绝
我们如何理解安全
安全是一种架构属性，而非最后一层提示词
我们的安全工作内建于架构之中：在运行时强制执行的能力边界、让人类审阅者保持高效且知情的监督界面，以及在对抗性压力下接受检验的拒绝行为。目标是一个对良性请求始终乐于相助、对恶意请求始终可靠把守的系统。
提示词层面的安全 → 在下一次越狱之前都有效
架构层面 → 即便提示词失守，边界依然成立
三项承诺
安全工作的落脚之处
AL2 能力边界
智能体在工具与数据的显式白名单内运作。边界在运行时层强制执行，而不仅靠提示词。
AL3 鲁棒拒绝
拒绝行为针对对抗性提示词、提示词注入与利益诱导压力进行检验。衡量标准是「对良性请求始终乐于相助」，而非「拒绝坏请求」。
白名单 · 运行时策略
工具默认拒绝。放行须显式声明。
由运行时而非提示词来裁决。不在白名单上的工具无法被调用，即便智能体认为它应该被调用。
工具 范围 区域 裁决
read_doc allow public + signed pass
web_search allow rate-limited pass
send_email deny requires reviewer block
shell_exec deny no sandbox match block
pay_invoice deny human-only block
compile_code allow sandbox · read pass
拒绝鲁棒性
对良性请求始终乐于相助。承压之下始终坚守。
衡量标准不是「拒绝坏请求」。衡量标准是「对良性请求始终乐于相助」，并在同一套评估中用别扭的措辞与对抗性压力加以检验。
good ask, plain 0.96
good ask, awkward 0.91
bad ask, plain 0.98
bad ask, jailbreak 0.94
bad ask, prompt inj. 0.92
bad ask, role-play 0.95
保持乐于相助 正确拒绝
监督交接
五个阶段，两个人工触点。
审阅者在执行前看到计划，在执行后看到抽检轨迹。智能体绝不执行任何审阅者未在计划层面批准的事项。
01
agent
plan
structured plan emitted
02
human
reviewer
approve · revise · deny
03
agent
execute
allow-listed tools only
04
human
reviewer
spot-check trace
05
agent
report
full audit trail · signed
公开面
有助益处则公开。构成差异化处则私有。
01 capability-boundary API public with reference runtime
02 audit-stream spec public JSONL · OTel-compatible
03 refusal evaluation harness public paper + scoring code
04 adversarial prompt corpus partial subset under research use
05 internal red-team playbook private differentiating
我们已发表的内容
能力受限智能体的方法、审计流规范，以及拒绝评估。在工作构成差异化之处，我们将底层机制保持私有；在不构成差异化之处，我们将其回馈上游。