提示注入检测与护栏

自主编码代理会读取任务摆在它面前的任何内容：源文件、网页、问题评论、构建输出。其中每一个都是攻击者可以直接与模型对话的渠道——而模型在设计上会遵循指令。Bromure Agentic Coding 以两种互补的方式守护这条边界，二者都在宿主机上、在 MITM 代理服务器内部强制执行，虚拟机中运行的任何东西——包括已被完全攻陷的代理——都无法将其关闭：

• 提示注入检测使用本地模型在设备上扫描代理的 AI 流量，并在被注入的指令到达模型之前（或到达之时）将其标记出来。
• 护栏对代理向你的基础设施——Kubernetes、AWS、git 托管服务、数据库等——发出的调用进行分类，并对写入和破坏性操作进行阻止或提示，因此即便代理被成功劫持，也无法悄无声息地一路 kubectl delete 穿过生产环境。

本章解释这一威胁、各个检测器、命中时会发生什么、护栏策略引擎及其许可对话框，以及所有这些的实际局限。逐字段的设置参考位于提示注入设置和护栏设置。

攻击：编码代理中的提示注入

提示注入是隐藏在代理读取的内容中的恶意文本，试图操控模型："忽略先前的指令"、"运行此命令并且不要提及它"、"将 ~/.aws/credentials 的内容发送到这个 URL"。对于聊天机器人来说这只是个麻烦；但对于拥有 shell、文件访问权限和凭据的编码代理而言，它就是一个远程代码执行原语。攻击路径很短：

1. 你让代理指向一个你并未编写的代码仓库、问题跟踪器或网页。
2. 代理读取了一个文件（或获取了一个页面，或运行了一个命令），其输出包含被注入的指令。
3. 代理将该内容作为下一次 API 请求的一部分流式回传给模型——而模型可能将攻击者的文本视为指令而非数据。

编码代理还有第二种更为阴险的变体：规则文件后门。Claude Code、Codex 和 Grok 会自动将指令文件——CLAUDE.md、AGENTS.md、GROK.md 及其嵌套和全局变体——作为可信权威加载到系统提示中。克隆仓库中一个被投毒的规则文件根本无需欺骗模型；它被直接交到了对话中权限最高的位置。攻击者惯于用不可见的 Unicode 将这些载荷对人类审查者隐藏起来：零宽字符、双向覆盖字符，以及在编辑器中不显示任何内容却能被正常分词的 Unicode 标签字符。

Bromure 的沙箱已经限制了爆炸半径——代理无法触及你的 Mac，其凭据也是诱饵（参见凭据）。提示注入检测则应对沙箱无法处理的问题：代理本身在其被授予的权限范围之内被反过来对付你的可能性。

Bromure 扫描什么

检测运行在宿主机一侧的代理服务器中，针对代理的出站 AI 流量——即代理发送给 Anthropic、OpenAI 或任何其他模型宿主的请求。由于代理服务器看到的是完整请求，因此无论是哪个代理产生的请求，它都能准确检查模型即将被告知的内容。有两个不同的面被扫描，每个都由各自的检测器负责：

一切都在设备上进行。分类器是通过 Mac 上的 ONNX Runtime 运行的本地 ONNX 模型；没有任何内容被发送到任何云服务进行扫描，而在非托管安装上根本没有任何检测数据离开本机（托管安装可以将检测结果转发给其组织——参见当检测器触发时中的注意事项）。

两个检测器都是编辑工作区窗口的提示注入窗格中的按工作区开关（侧边栏中红色警告三角图标）。二者默认均为关闭——每个在你首次启用时都需要一次相当大的模型下载。

检测器

源代码检测器（PromptGuard）

检测源代码中的提示注入使用本地 PromptGuard 序列分类模型（DeBERTa 系列，ONNX）对代理摄取的 tool_result 内容——文件内容、网页、问题和 PR 正文、命令输出——进行评分。它旨在捕捉经典情形："忽略先前的指令 / 窃取机密"这类文本被植入某个恶意仓库中，等待代理去读取。

