加密的子代理提示仍需本地审计追踪
摘要
本文认为,虽然加密的子代理提示能保护消息内容,但仍需本地审计追踪,以便调试和重建代理行为。
我在阅读 openai/codex 上关于加密 MultiAgentV2 消息的 issue 时,真正让我担心的并不是加密本身,而是缺少审计日志。如果代理将工作委托给子代理,我关心的不仅仅是最终 diff 能否通过测试。我还想知道子代理实际被要求做什么。没有这一点,调试会很快变得奇怪:是父代理分配错了任务?子代理忽略了任务?还是系统路由正确但隐藏了有用的中间步骤?这些是不同的失败场景。如果唯一可读的输出是最终答案和工具调用,那么你就缺少了解释工作为何偏离方向的关键信息。我理解加密传递的存在理由——在托管系统中保护消息内容确实有实际需求。但对于在我自己的仓库或机器上运行的代理,我仍然希望有一个本地可读的审计副本。它不需要暴露给模型,也不需要发送到其他服务,只需写入某个地方,以便在运行出现异常时我能事后检查。在生产环境中,我认为这比人们意识到的更重要。困难的部分不仅在于为代理授权,更在于能够在它处理了一堆文件后重建发生了什么。
相似文章
当智能体使用人类凭证运行时,如何保留审计跟踪?
讨论了当AI智能体使用人类凭证运行时,维护审计跟踪的挑战,强调了安全和问责问题。
AI代理需要审计追踪而非更多自主性
AI代理需要审计追踪以实现透明度和信任,而非仅仅专注于自主性,用户需要看到代理执行的每一步操作。
坦白说:在实际生产中,你们是如何处理AI代理可审计性问题的?
一位从业者探讨了在生产环境中为AI代理实施审计跟踪的挑战,提及了一项供应商解决方案,并征求社区关于实际部署情况的意见。
提示词是请求,而不是许可。这就是为什么你的智能体仍处于试点阶段。
一篇分析文章,认为提示词级别的护栏之所以失败,是因为它们依赖模型自我监督,而安全检查必须存在于工具边界,并带有可问责的持久审计记录。文章强调,智能体试点停滞的原因在于所有权不明确,而非准确性问题。
当你的子代理调用真实工具时,工具如何知道人类实际授权了什么?
作者正在测试一个原型,该原型在多代理工具执行中提供经过密码学验证的授权证据,询问这是否解决了开发人员的一个重大生产问题。