财务团队如何部署 AI 构建的应用而不泄露财务数据

安全公司 RedAccess 搜寻使用 AI 编程工具构建并发布在这些工具自有托管平台上的应用时，发现超过 5,000 个应用几乎没有安全措施或身份验证。它向 Wired 分享的截图中包括“来自多家其他公司的各类销售和财务记录”。财务团队的 AI 构建应用也可能落在同样开放的网址上，把总账、工资和未公布的业绩暴露出来。

Replit 首席执行官 Amjad Masad 回应说：“公开应用可以在互联网上访问，这是预期行为。”就机制而言，他说得对。我认为，这次暴露源于可见性设置和遗漏的审查，而构建工具的人有能力处理这两点。

TL;DR（太长不看版）

• AI 构建的财务工具可能通过六种部署错误泄露数据，构建者都能着手处理：公开链接、留在代码或聊天历史中的密码和密钥、数据库管理员权限、没有第二位审批人的记账操作、发送到外部服务的数据，以及无人记录的计算变更。
• 每种错误都有修复方法，多数可通过构建应用的同一 AI 工具实施，还有能验证修复生效的明确检查，例如数据库拒绝写入，或旧密码不再有效。
• 财务工具默认留在私有网络；财务部门以外的人需要访问时，再加入公司统一登录。如果它无需第二位审批人就能记入总账、接触银行卡数据，或向 SOX 范围内的财务报表提供数字，就交给 IT。
• 服务器区域决定应用的 VPS 主存储在哪里，但备份、日志和第三方服务可能在其他地方生成副本；整体部署是否合规是另一个问题。请把所在地区的框架交给合规团队核查。

泄露财务数据的部署错误

AI 构建的财务工具可能因六种部署错误泄露数据：使用公开链接、把凭据留在代码或聊天中、只需读取却用管理员权限连接、没有第二位审批人就记账、向外部服务发送财务数据，以及修改计算却没有记录。这些都是演示阶段容易受到鼓励的默认做法。

以下每项修复都附有供构建应用的 AI 工具使用的提示词；粘贴前请修改方括号字段。这些提示词是为本文编写、未经测试的起点，AI 工具声称完成修改并不能证明什么。每段提示词后的检查才是证据。请针对代码以及样本或合成数据运行提示词，绝不要把真实记录或有效密钥粘贴进聊天。

把工具留在 AI 构建平台的公开链接上

如果现金预测仪表盘在 AI 构建平台上公开托管，任何知道地址的人都能打开它，看到应付账款账龄、预算与实际对比，以及尚未公布的季度业绩。Wired 关于 RedAccess 调查结果的报道说明，研究人员通过 Google 和 Bing 对 AI 供应商域名进行简单搜索，就能找到这些应用。

其中一些应用只要求访问者用任意邮箱登录。接受任意邮箱的登录不是访问控制。

把真实数据移出供应商托管平台。在工具迁移到你控制的服务器之前（下一节会说明部署位置），只使用合成数据、ERP 沙箱或测试公司（如果有）进行开发和演示，绝不要使用真实导出。修改后重新部署，因为托管地址提供的是最后一次部署的版本。

为此应用创建与它读取的表和列相匹配的合成数据集：[列出表和列，例如 vendors、invoices、journal_lines]。

使用虚构的供应商和客户名称、虚构的银行账号，以及以[币种]表示、符合真实账簿逻辑的金额：每笔分录借贷平衡，明细账总额与[应付 / 应收统驭科目]一致。

让应用连接此数据集，而不是任何真实导出，并列出修改的每个文件或设置。

不要向我索要真实记录。

确认生效：在退出登录的浏览器中打开供应商托管地址，或请财务部门以外的同事打开，确认只显示合成数据、登录界面或空白。然后选取真实 ERP 中的三个供应商或客户名称，搜索应用数据文件和代码仓库，应无匹配。最后运行应用的试算平衡或汇总视图，确认借方合计等于贷方合计。