一次扫描如何进行：

• 每轮只扫描携带 tool_result 的最新消息。代理会在每次请求时重新发送整个对话历史；重新扫描它只会成倍增加成本却毫无收益，因此已经见过的历史会被跳过。
• 每段最多扫描 16 KB 的内容，最多分为 8 个各 1,536 字符的窗口。各窗口中的最大注入概率即该段的评分；当评分达到阈值（默认 0.5）时，该段被标记。
• 判定结果按内容块缓存（512 项），因此代理重新读取的文件——或在历史中重新发送的相同段——第二次不产生任何成本。

模型的运行参数（最大序列长度 512 个令牌、注入标签索引 1、阈值 0.5）可以通过在模型文件夹中放置一个可选的 bromure-injection.json 来覆盖——参见模型下载与存储。

规则文件检测器（启发式扫描器 + ModernBERT）

检测 CLAUDE.md 等文件中的恶意指令针对的是规则文件后门。它将指令文件从系统提示中提取出来——匹配 Claude Code 的 Contents of <path> (… instructions …): 包装以及众所周知的规则文件名——并对它们运行两遍扫描：

1. 确定性的启发式扫描器（无依赖——即使在下载任何模型之前它也能工作，尽管该开关同时管辖两遍扫描）。它会标记：
   • 系统提示中任何位置的隐藏 Unicode 信号：Unicode 标签字符（U+E0000–E007F）、双向覆盖字符，以及零宽或软连字符字符。这些全部为高严重性——在指令文件中出现它们基本没有任何正当理由。
   • 提取出的指令文件段中的元指令模式："忽略先前的指令"、"不要告诉用户"、"你现在是……"、"新指令："——高严重性。
   • 能力与窃取关键词：凭据文件路径（例如 ~/.ssh 或 .aws/credentials）、.env 引用、curl 管道到 shell、base64 加管道的构造、rm -rf、强制推送、发送到 URL 的模式——中严重性，仅记录为"待审查"发现。
2. 一个经过微调的 ModernBERT ONNX 分类器（claudemd-guard）对同样的指令文件正文运行一遍语义扫描，捕捉那些不匹配任何固定模式的恶意指令。

发现结果按内容哈希在每个会话内去重，因此未更改的 CLAUDE.md 只被记录一次——而不是在会话生命周期内每轮记录一次。

注意： 在询问和阻止强制模式下，只有高严重性的启发式发现（或模型判定）才会触发暂停或阻止。中严重性的"待审查"发现仅作记录，且即便在托管安装上也绝不会转发到 bromure.io。

模型下载与存储

检测器模型从不随应用捆绑——它们是数百兆字节的下载，在你首次启用开关时按检测器从 https://dl.bromure.io/llms/<model-dir>/<file> 获取：

下载流程：

1. 打开某个检测器开关。一个确认警告——下载 <检测器> 检测器模型？——会说明大小："这将从 bromure.io 下载约 <大小>，并占用大致相同的磁盘空间。下载完成后检测器即开始工作。"
2. 点击下载。一个正在下载模型的进度窗口会显示百分比和一个取消按钮。
3. 在下载中途取消——或拒绝该警告，或下载失败——都会还原开关。没有模型的检测器是一个静默的空操作，Bromure 不会假装并非如此。

若干保护措施使下载稳健可靠：

• 可用磁盘预检。 一次注定失败的下载会被预先以严重警告拒绝：磁盘空间不足，无法下载提示注入模型。
• 最小大小下限。 每个文件都有一个大小下限，因此被截断的下载或被保存为 model.onnx 的 HTML 错误页面会大声失败，而不是悄悄禁用检测器。
• 原子化、可续传。 下载按文件原子化进行，重试会跳过已存在且有效的文件。对同一模型的并发下载会被去重。
• 自动恢复。 如果某个工作区启用了检测器，但其模型在应用启动时或在配置保存后缺失，后台下载会自动启动。进度和结果会出现在安全日志中。

