AI构建的SaaS在第一位付费用户前我审计的内容
本文作者基于自己用AI构建SaaS的经验，指出AI生成代码在规模生产中的关键问题：缺乏机械性的拒绝表面。作者建议在SaaS上线前审计七项关键安全与可靠性措施，包括：边界授权（而非处理器内部）、数据库层深度防御、AI调用的评估而非单元测试、每租户成本归属、提示注入的爆炸半径、API密钥安全和可观测性。文章强调，这些结构性防御比行为性提醒更有效。
本文以一个警示故事开篇：一个AI构建的MVP上线生产环境，两周内便有客户读取了其他客户的数据。原因是模型在十四个处理器中漏掉了一个租户隔离检查。代码看起来完全相同，测试全部通过，但代码库中没有东西从机械层面上拒绝了这个错误。这揭示了核心问题：AI生成的代码缺乏“拒绝表面”——即代码本身机械地拒绝无效输入或状态的边界。
作者使用Cursor和Claude Code在九个月内独立构建了多租户SaaS Allset，基于此经验，他提出了在迎来第一位付费客户前需要审计的七个领域：
- 边界授权，而非处理器内部授权：不应依赖每个处理器内部的运行时检查（模型可能遗忘），而应将授权变为类型。例如，
TenantAccess值只能由一个边界函数构造，该函数执行数据库查找。跳过此检查的代码无法编译。Allset使用SpiceDB强制执行此规则。
- 数据库层的深度防御：即使有了类型化边界，仍需第二道锁。使用数据库级别的强制措施，如PostgreSQL的行级安全（RLS）或DynamoDB的IAM条件。应用程序在连接边界设置租户ID的会话变量，数据库独立拒绝不匹配的行。Allset在每个租户作用域的表上使用Aurora Postgres的RLS策略。
- 使用评估（evals）而非单元测试来测试AI调用：单元测试不适合随机性的AI输出。应使用评估——输入数据集配以评分函数，在CI中运行。从20个评估开始，每次用户报告模型出错时增加一个。这种基础设施提供真正的信心，而快照固定（snapshot-pinning）每次模型更新都会失效。
- 每个模型调用的按租户成本归属：为每次模型调用打上租户ID、模型和用途的标签。一个简单的仪表盘就能显示每个租户的每日成本。这在第一天只需五分钟，但事后重构需要一周。没有它，就无法明智定价或检测失控循环。
- 提示注入的爆炸半径：不要试图完全阻止注入（不可能），而应限制代理工具在当前租户上下文中的作用域。例如，
db_query工具应使用租户作用域的凭证。跨越租户边界的工具应结构上无法从单租户代理上下文中调用。
- API密钥安全：使用临时、作用域限定的密钥，而不是长期密钥。这限制了密钥泄露时的损害。
- 可观测性：实现指标、日志和追踪，特别是针对安全和成本异常。这确保你能快速检测并响应问题。
作者强调，这些结构性防御远比行为性提醒（如“在CLAUDE.md中验证租户访问”）有效。代码本身必须机械地拒绝错误行为。从一开始就构建这种拒绝表面，对任何追求生产可靠性的AI构建SaaS都至关重要。