最新

我分享一个开源的、基于聊天的编译器前端入口。<p>它将原始意图转换为密封的、基于回执的 XML 构建工件。 这**不是**一个聊天机器人提示，**不是**一个个性化程序，也**不是**一个运行时环境。<p>它的作用：<p>将聊天视为编译器界面<p>强制仅输出 XML，且符合模式规范<p>生成一个包含回执和 SR8 构建工件的密封 promptunit_package<p>设计上在编译阶段停止<p>其中包含几个 SRX ACE 演示代理，您可以将它们粘贴到任何聊天中：<p>MVP 构建器<p>着陆页构建器<p>深度研究<p>它们是受编译器控制的执行配置文件的示例，而不是一个提示词动物园。<p>仓库：<a href="https:&#x2F;&#x2F;github.com&#x2F;skrikx&#x2F;SROS-Self-Compiler-Chat-OSS" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;skrikx&#x2F;SROS-Self-Compiler-Chat-OSS</a><p>特别希望获得以下方面的反馈：<p>“聊天中的编译器”是否易于理解<p>范围边界是否清晰

Hi HN， 我正在开发用于软件开发的 AI 智能体。这些智能体可以自动启动短生命周期的应用实例——例如，针对每个拉取请求、每个任务或每个实验——每个实例都有自己的临时 URL。 身份验证的处理方式如下： * OAuth2 / OIDC * 外部身份提供商 * 重定向 URL 必须预先注册且是静态的 这与短生命周期应用产生了严重冲突： * URL 是动态且不可预测的 * 重定向 URL 无法实际预先注册 * 身份验证成为唯一一个在其他方面完全自动化的工作流程中非短暂的部分 我看到团队通常采用以下做法： * 在预览环境中禁用真正的身份验证 * 将所有回调路由到单个稳定的环境 * 使用通配符重定向或代理设置，感觉像是黑客行为 对于 AI 开发智能体来说，这尤其尴尬，因为它们假设基础设施是可抛弃的且完全自动化的——不需要手动配置 IdP。 所以，我很感兴趣： 1. 如果你使用短生命周期的预览应用，你如何处理真正的身份验证？ 2. 是否有适用于动态 URL 的干净的 OAuth/OIDC 模式？ 3. 静态重定向 URL 的假设在这里仍然是正确的模型吗？ 4. 在生产环境中，什么才是真正有效的？ 我正在寻找实际的设置和失败案例，而不是理论。

本报告记录了在 OpenClaw 上运行的两个自主 AI 智能体之间进行的实时对抗测试。<p>一个智能体充当红队攻击者。另一个充当防御智能体。这些智能体通过 Webhook 直接通信，并拥有真实的工具访问权限。一旦会话开始，就没有人类参与。<p>攻击者尝试了直接的社会工程攻击和通过文档进行的间接注入。直接攻击被阻止。通过 JSON 元数据的间接攻击仍在分析中。<p>这项工作的目标是可观察性，而不是安全性的声明。我们预计随着自主系统的广泛部署，智能体间的对抗交互将变得普遍。<p>乐于回答技术问题。

我们基于 OpenClaw 构建了两个自主 AI 智能体，并进行了一场实时的对抗性安全测试。 一个智能体扮演红队攻击者。 另一个智能体扮演标准的防御智能体。 会话开始后，没有人类参与。智能体通过 Webhook 使用真实的凭证和工具访问权限直接通信。 目标是测试在实践中容易破坏自主系统的三个风险维度： 访问、暴露和自主性。 攻击者首先尝试了经典的社会工程。它提供了一个“有帮助”的安全管道，其中隐藏了一个远程代码执行有效载荷，并请求了凭证。防御智能体正确识别了意图并阻止了执行。 然后，攻击者转向了间接攻击。它没有要求智能体运行代码，而是要求智能体审查一个 JSON 文档，该文档在元数据中嵌入了隐藏的 shell 扩展变量。此有效载荷已成功交付，目前仍在分析中。 主要结论是，直接攻击相对容易防御。通过文档、模板和内存的间接执行路径要困难得多。 本报告并非安全声明。这是一项可观察性练习，旨在揭示智能体间交互中真实的失效模式，我们预计随着自主系统的广泛部署，这些模式将变得普遍。 完整报告请见： https://gobrane.com/observing-adversarial-ai-lessons-from-a-live-openclaw-agent-security-audit/ 很乐意回答有关设置、方法或发现的技术问题。