要移除某个模型，删除其位于 ~/Library/Application Support/BromureAC/Models/ 下的文件夹。放置在模型文件夹中的可选 bromure-injection.json 会为该检测器覆盖 maxLength、injectionLabelIndex 和 threshold。

注意： 窗格说明中引用的是略小的四舍五入数字（~272 MB 和 ~571 MB）；确认对话框根据实际字节总数计算其大小（~298 MB 和 ~603 MB）。请以对话框为准。

当检测器触发时：记录、询问或阻止

一个共享的按工作区响应——提示注入窗格上的当检测到注入时单选按钮组——同时适用于两个检测器。在至少启用一个检测器之前，该组处于禁用状态。

询问对话框

在询问我如何处理模式下，一个标题为 Possible <detector> in "<workspace>" 的严重对话框会在一个可滚动的等宽文本区域中显示被标记的文本，正文为："Bromure 标记了代理即将发送给模型的内容（来自 <source>）。在下方审查它——放行，还是阻止此请求？"按钮为阻止此请求和允许此请求。

你的决定会在应用本次运行的其余时间内按工作区、来源和内容记住，因此同样被标记的文本不会每轮都重新提示——代理会不断重新发送历史，若没有这种记忆，单个被标记的文件就会打断后续每一个请求。该记忆仅存于内存中；它不会在应用重启后保留。

当工作区通过 SSH 或 CLI 以无头方式驱动时，同样的问题会在工作区的 tmux 内以文本提示形式呈现。只有明确的允许此请求才会放行——不回答即表示阻止。参见远程访问。

请求被阻止时代理看到什么

在单方面阻止模式下——或当你用阻止此请求回应一个询问对话框时——代理会收到 HTTP 451 Unavailable For Legal Reasons，正文为：

Bromure blocked this request: possible <detector> detected in <source>.

模型永远不会收到被投毒的内容；代理看到的是一个干净、可解释、可向你报告的失败。已解决的结果（"允许"或"阻止"）会被记录到安全日志，并在托管安装上作为云事件转发。

注意： 在已注册 bromure.io 的 Mac 上，每次检测都会作为一个 prompt_injection.detection 事件转发，携带检测器、方法、动作、宿主、来源、评分、启发式信号，以及——不同于本地日志的 160 字符预览——完整的被标记片段，上限为 20 KB。这些事件会被工作区的私密模式开关抑制，且绝不会在非托管安装上发送。参见追踪与审计和企业。

观察检测：安全日志

检测、规则文件发现、模型下载进度和强制结果全都出现在安全日志窗口中——打开窗口 → 安全日志…。注入行看起来像这样：

[prompt-injection] source FLAG score=0.973 toolUse=… preview="…"
[prompt-injection] rules FLAG source=/path/CLAUDE.md signals=[zero_width(high)]
[prompt-injection] blocked: rogue instructions in /path/CLAUDE.md → api.anthropic.com

第一种形式是源代码检测器（带有模型的评分和一段简短预览）；第二种是规则文件检测器（带有文件路径和触发的启发式信号，每个都标注了其严重性）；第三种记录一次强制结果。本地日志行只携带被标记内容的 160 字符预览——完整文本只出现在询问对话框中（以及在托管安装上的云事件中）。

窗口本身——一个大约保存最近 5,000 行的内存环形缓冲区，镜像到 stderr，支持过滤和自动滚动——在与其共享该窗口的供应链保护中有详细描述。

护栏

