把服务器上的实际作业交给 AI 编码智能体。让它转换 schema、搭建验证环境、跑测试——这样的用法正在变得现实可行。于是自然会产生这样的担忧：“万一 AI 做了不该做的操作怎么办？”

在本系列正篇中，我们报告了一次实践：在不向 AI 智能体（Claude Code）交出任何实际数据的前提下，将 Oracle 到 SQL Server 的迁移前处理自动化。本文要讲的，是其中发生的一件计划之外的事。在作业过程中，AI 智能体一侧的安全机制（护栏）在执行前两次拦截了 AI 自身的操作。

需要说明的是，本文是从“治理的视角”深入剖析这两起事件。它们发生时所处作业的技术幕后（SSH 非交互化、字符编码、PowerShell/T-SQL 接缝处踩过的 10 个坑），我们另作分篇，收录在技术番外篇《把 Windows 实机作业交给 AI 智能体踩过的 10 个坑》中。

乍看之下，这像是“AI 不听话”的麻烦。但回头来看，它是一件对思考治理颇具启发的事。我们尽量诚实地从两面来写。先要声明一点：这里触发的，是某个特定 AI 智能体实现所具备的安全判定，并不能保证在其他工具、模型或版本下同样的操作会被拦下（这种非确定性将在第 4 章详述）。

本文涉及的作业对象，是未在互联网上公开的本公司验证专用环境，不包含生产系统或客户环境。

1. 被拦下了两次 #

推进作业的是 AI 智能体。人类（我们）则退到批准方针、进行审查的一侧。而这个 AI 出于效率优先想要打出的招数，有两次都在执行前被挡了下来。

事例1: 削弱安全设置的执行方式 #

为了调查环境，AI 试图以临时削弱执行策略的方式（相当于 PowerShell 中的 -ExecutionPolicy Bypass）来运行调查脚本。尽管目的只是读取，但这是绕过保护机制的操作。

这时护栏将其作为“削弱安全的操作”拒绝了。AI 并没有去寻找绕行办法，而是意识到根本就没有削弱的必要。在目标环境的默认设置（RemoteSigned）下脚本本就可以执行，没有任何理由去动这个策略。结果，AI 切换到更安全的方法继续推进。

事例2: 把认证信息写入文件 #

在自动化产品安装的过程中，AI 起初试图以混合模式认证（使用 sa 账户的方式）安装 SQL Server，并打算把该 sa 的密码直接写进脚本文件再传输。

这一次护栏同样以“认证信息泄露”为由拒绝。这是一个正面违背了人类在作业开始前所定原则——“不要把凭据持久化到代码和文件中”——的操作。AI 随即转变方针，放弃混合模式，改为仅使用 Windows 集成认证的配置（不创建 sa，也不创建其密码）。结果，AI 达成了一种在产出物、脚本、日志的任何地方都不残留机密信息的配置。

两起事件的共同点是：都在执行前被拦下，而且在被拦下之后，都向更安全的配置前进了。

2. 为何能称之为“看门人” #

值得关注的是，这两次拦截都与人类一侧在开头固定下来的原则相一致。

事例2正是“不持久化凭据”这条明文原则本身。事例1也踩在“不要随意削弱保护机制”这条即便不特意写明也作为前提的红线上。

也就是说，护栏并不是作为妨碍作业的障碍物，而是作为人类所定设计原则的“看门人”在发挥作用。而且它不只是单纯地拦下，正是因为被拦下，配置才向安全一侧倾斜。最终，AI 落到了一开始并未选择的、更为牢固的设计——“干脆一开始就不创建机密信息”。

3. 另一种解读 —— 同一件事也是“AI 提出了高风险方案”的证据 #

就此打住的话，这会变成一篇歌颂 AI 护栏的文章。我们诚实地翻到反面。

被拦下两次，意味着即便事先让 AI 读入了原则，AI 仍然两次尝试了违反原则的操作。

这不应被看作个别的设置失误，而应理解为当前 AI 委托中内在的性质。AI 智能体（无论何种模型）都可能出于效率优先而提出违反原则的招数。正因如此，才要在第 1 层（事前原则）划定红线，并在第 3 层（护栏）为漏网之鱼做准备——这次正是按照该设计，越界的尝试在执行前被检测到了。话虽如此，倘若没有护栏，或者换成别的模型、别的版本而判定不同，那个操作或许就那样被执行了。

这种两面性，若只看其中一面就会判断失误。

• 只看乐观一面：“因为有安全机制，所以可以放心交给 AI”→ 对护栏的漏网毫无防备
• 只看悲观一面：“AI 会尝试危险操作，没法用”→ 放弃了只要妥善围护就很有用的工具

成熟的看法，是同时持有两面。AI 可能出于效率优先而提出高风险的招数，所以需要围护。作为围护的最后一层，护栏是有效的，但不能只依赖它。

