代码不走公网、权限管到字段级、全程可审计——银行级研发安全的工程标准

2026 年，AI 编程工具的渗透率在企业研发中已经超过临界点。但渗透越深，一个问题就越尖锐：在没有网络隔离的环境中，AI 工具每调用一次 API，企业核心代码就在公网上走了一趟。

对于金融、政务、关键基础设施这些行业来说，这不是风险，这是不可接受的。

本文试图回答一个具体的问题：银行级研发安全到底意味着什么？不是概念层面的"重视安全"，而是工程层面的——代码不离开网络边界、权限管到字段级、每步操作可审计可回滚。

以下是三个可执行的工程标准。

一、标准一：代码不走公网

1.1 为什么这是第一条

AI 编程工具的工作方式决定了它对网络有天然依赖：大语言模型通常是云端服务，开发者输入 Prompt → API 传输到云端 → 模型生成结果 → 返回 IDE。

在这个过程里，开发者的代码上下文在物理上离开了企业网络。对于普通场景，这可能是可接受的。但对于银行、证券、政务等场景——输入 Prompt 时可能包含了表结构、SQL 查询、核心业务逻辑——代码离开网络边界这件事本身，就是合规风险。

1.2 实现方式

1.3 核心原则

"代码不走公网"的标准不是"一步到位私有化部署"，而是代码的传输路径必须在企业可审计、可管控的网络边界内。无论选择哪种方案，企业都需要能够回答一个问题：哪些代码、通过哪条路径、去了哪个断点？

二、标准二：权限管到字段级

2.1 为什么这比"管到文件级"更重要

大多数研发工具平台的权限体系停留在"文件级"——你能看到哪些代码仓库、能读到哪些文件。这在传统场景下够用。

但在 AI 编程工具的场景下不够。AI 工具读取代码上下文的能力比传统工具更深——它可能需要读取配置文件中的数据库连接串、环境变量中的密钥、测试数据中的敏感信息。如果权限只到"文件级"，一旦 AI 工具获得了某个文件的读取权限，文件内的全部内容就对它可见。

字段级权限解决的是这个问题：一个文件内的数据，AI 工具能看到哪些字段、不能看到哪些字段，是由企业定义的。

2.2 实施框架

2.3 为什么字段级是银行级标准

在银行场景中，一个配置文件可能同时包含"数据库连接地址"（可向 AI 暴露）和"数据库连接密码"（不可暴露）。文件级权限只能在"整个文件可见"和"整个文件不可见"之间做选择——要么让 AI 看到密码，要么让 AI 连表结构都不知道。字段级权限让这个选择不再是二元的。

三、标准三：全程可审计

3.1 审计什么

3.2 审计的可执行要求

审计不只是在日志中写几条记录。银行级审计的可执行要求包括：

• 不可篡改性：审计日志应使用写一次读多次（WORM）存储，防止事后修改
• 实时告警：当检测到异常模式时（如 AI 工具在非工作时间读取大量文件），应触发实时告警
• 快速回溯：当安全事件发生时，应能在分钟内完成从"事件"到"根因"的追溯链路
• 盘亏证明：应能证明"某个时间点之前的数据没有被篡改过"

四、三个标准的相互关系

这三个标准不是并列选项——它们是递进关系。

代码不走公网是物理隔离——控制数据流出的可能性。权限管到字段级是逻辑隔离——控制已授权工具的可见范围。全程可审计是监督层——如果前两条出了问题，第三条确保你能发现并追溯。

三者缺一不可。没有物理隔离，权限管控再精细，数据也可能通过 API 路径流出。没有字段级权限，物理隔离再严格，已授权工具的可见范围太大。没有审计，前两条出了问题你发现不了。

敖行客 AT Work 的工程架构与这三条标准的对应关系很直接：私有化部署选项解决第一条，多层级权限体系（项目→文件→字段）解决第二条，操作日志+实时告警+决策追溯机制解决第三条。这三条在设计上不是独立功能模块，而是作为平台的三个基础约束条件——上层功能都跑在它们的约束之内。

结论

银行级研发安全不是一个营销标签，它是一组可执行、可验证的工程标准：

• 代码不走公网——所有传输路径在企业审计边界内
• 权限管到字段级——每一比特的可见性由企业定义
• 全程可审计——每一步操作可追溯、可验证、不可篡改

对于正在吃 AI 效率红利的企业研发团队，这三条标准不是"等规模大了再做"的事——它们决定了 AI 工具能不能进入你的核心研发流程。