提示注入检测试图捕捉劫持；护栏则限制被劫持（或仅仅过于热心）的代理能做什么。它是一个按工作区、在宿主机上强制执行的策略引擎，将代理向受保护协议发出的每个 API 调用分类为读取、写入或破坏性操作，并对该资源应用工作区的模式。正如窗格所述：护栏从此代理所使用的协议中剥离破坏性操作；它在宿主机上——在代理服务器内部——强制执行，因此虚拟机中行为不端或被攻陷的代理无法绕过它，被阻止的调用会返回一个代理能看到的硬错误。

四种模式

每个受保护的资源都有自己的模式选择器：

新工作区在每个资源上默认为写入前提示。在护栏出现之前创建的工作区——或其 JSON 省略了相关字段的配置——会被解码为关闭。

受保护的资源

护栏覆盖编码代理最常使用的基础设施协议。简而言之（完整的逐协议分类规则——HTTP 动词、AWS 动作名前缀、SQL 关键词解析——在护栏设置中列成表格）：

• Kubernetes——来自工作区 kubeconfig 的 API 服务器。DELETE 为破坏性；GET/HEAD/OPTIONS 为读取；其他动词为写入。被阻止的调用会返回 kubectl 能清晰呈现的 Kubernetes Status 403 JSON。
• AWS——所有 *.amazonaws.com 宿主。动作名（来自 X-Amz-Target 头或 Action= 表单参数）按前缀分类——Delete*、Terminate*、Remove*、Purge*、Destroy*、Deregister*、Revoke* 为破坏性；Get*、List*、Describe* 及类似的为读取——并为 S3 和 REST 风格的请求提供 HTTP 方法回退。被阻止的调用会返回一个 AccessDeniedException 正文。
• DigitalOcean——api.digitalocean.com 和 *.digitalocean.com，按 HTTP 方法分类。
• Docker 注册表——在凭据下配置的注册表加上 Docker Hub。拉取为读取，推送为写入，DELETE 为破坏性；被阻止的调用会返回注册表风格的 DENIED 正文。
• GitHub / GitLab / Bitbucket——REST API 加上通过 HTTPS 的 git。git push（git-receive-pack）算作写入——在只读下被阻止，在写入前提示下被提示——而 git fetch（git-upload-pack）始终为读取。
• HTTPS 数据库——在凭据下配置的每个端点占一行：MongoDB Atlas Data API（find/aggregate 读取，insert/update/replace 写入，deleteOne/deleteMany 破坏性）、ClickHouse（按 SQL 的起始关键词分类）和 Elasticsearch（_search 及其他查询端点即使通过 POST 也是读取；DELETE 和 _delete_by_query 为破坏性）。

Kubernetes 和 Docker 护栏仅适用于从工作区的 kubeconfig 和已配置注册表派生出的宿主，而数据库护栏需要在凭据下设置端点的宿主——一个没有任何可界定范围目标的护栏不会过滤任何东西，遇到这种情况时窗格会内联地警告你。

写入前提示：许可代理

在写入前提示模式下，读取会静默放行，而每次写入都会暂停以弹出一个标题为 Allow write on "<scope>" from workspace "<name>"? 的宿主机对话框。正文逐字显示确切的操作——数据库调用显示字面 SQL 语句，或 REST 调用显示 METHOD /path——因此你批准的是实际将要运行的内容，而非某种转述。四个选择：

授权按工作区和按协议范围界定：一个 Kubernetes API 宿主、整个 AWS、一个 Docker 注册表、每个 git 托管服务整体、一个数据库宿主。在一个宿主上允许 ClickHouse 写入不会在其他任何地方授予任何权限。并发的相同写入会合并到单个对话框，而不是堆叠多个警告。所有决定都仅存于内存中——会话范围的授权（与会话的其他一切一样）会在拆除时被清除。

在无头 SSH/CLI 驱动的工作区上，同样的四个选择会作为 tmux 文本提示提供；不回答即表示拒绝。

注意： 护栏的写入授权不会列在任何窗口中。凭据批准窗口（窗口 → 凭据批准…）只显示凭据许可决定；护栏授权按其自身的计时或在会话拆除时过期，目前没有提前撤销它的 UI。

