--- title: AI 智能体对自己的操作说了“不行”——AI 护栏与三层治理，数据库迁移中被拦截两次的实录 description: 把服务器实机作业交给 AI 智能体后，安全机制（护栏）在执行前两次拦下危险操作。以事前原则×批准关卡×护栏的三层治理与审计日志运维为例剖析。 url: "https://bestnetllc.co.jp/zh-hans/docs/ai-agent-guardrails-three-layer-governance-cn/" updated: "2026-06-27" category: Tech Blog --- # AI 智能体对自己的操作说了“不行”——AI 护栏与三层治理，数据库迁移中被拦截两次的实录 BESTNET TECH BLOG AI 智能体对自己的操作说了“不行” AI 护栏与三层治理 —— 数据库迁移中被拦截两次的实录 作者: Hideyuki Chinda / BESTNET LLC2026-06-13系列 治理番外篇 把服务器上的实际作业交给 AI 编码智能体。让它转换 schema、搭建验证环境、跑测试——这样的用法正在变得现实可行。于是自然会产生这样的担忧：“万一 AI 做了不该做的操作怎么办？” 在本系列正篇中，我们报告了一次实践：在不向 AI 智能体（Claude Code）交出任何实际数据的前提下，将 Oracle 到 SQL Server 的迁移前处理自动化。本文要讲的，是其中发生的一件计划之外的事。**在作业过程中，AI 智能体一侧的安全机制（护栏）在执行前两次拦截了 AI 自身的操作。** 需要说明的是，本文是从“治理的视角”深入剖析这两起事件。它们发生时所处作业的技术幕后（SSH 非交互化、字符编码、PowerShell/T-SQL 接缝处踩过的 10 个坑），我们另作分篇，收录在[技术番外篇《把 Windows 实机作业交给 AI 智能体踩过的 10 个坑》](https://bestnetllc.co.jp/zh-hans/docs/ai-agent-windows-sqlserver-pitfalls-cn/)中。 乍看之下，这像是“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. 三层统制 —— 护栏是最后一道防线，而非根基 ![AI 委托的三层统制模型（第 1 层 事前原则、第 2 层 人类的批准关卡、第 3 层 护栏）](https://bestnetllc.co.jp/wp-content/uploads/2026/06/fig2_three_layer_governance-1.png) AI 委托的三层统制模型（第 1 层 事前原则、第 2 层 人类的批准关卡、第 3 层 护栏） 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](https://bestnetllc.co.jp/zh-hans/docs/oracle19c-sqlserver2022-ai-preprocessing-cn/)中给出了 5 项模板。本文的定位，是在其之上补上第 6 章的“为护栏失灵也能察觉而做的事后审查”。 --- ## 总结 AI 智能体对自己的操作说了两次“不行”，这单独来看，只是一段“便利的安全机制起了作用”的插曲。但重要的是，那个安全机制之所以有意义，是因为它与人类预先划下的红线相一致；而且**那条红线必须由我们自己来划**。 护栏可以成为看门人。但前提是有雇主（事前原则），以及巡查的机制（记录与事后审查）。在把作业交给 AI 的时代，统制既不是“相信聪明的 AI”，也不是“因为危险所以不用”，而是**用三层来设计围护，并让最后一道防线失灵时也能察觉**——这次实践告诉我们的，尽在于此。 BESTNET 合同会社可就 AI 智能体业务应用中的统制设计（信息的边界划分、批准流程、审计日志运维）提供咨询。我们将从“不完全依赖安全机制的围护方式”开始，与您一同设计。