AI Agent护栏要守住工具边界
很多团队给 AI Agent 加了“护栏”，实际只检查用户提示和模型回答。但危险动作常发生在中间——模型已经决定调哪个工具、传什么参数，或者工具把外部数据带回来时。

【来源事实】AWS 8 月 27 日发布的技术文章指出，常规模型级 Bedrock Guardrails 会在推理前检查提示、推理后检查回答，但工具和 MCP 边界上的数据不一定经过这两处检查。文章用 Strands Agents SDK 的生命周期 Hook，把检查补到三个位置：

① 进上下文前：`BeforeInvocationEvent`
检查来自用户、其他 Agent、MCP、RAG 的输入。命中策略的内容不进入上下文，也不触发执行。

② 真正调工具前：`BeforeToolCallEvent`
模型生成参数后、工具执行前再检查。“发邮件”“改数据库”“调用支付”等动作可在产生副作用前取消；还能按 `tool_names` 配置不同规则。

③ 工具结果返回后：`AfterToolCallEvent`
外部 API、数据库或网页返回的内容，在交给用户或下游 Agent 前再检查；违规输出可替换成阻断消息。

【专家判断】落地时可记成“三道闸门＋一层底座”：入口做完整策略检查；动作前用 JSON Schema、正则、允许列表和工具专属规则做快速校验；结果出口重点拦截敏感信息与提示注入。底座仍要保留最小权限、审计日志，以及删除、转账、外发等高影响动作的人工确认。

上线检查单：
□ 未经检查的数据会不会进入上下文？
□ 工具参数是否在执行前校验类型、范围和权限？
□ 外部返回是否可能夹带敏感数据或恶意指令？
□ 阻断后是否留下可追踪记录，而不是静默失败？
□ 高风险动作是否需要二次确认？

需要注意：这篇文章是架构教程，不是安全效果评测；它没有给出延迟、误报率、漏报率或事故下降数据，示例工具也是占位实现。因此它证明的是“可以把检查点插到工具边界”，不是“部署后就一定安全”。

一手 智能体 MCP 工具调用