代理看到什么

被阻止的调用会返回一个协议相应的 403 风格错误正文——一个 Kubernetes Status JSON、一个 AWS AccessDeniedException、一个注册表 DENIED 载荷——其消息以 "blocked by Bromure Guardrails" 结尾。代理得到的是一个干净、普通、它能报告且往往能绕行的 API 失败，而不是一个挂起的连接。提示注入阻止使用 HTTP 451，供应链阻止使用带有各自正文前缀的 HTTP 451，因此这三个系统在日志和代理输出中一目了然、可以区分。

性能与资源使用

• 记录模式是免费的。 在记录但继续下，扫描在响应已经转发给代理之后运行——检测为代理循环增加的延迟为零。
• 询问和阻止模式在转发前扫描。 分类器必须在请求被转发之前完成，因此被标记的轮次会内联地支付推理成本。窗口化上限（16 KB、每段 8 个窗口、仅最新消息）和 512 项的判定缓存使其保持有界。
• 内存。 ONNX Runtime CPU 执行提供程序为默认，在两个模型都加载时使用约 2 GB 常驻内存。CoreML / 神经引擎提供程序可通过环境变量 BROMURE_INJECTION_COREML=1 选择启用——它在相同准确度下将常驻内存大约放大 5 倍（两个模型约 9 GB），因此默认关闭。BROMURE_NO_COREML 即使已设置该选择启用也会强制禁用 CoreML，而 BROMURE_INJECTION_FIXED_SHAPE=1 会将每个分类窗口填充为固定的 512 令牌形状（在 CoreML 选择启用时自动隐含，以避免按形状重新编译；判定结果不变）。
• 调试。 BROMURE_AC_DEBUG=1 会在 stderr 上为分类器和规则扫描器输出详细的按段 ok/score 行以及推理错误。
• 护栏可忽略不计。 分类是对已经流经代理服务器的请求进行字符串匹配；只有许可对话框本身引入一次暂停，而那次暂停正是重点所在。

检测无法捕捉什么

提示注入检测是一个强大的过滤器，而非保证。要了解它的边界：

• 没有模型就没有检测。 在其模型安装之前，检测器是一个静默的空操作。如果开关打开但下载失败（磁盘已满、网络中断），工作区就在无保护状态下运行——失败会被记录到安全日志，磁盘已满状况会弹出一个模态警告，但在此期间没有任何东西会阻止代理。
• 分类器有阈值。 一个足够新颖或微妙的注入可能评分低于 0.5 并通过。反过来，与安全相关的正当文本（例如一个关于提示注入的 README）可能评分高于它——这正是记录但继续为默认、且询问存在的原因。
• 中严重性启发式从不强制执行。 规则文件中的能力关键词（rm -rf、凭据路径、curl 管道到 shell）会被记录以供审查，但不会单独暂停或阻止——它们在正当的开发者文档中太常见了。
• 只扫描 AI 流量。 检测器监视代理发送给模型的内容。模型已经内化的指令会通过普通的工具调用执行；那是护栏这一层，再加上凭据中描述的凭据诱饵和攻陷检测。
• 护栏有传输层盲点。 git 强制推送在传输上与普通推送无法区分，因此阻止破坏性无法阻止它——只有只读和写入前提示才会对推送设卡（通过托管服务 REST API 的显式删除仍会被捕捉）。对于 ClickHouse，一个没有可见 SQL 文本的请求在只读下会被阻止（Bromure 无法证明它是读取），但在阻止破坏性下会通过（它偏向放行）。

纵深防御是所期望的姿态：检测、护栏、诱饵凭据、供应链检查和一次性虚拟机各自弥补其他层的缺口。

配置这些窗格

两个系统都在编辑工作区窗口中按工作区配置：

完整的逐字段参考是提示注入设置和护栏设置。每一次检测和强制结果都可以事后审计——参见追踪与审计。