4. 所以无法“单点依赖” —— 判定取决于模型 #

决定性的一点是，护栏的判定是非确定性的，取决于模型和版本。这次被拦下的操作，换个设置或版本也许就放行了；反过来，并不危险的操作也可能被过度拦截。

这在安全领域是理所当然的原则——不要把统制托付给单一的防御层。护栏是“有它会更安心的最后一道防线”，而不是“因为有它所以别的都不需要”的根基。

那么该依赖什么呢？从这次实践中能够导出的，是把护栏置于第 3 层的三层结构。

5. 三层统制 —— 护栏是最后一道防线，而非根基 #

1. 第 1 层: 事前原则 —— 把“可以交出的信息／不交出的信息”“可以做的操作／不可以做的操作”，作为作业开始前给 AI 的最初指示固定下来。这次的“不持久化凭据”就属于此层。统制的根基不是厂商的安全机制，而是我们自己先划下的红线。
2. 第 2 层: 人类的批准关卡 —— 在前提崩塌的局面或设计判断上，AI 只停留于提出选项，由人类来决定。这次当环境与最初设想出现出入时，也是 AI 给出选项，由人类裁定方针。
3. 第 3 层: 护栏 —— 拦下穿过第 1、2 层的危险操作的最后一道防线。这次正是此层启动了两次。

顺序很重要。只要第 1 层和第 2 层由我们自己设计好，第 3 层就能作为“保险”发挥作用。反过来，若只指望第 3 层，那么在它失灵的那一刻，便什么都不剩了。

6. 最难的是“护栏没有启动的时候” #

说“不依赖第 3 层”很容易，但实务的要害恰在于此。拦下来的时候很好辨认，问题是没拦下来的时候，要如何察觉。

在这次作业中，我们把 AI 的操作、判断、安全机制的启动按时间顺序全部记录进了工作日志。这份日志可以直接成为 AI 使用的审计证据。其粒度的概念大致是“〔时刻〕〔操作类别: 执行／批准／拦截〕〔对象: 变更执行策略〕〔结果: 护栏拒绝〕”这种程度就够了，这样事后便能按各个观点逐一扫查。要点在于，不是“浏览”日志，而是确定观点后进行事后审查。至少，以下 3 个观点应由人类来检查。

• 认证: 有没有涉及凭据的生成、保存、传递的操作
• 权限: 有没有触及权限提升或保护机制的变更（执行策略、防火墙、访问控制）
• 外发: 有没有把数据发往预期之外目的地的操作

只要日志中存在符合这 3 个观点之一的操作，人类就必须确认其执行结果是否违反了原则；若有越界，则一直做到纠正与防止再发（在原则中追加条文）。护栏只有与这套“由人类事后检测并处置”的体制配套，才能作为统制而完整闭环。要把作业交给 AI，前提就是同时备好“交而不撒手”的机制，即记录，以及确定了观点的事后审查。

7. 落实到 AI 使用方针（AI 治理） #

若要把上述内容落实到本公司的 AI 使用准则，关键不只是罗列原则，还要决定“放在哪里、由谁、何时来看”。

• 放置位置: 第 1 层的事前原则不要束之高阁，而要作为给 AI 的“最初的系统提示词／项目规约”，贴在作业的开头。用于盘点的准则，与运行时真正生效的规约，是两回事
• 批准关卡: 把设计判断、前提变更停留在 AI 提出选项的层面，事先界定由人类裁定的局面
• 记录: 把 AI 的操作、判断、安全机制的启动／未启动都纳入记录对象
• 审查负责人与频次: 在每个作业会话结束时，由 1 名非该作业负责人，以“认证、权限、外发”这 3 个观点核查工作日志，并把是否存在相关操作留入记录
• 隔离与最小权限: 切断作业环境通往生产、客户系统的路径，赋予 AI 的权限取最小
• 以非确定性为前提: 以护栏的行为会随模型/版本而变为前提来设计（不做单点依赖）

落成条文文体的“AI 使用准则条文示例”，在正篇的附录 B中给出了 5 项模板。本文的定位，是在其之上补上第 6 章的“为护栏失灵也能察觉而做的事后审查”。

总结 #

AI 智能体对自己的操作说了两次“不行”，这单独来看，只是一段“便利的安全机制起了作用”的插曲。但重要的是，那个安全机制之所以有意义，是因为它与人类预先划下的红线相一致；而且那条红线必须由我们自己来划。

护栏可以成为看门人。但前提是有雇主（事前原则），以及巡查的机制（记录与事后审查）。在把作业交给 AI 的时代，统制既不是“相信聪明的 AI”，也不是“因为危险所以不用”，而是用三层来设计围护，并让最后一道防线失灵时也能察觉——这次实践告诉我们的，尽在于此。