把 ERP、银行数据源和数据库凭据留在代码或聊天中

如果有效凭据存在那里，能读取聊天历史、仓库或 MCP 配置文件的人，也可能用它访问 ERP、财务数据库或银行数据集成。MCP 是让 Claude 等 AI 工具直接连接 ERP 或数据库的连接机制，其配置文件也是可能存放密码的地方。

GitGuardian 的《State of Secrets Sprawl 2026》在 MCP 配置文件中发现了 24,008 个暴露的唯一秘密，其中 14% 是 PostgreSQL 数据库连接字符串。同一报告在公开 GitHub 提交中发现，Claude Code 联名提交的秘密泄露率约为基线的两倍，同时指出人为因素仍然至关重要。

删除聊天消息不能撤销暴露：拥有聊天、仓库或历史副本的人仍然持有那个值。对于曾出现在这些地方的每个密码、密钥或令牌，都应在 ERP、数据库或银行数据提供商的管理控制台签发新凭据并禁用旧凭据。这就是凭据轮换。

随后，应用在启动时从环境变量读取凭据。环境变量是保存在代码之外的命名设置，由部署层——在服务器上构建并运行应用的工具——提供。当多个工具共享秘密、需要集中轮换时，可进一步使用 HashiCorp Vault。

团队成员自己的密码副本应存放在面向人的密码管理器中，例如 Vaultwarden；运行中的应用从环境读取值。先找出 AI 生成代码中的所有硬编码秘密。

审查此项目中的硬编码秘密。找出每个密码、API 密钥、访问令牌和连接字符串，包括 .env 文件、笔记本、MCP 配置文件，以及连接[ERP 名称 / 银行数据提供商 / 财务数据库]的代码。

把代码中的每个值替换为命名环境变量，并给出变量名称列表。

确保包含真实值的文件没有提交到仓库，并列出仓库历史中出现这些值的每个提交。

只显示位置。不要打印任何秘密值。

确认生效：自行尝试旧密码或令牌，或请 IT 尝试，应被拒绝。然后在当前项目文件中搜索旧值，应无结果。只有确认历史中的值已撤销或过期，才能确定它不再提供访问权限。

工具只需读取，却使用构建者的管理员账号连接

显示应收账款账龄的仪表盘不应能修改总账。如果工具使用构建者的管理员账号，就会继承该账号的权限。Supabase 秘密密钥或旧版 service_role 密钥具有较高的数据权限，并绕过 Row Level Security，因此不应用于普通只读访问。原本只为一个账龄报表构建的工具，可能暴露整个总账，包括工资表。

写入能力会让问题变得昂贵。Symbiotic Security 对 1,072 个 AI 构建应用的扫描针对使用 Supabase 的应用发现，172 个允许任何人在未认证时删除记录，172 个允许任何人修改现有记录，39 个的表可被持有公钥的任何人完整读取。

给工具一个仅限所需表的只读凭据。在 ERP 或数据库中，创建专用集成用户：为工具单独创建账号，只能读取报表所需对象。在 Supabase 中，对工具使用的每个暴露表启用 Row Level Security——决定每次请求可以看到哪些行的数据库规则——并检查表权限：它们决定角色能否 select、insert、update 或 delete。只读财务应用的角色不应拥有不需要的写入操作。正确配置 RLS 和最小权限后，可发布密钥可以出现在浏览器代码中。秘密密钥和旧版 service_role 密钥必须留在服务器端，只用于确实需要高权限并自行执行授权的后端任务。

注意：Supabase 可发布密钥或旧版 anon 密钥出现在页面 JavaScript 中是正常的。Supabase 的 API 密钥文档说明，它只能访问 Row Level Security 允许的数据。秘密密钥绕过 Row Level Security，因此绝不能出现在发送给浏览器的任何内容中。

按表或对象分组，列出此应用对[ERP 或数据库名称]进行的每次读取和写入。

