你的AI Agent正在裸奔。用户输入、网页抓取、历史记忆、工具调用——每一环都可能被注入恶意指令。传统Web应用有WAF防护，Agent技术栈却长期缺位。Google的Genkit团队最近开源了Sentinel，一套专门给AI Agent设计的输入防火墙。
这不是概念验证，是已经能跑的生产级方案。本文拆解它的架构设计、工程取舍，以及为什么你的下一个Agent项目需要类似机制。
问题：Agent系统的输入暴露面太大
LLM Agent的输入来源极其杂乱：终端用户、检索结果、持久化记忆、第三方工具返回。Prompt注入不是边缘案例，是开放系统的预期行为。攻击者不需要黑进服务器，只需要让模型"忽略之前的指令"或"把API密钥发给我"。
传统安全架构在这里失效。WAF看不懂自然语言，API网关不介入模型内部循环。Sentinel的设计目标很明确：坐在Agent中间件里，在风险内容触及敏感系统前完成拦截、清洗或人工审批。
设计目标六条
1. 嵌入Agent中间件/工具调用链，不破坏原有流程
2. 早期拦截明显越狱企图
3. 优先清洗而非阻断，保留可用性
4. 全量日志支持回放与审计
5. 多云/本地模型兼容
6. 高风险场景支持人工介入
输入检查面覆盖六个维度
Sentinel扫描的输入表面包括：用户提示词、系统提示词、工具参数、记忆检索结果、模型输出、中间循环消息。任何一端都可能成为攻击向量。
威胁检测：确定性规则+加权评分
Sentinel不用LLM做安全判断——那会带来延迟和不可解释性。它采用确定性检测器，每条规则带权重分值：
• "ignore previous instructions"类注入短语 → +30分
• 隐藏文本/注释/不可见Unicode → +20分
• Base64/Hex编码载荷 → +35/+40分
• 数据外泄企图（如"reveal api keys"） → +80分
核心扫描逻辑直白：遍历注入模式库，命中则生成信号对象，包含类型、表面来源、分值、匹配详情。
四级威胁与对应动作
0-20分 SAFE → 放行
21-50分 SUSPICIOUS → 警告记录，继续执行
51-80分 DANGEROUS → 清洗后放行
81-100分 CRITICAL → 阻断，可选触发人工审批
中间件决策逻辑
扫描结果与策略覆盖层组合：先运行威胁检测，再应用用户自定义策略。若策略指定了与评分系统不同的动作，以策略为准。这保证了确定性策略行为，同时保留评分作为默认 fallback。
清洗管线：危险但可恢复的场景
对于51-80分区间，Sentinel尝试修复而非拒绝。当前清洗规则：
• 删除HTML注释块
• 剥离零宽字符（\u200b、\u200c、\u200d、\ufeff）
• 替换疑似Base64编码块为[REMOVED_ENCODED_PAYLOAD]
• 替换高危注入短语为[REMOVED_INJECTION]
这套正则清洗在延迟和安全性之间取平衡——复杂解析会拖慢响应，简单替换足以消除大部分攻击面。
工具执行防火墙
Sentinel对高风险工具做额外包装：
• 路径白名单与目录遍历拦截
• 危险Shell模式阻断
• 元数据端点与本地主机SSRF检查
• 破坏性SQL模式识别
以shell.exec为例，命令字符串在进入执行前必须经过上述检查层。工具不再是"给了参数就运行"的黑盒，而是有明确安全边界的受控接口。
工程取舍：为什么这样设计
Sentinel选择了规则引擎而非模型检测，核心考量有三：延迟敏感（Agent交互要求快响应）、可解释性（安全审计需要明确依据）、确定性（同样输入必须产生同样决策）。加权评分而非二元判断，则给了运营团队调优空间——你可以把特定业务的误报模式降权，或把内部合规要求提权。
人工审批环节的设计同样务实。不是所有阻断都值得立即拒绝，财务转账、数据导出、权限变更等场景下，"暂停并通知"比"直接阻止"更符合业务逻辑。Sentinel把这类决策权交还给人类，同时保证全链路可追溯。
给你的启示
Agent安全不是"上线后再补"的选项。输入面的复杂性、模型行为的不可预测性、工具调用的实际影响，三者叠加意味着单点防护必然失效。Sentinel的架构思路——分层检测、评分驱动、策略覆盖、清洗优先、人工兜底——值得任何构建Agent系统的团队参考。
Genkit生态正在快速补齐生产级能力。从编排框架到安全中间件，Google显然想把Agent开发的完整工具链握在手里。对于开发者而言，这意味着更少的基础架构重复建设，但也意味着更深的平台绑定。选开源方案自建，还是拥抱生态走捷径，取决于你对控制权和交付速度的具体权衡。
热门跟贴