人类实际使用的界面从未被代理治理——'有人监视'实则非有效控制措施

我运行一个带有治理层的开源代理：一个污染日志记录来自网络的内容，一个数据围栏围绕不受信任的工具输出，危险工具在运行读取外部内容后需要批准，一个具有允许/警告/审查/阻止功能的内核。它为无人值守的路径构建——API、cron、机器人——因为在那里没人能看到模型做什么。交互式界面（终端聊天、全屏TUI、桌面应用聊天）被豁免。书面原因是'有人值守：一个人在键盘旁，看到每个工具调用通过。'上周我进行了测量，而不是仅仅断言。相同的注入语料库，相同的存根工具，0美元。终端路径执行了治理路径阻止的7项攻击中的全部7项，而12项外部读取中，没有一项到达其自身系统提示在每个回合承诺的数据围栏内。第二个数字比看起来更糟：对于被告知'外部内容在这些标记内到达'的模型，没有标记的内容被读作非外部。围栏的缺失并非缺少防御，而是反转的防御。'有人值守'并非一个控制措施，原因有两个我未曾预料：人仅在模型选择命令后才看到它。值守在决策时无所捕捉。在一个跟踪的回合中，人根本没有看到它。TUI的确认提示是在一个以原始模式持有tty的终端应用下的stdin读取，因此问题从未被绘制，调用在123.8秒后超时，然后模型将被拒绝命令的输出叙述为好像它已运行。转录看起来像成功。修复它是容易的部分（交互式界面现在通过与API相同的治理组装构建，TUI通过模态窗口在约5秒内询问）。我不断思考的部分是代价。当防护开启且无人应答时，语料库中8项合法任务中的5项被拒绝，因为每个外部读取都变成一个问题，沉默根据设计是拒绝。有人应答时，0项被拒绝。因此，治理交互式界面的代价不是阻止工作，而是问题——每个网络阅读工作会话中五个问题。我想听听在人类面前运行代理的人的两件事：你是否像治理无头界面一样治理交互式界面，还是也将值守视为控制措施？如果是后者，你怎么知道人真的看到了调用？一个将拒绝工具的输出叙述为真实的模型是我无法通过权限设计消除的失败模式。对我唯一有效的是让拒绝字符串说'工具未运行，不要将其报告为完成'——这是一个提示，而非保证。你们怎么做？数字和方法在仓库的bench目录中；链接在评论中，根据子版块的规则。