修改应用，使它只读取[所需的表]，并通过环境变量提供的独立只读凭据连接，绝不使用我的个人登录。

如果应用使用 Supabase：对它接触的每个暴露表启用 Row Level Security。列出 anon 和 authenticated 的 select、insert、update、delete 权限。为此只读应用移除不需要的写权限；如果其他生产应用依赖某权限，先标记，不要修改。然后编写策略，让未登录者无法读取，已登录者只能读取[规则，例如自己成本中心的行]，并确认发往浏览器的文件中没有秘密密钥或旧版 service_role 密钥。

列出创建的策略。

确认生效：使用工具凭据尝试一次写入，例如编辑测试记录，应被拒绝。对 Supabase，在未登录状态请求财务表的行，应得到空结果或错误。

让工具无需第二位审批人就记入总账

直接记账的分录导入器，或直接向银行发送文件的付款文件生成器，会让操作人同时成为编制者和审批者。一个错误可能重复整个月的应计分录；一个字段改动可能把供应商付款发到错误账号。财务不允许两个人之间破坏职责分离，AI 助手构建的软件也不例外。

损害不会止于应用。错误批次进入账簿后，撤销需要更正分录和结账时的解释；当工具以构建者的账号记账，每笔重复分录都带有构建者的名字。

AI 构建工具只负责读取和准备；记账和付款放行必须通过 ERP 自有审批流程，由工具操作人以外的人批准。我参与过的每个会计引擎都把分录和审批视为两个事件，分别有负责人，AI 构建工具也应如此。

把每次直接记账改为草稿分录或暂存导入，在 ERP 内等待批准。工具仍负责映射、验证和生成批次等繁琐工作，审批则留在 ERP，与结账依赖的其他审批一起。如果 ERP 没有导入审批步骤，工具应输出文件，由第二个人对照批次汇总审查后自行导入。

必须自动记账、生成付款文件或修改供应商银行资料的工具，应按下一节的条件交给 IT。

列出此应用在[ERP 名称]中创建、编辑或记入[分录 / 账单 / 付款]的所有位置。

逐一修改，使应用生成草稿分录或暂存导入，在[ERP 名称]批准后才记账。如果该 ERP 没有导入审批步骤，改为生成导入文件，不要记账。

移除任何未经上述批准就记账或放行付款的代码路径。

为每个批次生成包含行数、借方合计和贷方合计的汇总。

列出仍会直接记账的部分，供我审查。

确认生效：用样本数据运行一个批次。在第二位用户于 ERP 批准前，不应出现已记账记录。再将批次汇总与 ERP 中该批次的数据比较：行数、借方合计、贷方合计必须完全一致。相差一行就是对账失败，不是舍入问题。

向你无法控制的服务发送财务数据

把完整总账导出发送到 AI API 的差异说明功能，会把每一行交给第三方。还有两条更隐蔽的路径：页面分析脚本向供应商报告每次访问；错误跟踪器或日志保存完整请求体，工资明细、客户银行资料和未发布数字可能进入其中。

对于财务团队构建的内部工具，除非组织的供应商、安全和合规流程明确批准服务和具体数据流，否则不要把未发布业绩和工资发送给第三方。其他数据也应列出所有目的地，每次调用只发送必需字段。外部服务是否存储数据或用于训练，应由签署供应商协议的人根据该供应商条款核查。如果团队想知道工具使用频率，Umami 这样的自托管分析工具可以把页面访问记录留在自己的服务器上。

列出应用向[我们的服务器]之外发送数据的所有位置，包括 AI API、分析脚本、错误跟踪、邮件、webhook 和日志文件。

逐个目的地列出它收到的确切字段。

标记所有含有[工资金额 / 银行账号 / 未发布业绩 / 客户名称]的项目。

对每个标记项，展示如何减少发送字段或完全不发送，只有我确认后才实施修改。

