放弃在 Prompt 里死磕，尝试用预先硬化方案解决 Agent 隐私泄露
我最近在研究一套名为 Preemptive Hardening（预先硬化）的防御思路，它的核心逻辑是：不要试图在运行时用过滤器去“堵”漏洞，而是在部署前的 Pipeline 阶段就通过静态分析和代码级补丁把漏洞“封”死。
这套方案最关键的转变在于，它将防御重心从 LLM 的推理侧转移到了工程的定义侧。具体实现可以分为三个阶段。
首先是静态扫描与补丁生成。在 Agent 部署前，系统会扫描所有的 Prompt 模板、工具接口定义（Tool Schema）以及调用代码。它寻找的是那些导致泄露的潜在模式。例如，如果一个 Tool 的参数定义过于宽泛（比如使用了泛型 String 而没有具体的格式约束），或者在处理外部输入时缺乏边界清洗，这些都会被标记为高风险点。
其次是实施真正的“硬化”手段。这里不再依赖提示词，而是直接在代码层面打补丁。最有效的手段包括：
1. Schema Tightening（模式收紧）：强制收紧接口定义，限制 LLM 能够传递的参数范围，从物理上杜绝乱传参数的可能性。
2. Boundary Sanitization（边界清洗）：在数据进入 LLM 或从 LLM 返回给工具之前，强制执行边界清洗，剔除潜在的指令注入字符。
3. Allowlist Gating（白名单准入）：建立严格的工具准入机制，只有在特定上下文下被授权的工具才能被唤醒，而非全部暴露给 LLM。
4. Least-Privilege Checks（最小权限检查）：遵循最小权限原则，给 Agent 分配的 API Key 或数据库权限仅限于完成当前任务所需的最小集。
最后是对抗性验证。硬化完成后，系统会自动生成一批类似 Jailbreak（越狱）或指令覆盖的攻击输入。通过模拟真实攻击，验证补丁是否生效，同时确保正常业务流程没有被误杀。
这种实战导向的防御效果远超单纯的提示词约束。在 AgentDojo 等基准测试中，这套流程展现出了极强的鲁棒性，能够将基础的越狱泄露率直接降低至 0；即便是在高压操纵的复杂环境下，依然能降低 91% 的数据泄露概率。
对于目前深耕 AI Agent 工作流的工程师来说，这个经验非常重要：LLM 的不确定性决定了你不能完全信任它的“自觉”。与其在 Prompt 里写废话，不如在接口定义和代码权限上做文章，把防御逻辑下沉到确定性的工程层。
