解决“有用但不安全”的困境:非隔离代理的一次性管理员审批

Reddit r/AI_Agents 工具

摘要

本文介绍了 prompt2bot 中针对非隔离 AI 代理的一次性管理员审批机制,通过要求管理员确认执行敏感工具(如创建虚拟机或执行代码)来防止 prompt 注入攻击。

大家好,如果你正在构建个人助手或编码器/集成代理,且禁用了用户隔离(以便代理可以在多个参与者之间协调或处理共享工作流),你会遇到一个难以突破的安全天花板。具体来说,如果你的代理连接到了公共频道,比如 WhatsApp 或 Telegram 号码(或共享群聊),任何参与者都可以向它发送消息。如果该代理拥有创建真实虚拟机、运行代码或获取 OAuth 令牌的工具,它极易受到 prompt 注入攻击。恶意用户或巧妙的提示可以轻易诱骗你的助手使用你的秘密执行代码、启动昂贵的云计算资源或泄露 API 密钥。为了解决这个问题,我们在 prompt2bot 中设计了一种安全、无重复的审批机制。以下是具体流程: 1. **执行拦截**:当非管理员用户触发敏感工具(例如创建虚拟机、执行带有映射秘密值的自定义代码/Safescript,或请求 OAuth 回调)时,工具执行立即暂停。代理会回复用户,告知已请求管理员权限。 2. **一次性令牌与 TTL**:服务器在 Deno KV 中注册一个待审批请求,包含一个安全的、不可猜测的 UUID 和严格限制的 10 分钟过期时间。 3. **一次性链接通知**:一个安全的审批链接会立即通过 WhatsApp 或电子邮件(取决于可用方式)发送给机器人配置的管理员。 4. **上下文注入**:当管理员点击审批链接时,他们会看到一个成功页面。在后台,服务器直接将一条包含 requestId 的内部系统思考注入到对话历史中。 5. **重新运行与消费**:这会自动触发代理的安全重新运行。代理读取系统思考,重新调用工具并传递已审批的 requestId,该 ID 被验证并消费(一次性使用),然后继续执行任务。 如果机器人所有者是尚未配置邮箱/电话的访客用户,系统会自动跳过检查,以保持其开发者测试流程完全无摩擦。很想知道其他人是如何在多用户/非隔离场景中处理敏感工具的人工审批的。
查看原文

相似文章

谁授予了你的AI代理权限?

Reddit r/AI_Agents

讨论AI代理工作流中的安全漏洞,即代理在关键步骤中假设存在人类监督,并提出了一个运行时控制平面,用于强制执行权限,并在破坏性操作前要求人工批准,通过Tandem演示进行了说明。

为什么AI代理需要两层架构

Reddit r/AI_Agents

本文讨论了在单一服务器上运行具有工具执行能力的AI代理的安全风险,并提出了一种两层架构,将提示评估与代码执行分离,以减轻提示注入和恶意代码攻击。