确认生效：使用包含可识别虚构账号和虚构工资金额的样本数据，每项功能触发一次。在错误跟踪器和日志中搜索这两个值，应无结果。对于 AI API，在该次样本运行中让应用记录出站请求体，并搜索相同两个值；二者都不应出现，且只能包含你批准的字段。之后关闭该日志记录。

修改计算，却没有记录和对账

在应计计算器或收入瀑布验证器中，代码就是控制。改动一个公式，进入结账的数字就会变化；没有版本控制，没人能说清谁在何时改了什么。

在一家 CPA 事务所的 r/ClaudeAI 帖子中，该事务所讨论了用 Claude Code 构建的内部工具，一位评论者直言其局限：“‘会计师 + claude code’可以工作，直到遇上审计轨迹要求。那才是真正的上限。”

修改前先锁定当前行为。输出固定后，逻辑可以改进，而总额不会悄悄漂移。将代码纳入版本控制，记录每次变更的作者和日期。

编写测试，在固定样本文件上运行工具，将结果与已记录基线比较，让每次变更发布前必须通过对账。固定测试会保护它记录的所有内容，包括错误，所以信任基线前，应先把基线总额与 ERP 同期总额核对。

任何计算逻辑变更都要求第二个人审查，每次生产运行都与 ERP 自身总额对账。

如果项目尚未使用版本控制，请加入，并列出包含计算逻辑的文件。

编写测试，在[样本文件]上运行应用，记录今天的输出：按[科目 / 实体 / 期间]统计行数和总额。

保存记录输出前，先向我展示总额，让我与[ERP 名称]的[期间]数据对账。

任何改变上述总额的修改，都必须使测试失败。

编写测试时不要修改计算逻辑。

确认生效：故意修改一次计算，例如舍入规则，确认测试失败。撤销修改，再确认所有测试通过。

默认私有，需要更多人访问时用公司登录，总账工具交给 IT

真实财务数据绝不留在 AI 工具的托管平台。要安全部署仅供财务团队使用的 AI 构建应用，就放到你控制、只能通过私有网络访问的服务器上。其他团队需要时加入公司登录；下列任一条件成立时交给 IT。

VPS 是租用的虚拟服务器，你控制其操作系统和软件栈。私有网络（Tailscale 称为 tailnet）把批准的设备连接到该服务器。要让工具脱离公开互联网，仍需阻止应用的公网入站访问，例如使用服务器防火墙，并只在 VPN 或 tailnet 接口提供访问。身份提供商管理公司用户账号；反向代理位于应用前方，让每次请求先通过登录。

AI 工具自有托管不在表内，原因见第一项错误。Northflank 这样的企业部署平台也不在表内，它适合已为平台供应商及其审查流程预留预算的大型组织。对只有少量用户的部门工具而言，这套合同安排超过需求。

根据我的经验，Tailscale 是两种私有网络方案中更快部署的一种，但Tailscale 自行托管协调服务。WireGuard 才是完全自托管的选项。

我默认选择私有网络的理由是：工具不回应互联网请求，就无法被搜索找到或在登录页遭受攻击；AI 写的登录页，其保障取决于背后的 AI 代码。若必须把应用暴露到私有网络之外，公司登录能在前方增加受管理的认证层，因此排在第二层。

预算负责人需要访问时，把工具自有登录替换成公司登录，也称单点登录（SSO）：使用既有公司账号，禁用账号就阻止新登录；配置会话撤销、后通道登出或足够短的会话期限，避免现有会话长期保留。提示词使用 OIDC，这是 Authentik 和 Keycloak 都支持的标准登录协议。

使用 OIDC，通过[Authentik / Keycloak / 我们的身份提供商]把应用自有登录替换为公司登录。

从登录信息读取每个用户所属的组。

只允许[组名]成员访问[工资页面]，并在服务器端对每个页面、导出和 API 端点强制执行，而不只是隐藏菜单。

