2025年10月16日·1 分钟
AI 构建应用的安全：能承诺的、盲点与防护
了解 AI 构建者能和不能承诺的安全内容、常见盲点在哪里，以及用于安全交付 AI 构建应用的实用防护措施。
了解 AI 构建者能和不能承诺的安全内容、常见盲点在哪里，以及用于安全交付 AI 构建应用的实用防护措施。
“AI 构建的应用”可以指几种不同情况，本文广义使用该术语，包括：
目标很直接：在不自称能做到完美安全的前提下，降低风险。AI 可以加速开发和决策，但它也改变了错误发生的方式——以及错误传播的速度。
本文写给那些没有专职安全团队的创始人、产品负责人和工程团队——或那些有安全支持但需要贴合交付现实的实用指南的人。
你会了解对“安全保证”可以现实地承诺什么（以及不该承诺什么）、一个可复用的轻量威胁模型，以及当 LLM 涉及代码、依赖、工具和数据时常见的盲点。
你还会看到一些既无聊又有效的防护措施：身份与访问控制、租户隔离、秘密处理、安全部署工作流，以及帮助你及早发现问题的监控和滥用控制。
这不是合规指南、不能替代安全评审，也不是会自动让任何应用安全的核对清单。安全是人（培训与归属）、流程（审查与发布门）和工具（扫描器、策略、日志）共同承担的。关键是让这种共同责任变得明确且可管理。
关于 AI 构建应用的安全“保证”往往是隐含的而非明确的。团队会听到诸如“模型不会泄露秘密”或“平台是合规的”这样的表述，然后在脑中把它们转化为绝对承诺。这就是期望与现实偏离的来源。
你经常会看到（或推断出）这样的说法：
这些说法有些在特定情况下可能部分为真——但很少是放之四海而皆准的。
真实的保证有边界：哪些功能、哪些配置、哪些环境、哪些数据路径、以及持续多长时间。例如，“我们不会用你的数据来训练”不同于“我们不会保留它”，两者又不同于“你的管理员不会意外暴露它”。同样，“默认安全”可能适用于入门模板，但不一定适用于经过多次迭代后生成的每一段代码。
一个有用的思路：如果一个保证依赖于你设置正确的开关、以特定方式部署或避免某种集成，那它就不是一个无条件的保证，而是有条件的保证。
供应商可以交付特性；而结果仍然依赖于你的威胁模型、配置和运营纪律。
如果它不可测量，就不是保证。
要求你能验证的东西：书面保留期、文档化的隔离边界、审计日志覆盖范围、渗透测试的范围，以及清晰的责任划分（供应商保障什么，你需要保障什么）。
如果你在使用像 Koder.ai（基于聊天的应用生成，底层有 agent）的“vibe-coding”平台，也要用同样的视角：把“我们为你生成”当作加速，不是安全宣言。关键问题是：哪些部分是标准化且可重复的（模板、部署管道、回滚），哪些部分仍需要你自己的控制（授权、租户范围、秘密、审查门槛）。
你不需要 40 页的安全文档来做出更好的决策。一个轻量的威胁模型就是一张共享的地图：谁与应用交互、你要保护什么、以及事情可能如何出错——特别是当部分代码和工作流由 AI 生成时。
先列出能制造变更或触发动作的各方：
这能让讨论更务实：“哪个行为者能做什么，拥有哪些权限？”
挑出一小套暴露会造成损害的资产：
列出输入穿越边界的位置：
对每个新功能做这个快速检查：
这不能替代完整的安全评审——但能可靠地在改动还便宜时揭露最高风险的假设。
AI 可以快速起草大量可运行代码——但“可运行”不等于“安全”。AI 构建应用中的许多安全故障并非奇技淫巧的攻击；它们是普通的 bug 和不安全的默认设置，因为模型优化的是合理性与速度，而非你组织的安全标准。
认证与授权是常见的失误点。生成的代码可能会：
isAdmin: true）而不是服务器端检查。输入校验也是常见问题。代码可能只校验常见路径，却漏掉边缘情况（数组与字符串、Unicode 绕过、超大输入）或通过字符串拼接构建 SQL/NoSQL 查询。即便用了 ORM，也可能构建不安全的动态过滤器。
加密误用体现在：
模型常常重现类似公开示例的模式。这意味着你可能得到的代码：
从安全模板开始：预先批准的项目骨架，包含你的认证、日志、错误处理和安全默认值。然后对所有安全相关变更（认证流程、权限检查、数据访问层、任何接触秘密的改动）强制人工审查。
再增加不完全依赖人的自动化检查：
如果你通过 Koder.ai 生成应用（React 前端、Go 后端、PostgreSQL），把模板当作你的契约：一次性把 deny-by-default 的授权、租户范围、安全头和结构化日志内置进去，然后让 AI 在这些边界内工作。同时利用平台能减少运维风险的功能（如快照与回滚），但不要把回滚当成预防措施。
安全回归常常以“微小重构”的形式出现。放置一些高杠杆的测试：
把任何“保证”都当作有范围限制的声明。问清楚：
如果你不能测量它（通过日志、策略、文档化的边界），那它就不是一个真正的保证。
安全特性（SSO、加密、审计日志、秘密扫描）是能力。结果才是你能实际承诺的东西（例如：无跨租户访问、无秘密泄露、无未授权导出）。
只有当特性被：
你才可能实现那些安全结果。
做一个快速的轻量威胁建模：
通常这已经足以在改动还便宜时发现最高风险的前提假设。
常见失败往往很普通而非高深莫测：
isAdmin: true）而非服务器端校验。缓解方法：使用安全模板、对安全关键代码强制人工审查，并在 CI 中加入自动化检查（SAST/DAST + 目标化授权测试）。
从可强制执行的控制开始：
同时设定补丁节奏（例如每周；关键 CVE 同日处理），并为每个服务指定命名负责人。
提示注入是不受信任的内容引导模型去无视你的意图。当模型能使用工具（数据库查询、发邮件、退款、部署）时，风险就会放大。
实用防御：
lookup_order(id)）而非自由形式的动作（任意 SQL/Shell）。最大的泄露通常来自间接途径：
降低暴露的方法：数据最小化、在记录前积极脱敏、严格的访问控制，并为每个系统记录明确的保留策略（包括备份的可行性）。
在服务端强制隔离：
tenant_id 进行限定。tenant_id 来源于认证会话，而不是请求体。要做 IDOR 测试：验证用户即便猜到有效 ID 也不能访问其他租户的 /resource/{id}。
遵循三条规则：
在运营上，记录秘密的访问（审计轨迹）、按计划轮换，并在怀疑泄露时立即撤销/轮换。
最低限度的生产监控信号：
如果你不能快速回答“谁用哪个工具对哪些数据做了什么”，事后响应将会缓慢且猜测性强。