北京
一个AI驱动的Terraform审查代理，在CI流水线中明明已经拒绝了存在风险的变更，但大模型却依然被调用了。这不是流程设计上的小瑕疵，而是安全边界控制中的一个关键盲区。
我最近构建了一个结合Terrascan、GitHub Actions、AWS Lambda和Gemini的AI Terraform审查代理。工作流程本身并不复杂：Terraform拉取请求触发GitHub Actions，生成Terrascan JSON报告，再由AWS Lambda调用Gemini进行审查，最终输出APPROVE、APPROVE_WITH_CHANGES或REJECT三种结论。当模型返回REJECT时，GitHub Actions工作流会以状态码1退出，从而阻止拉取请求合并。
从表面看，这套流程运转正常——有风险的变更确实被拒绝了，PR也确实被拦截了。但当我仔细审视执行路径时，发现了一个重要问题：最终结论的正确，并不能证明控制措施在正确的边界上得到了执行。
问题出在权威归属上
在最初的Lambda实现中，执行序列实际上是：先提取Terrascan的相关发现，构建提示词，然后调用Gemini，最后从AI回复中解析出结论。风险阈值被写在了提示词里，而不是在调用模型之前作为确定性控制被评估。
这意味着，流水线虽然拒绝了变更，但大模型已经运行过了。在DevOps语境下，一个写着“不要继续”的策略，应该阻止下一步动作的发生，而不是仅仅让下一步动作同意“这个请求本应被阻止”。这两者有着本质区别。
这种设计带来了三个层面的隐患。最容易被普通CI输出掩盖的，是第三个问题：测试断言无法区分两种执行路径。假设一个测试夹具包含一个HIGH严重级别的公共访问违规，常规测试可能会断言结果为REJECT。但这个断言无论流水线是在调用Gemini之前就拒绝，还是调用了Gemini然后接受其拒绝结论，都能通过。
两条路径并不等价
期望的路径是：Terrascan扫描后，由确定性策略直接判定REJECT并停止。而原始实现的实际路径是：Terrascan扫描后，先调用Gemini，解析其响应，然后才得到REJECT并停止。前者是策略前置，后者是策略后置——后者的安全边界依赖于模型判断的可靠性，而非确定性规则。
为了把这条路径变得可见，并为其添加一个确定性的CI契约，我使用了AgentInspect工具。需要说明的是，我是在上述工作流中独立测试AgentInspect的，维护者审阅了AgentInspect命令的技术准确性，但结论由我自己负责。AgentInspect并没有替代Terrascan、GitHub Actions、AWS控制或应用的安全策略。
这个案例揭示了一个容易被忽视的工程原则：在AI驱动的自动化流程中，控制点的位置比最终结果更重要。一个正确的结论，如果是在错误的边界上得出的，那么它提供的安全感本身就是一种风险。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