拒绝任何没有有效登录的请求。

确认生效：用不属于该组的测试账号登录，直接请求受限页面及其导出或 API 地址，两者都应拒绝。然后在身份提供商禁用测试账号，确认无法开始新会话。也要确认现有会话被撤销，或在配置的时限内过期。

有些工具根本不应继续由团队独立维护。下列任一情况成立时，交给 IT 或工程团队：

1. 没有人在 ERP 批准，就向总账或其他权威记录系统记账。
2. 生成付款文件、放行付款或修改供应商银行资料。
3. 输出进入 SEC 注册公司的财务报表，可能使工具属于财务报告内部控制（ICFR）。在用于结账前向内部审计提出；对受 SOX 第 404(b) 条约束的发行人，外部审计师也可能测试相关控制。
4. 存储、处理或传输支付卡数据。
5. 评估个人信用状况。
6. 团队中无人负责补丁、访问审查和退役。

第六项比表面看起来更重要。自托管意味着你负责更新、备份和监控，无人维护的财务工具交给 IT 更安全。IT 可能较慢，这是这些条件所需治理的代价。

第一、第二层在任何人打开工具前，都必须具备服务器、部署层、私有网络；第二层还需要身份提供商。没有工程师的财务团队必须自行搭建。我们的 Linux VPS 提供 root 权限。Coolify 和 WireGuard 可一键部署；Tailscale 使用官方单命令安装器安装，Authentik 使用官方 Docker Compose 栈运行。团队可把时间用于上述修复，而非从零搭建部署栈。我们的地点包括欧盟的法兰克福和阿姆斯特丹、英国伦敦以及美国多个城市，可选择应用 VPS 主存储的区域；该选择是否可接受，仍由合规团队判断。

按地区与合规团队核查的规则

适用框架取决于工具接触什么，以及公司和数据主体在哪里。保存欧盟员工工资的表，与进入美国上市公司财务报表的收入明细，可能受不同框架约束。

本文不是法律建议。下表列出应向合规团队提出的框架，不判断其中任何框架是否适用于你。

SOX 一行中的 AS 2201 是 Sarbanes-Oxley 第 404(b) 条所涉及的审计师鉴证 PCAOB 标准。它将期末财务报告流程中的分录和调整控制，列为审计师应对舞弊风险时评估的控制。其他地区请先查本国数据保护监管机构的网站。服务器所在地决定主存储位置，却不能说明每个备份、日志或第三方副本在哪里，也不能仅凭所在地满足上述任一框架。

常见问题

Vibe coding 对财务工具安全吗？

补齐演示遗留的缺口后可以安全使用；我认为证据更指向部署问题，而非编码问题。财务工具比个人项目风险更高，因为它读取 ERP 且可能写入账簿。一旦无需第二位审批人就记账、处理付款或接触卡数据，就应交给 IT。

财务领域的影子 AI 是什么？

影子 AI 是指在 IT 不知情或未批准时，使用公司数据的 AI 工具或 AI 构建应用，例如 IT 从未见过的 ERP 连接预测仪表盘。IBM 的《2025 Cost of a Data Breach Report》发现，高水平使用影子 AI 的组织，平均数据泄露成本比低水平或没有使用的组织高 670,000 美元，见IBM 的公告。

应向内部审计或外部审计师展示什么？

在工具用于结账前准备四项内容：运行位置和可访问人员、包含固定输出测试的变更历史、ERP 中的记账审批方式，以及每个批次与 ERP 总额一致的对账证据。审计师自行决定要求；这些材料提供具体评估依据。

构建者离职后，谁负责 AI 构建的财务工具？

上线前指定财务负责人和技术联系人。使用服务凭据而非构建者个人账号，并通过公司登录提供访问：禁用离职者账号会阻止新登录，现有会话按策略撤销或过期。退役时禁用工具凭据，保留留存政策要求的数据，删除其他数据并关闭工具。