Vercel 近日宣布 Security Review 公开测试，把 AI 安全审查接到关联 GitHub 仓库的每次推送上，直接推送到生产分支也在覆盖范围内。对使用 Vercel、频繁借助 AI 写代码的独立开发者和小团队来说，这多了一次发现权限遗漏的机会。本文讲清它检查哪部分代码、发现后怎样修复，以及为什么“没有再报错”还需要自己验收。

AI 安全审查概念图：代码推送、问题发现与人工验收

原创 AI 概念封面，展示审查与验收流程，不代表产品界面或本站实测。

[配图建议：多条代码纸带进入检查拱门，修复补丁停在人工作业台前 + 金黄、钴蓝和橙红配色的纸雕版画风格。]

一、从 PR 扩展到推送，补上容易漏查的变化

先说明时间口径：官方介绍页标注 2026 年 11 月 2 日，公测变更日志标注 11 月 3 日。本文结合这两份近 72 小时资料解读这次公测，不把它写成今天刚推出的新能力。当前面向 Pro 与 Enterprise 团队，需要在设置里启用。来源：官方介绍、公测变更日志

它的关键变化是触发点：审查从 GitHub push 事件开始，而不依赖有没有拉取请求（PR）。因此，直推与强制推送到生产分支的变更也能进入检查。同一次推送影响的项目会一起审查。来源：工作机制

这解决的是覆盖机会的问题。小团队赶着修线上故障，可能没有先开 PR；一个自动化脚本也可能直接产生提交。让检查跟随代码变化，可以减少流程差异造成的空档。

但“推送后会审查”和“上线前一定拦住”是两个要求。公告描述了推送触发、结果面板和 GitHub 检查项，不能据此认定生产部署会自动等待审查通过。若业务需要强制门禁，仍应核对自己的分支保护、检查项要求和发布流程。

检查范围也要看清：它通常对比基线审查变化；部署场景以该分支上一次部署为基线，没有基线时才读取完整源码。单仓多项目按项目根目录限定范围。这样的设计适合持续检查新增变化，首次结果也不宜当作完整安全审计证书。来源：基线与范围说明

[配图建议：PR 推送、直接推送两条路径汇入同一个审查节点，旁边单独画出部署门禁 + 简洁流程图风格，不将审查画成默认阻断部署。]

二、真正值得看的是业务权限，而不只是代码格式

用一个自拟场景说明：团队维护一个多租户知识库，用户可以下载自己公司的资料。新接口检查了“是否登录”，随后却只按文档 ID 查找文件，没有检查文件属于哪家公司。

这样的代码可能通过类型检查，普通用户下载自己的文件也能成功。真正需要追问的是：用户换一个文档 ID 后，服务端是否仍然验证他有权读取？这类问题取决于调用路径、用户身份与业务资源之间的关系。

Vercel 在官方介绍中说明，审查会结合变更与周边代码，检查可达路径及现有保护，并在上报前重新检查发现项。这是厂商对工作方式的描述，本文没有测试其检出率，也不据此给不同工具排能力名次。来源：审查过程

团队还可以用自然语言补充安全策略。对上述知识库，可以写下这条示例规则：

所有读取或下载知识库文档的接口，都必须根据当前用户所属组织验证文档归属；登录成功不能替代组织级权限校验。

这条规则把“注意安全”变成了可以围绕代码核查的业务要求。策略能为审查提供上下文，却不会自动成为接口里的权限实现；开发者还要确认真实请求确实经过了相应检查。来源：安全策略说明

对 AI 产品尤其如此：前端按钮隐藏、提示词要求“只看自己的资料”，都不能代替后端授权。把产品约束写成明确规则，再为越权路径准备可核对的测试，比让审查工具猜测业务边界更有帮助。

[配图建议：两个虚构组织各有资料柜，登录凭证与资料归属校验分别画成两道检查 + 纸张拼贴情境插画，避免出现真实客户信息。]

三、AI 提交修复后，为什么还要做一次验收

发现项可以在 Vulnerabilities 面板查看，也可以交给自己的编程助手处理。使用 Vercel Agent 修复时，需要开启 Chat；它会确认问题、尝试最小修复并运行类型检查、lint 和测试，随后打开 PR，合并由人决定。来源：修复流程

更容易被忽略的是结果的含义。管理文档明确说，严重程度是 AI 估计，不是按固定评分准则算出的分数；Closed 表示后续审查不再检测到问题，并不确认问题已修复。来源：发现项与状态

因此，上述下载接口的验收至少应包含：

  • 合法访问：本组织用户仍能下载自己的资料。
  • 跨组织访问：另一组织的用户无法凭文档 ID 读取它。
  • 未登录访问：请求被拒绝，响应不带文件内容。
  • 其他入口：预览、导出等路径是否沿用同一权限约束。

这些是本文建议的验证方向，不是声称工具已经替你完成的测试。验收时应使用独立测试账号和虚构资料，在可控环境核对结果，留下能够复查的证据。

信息可见性也值得提前安排。官方说明，公开仓库只展示检查项，问题细节留在面板；私有或内部仓库的 PR 评论则可能包含源码片段，仓库访问者都能阅读。团队应根据实际访问范围分配处理人员。来源：隐私说明

[配图建议：修复 PR 旁放置合法、跨组织、未登录三类测试记录，最后由人签收 + 编辑插画与验收记录单结合的风格，不使用“零漏洞”印章。]

四、先选一个项目，把收益和账单一起观察

适合优先试用的，是已经使用 Vercel Pro 或 Enterprise、连接 GitHub，并且确实需要持续检查业务权限的小团队。官方介绍把 CLI、v0 部署以及不在 Vercel 部署的仓库列为后续扩展方向，不能把现有公测理解成所有代码来源都已覆盖。来源：后续计划

开始时可在团队 Agent 设置里开启自动审查，并选择具体项目。建议先挑一个业务边界清楚的测试项目，写下一条明确的权限规则，观察推送后发现项是否能定位到正确提交，以及处理者是否能顺利完成复核。

已安装并登录 Vercel CLI 的团队，可以通过下面的官方入口读取发现项；变更日志要求 CLI 65.10.0 或更新版本：

vercel security vulnerabilities

来源：CLI 文档、版本要求

费用要拆开理解。官方公告称安全审查免费至 2026 年 11 月 10 日，Vercel Agent 修复工作仍计费。常规定价包含底层提供商推理费，再加每百万 Token 0.25 美元的 Vercel Token Rate；后者涵盖输入、缓存与输出 Token，不是整个任务的总价。来源：公测价格说明、Agent 计费文档

因为按推送触发，评估时可以同时记录推送频率、有效发现、误报处理时间、修复耗时与实际费用。不要仅看告警数量：重复追查无关问题会占用精力，少量定位准确的权限缺口反而可能更有价值。

[配图建议：一个测试项目旁摆放记录单，分别记录有效发现、人工处理时间与实际费用 + 克制的账本式信息图，不填虚构节省比例。]

今天先验一条权限边界

这次公测提供了一条跟随代码变化持续检查的路径，价值需要结合项目和实际发现判断。它分析源码，不执行运行时或渗透测试，重要业务仍需保留相应验证。来源：能力边界

今天可做的一步：选一个资料下载接口，写清“谁可以读什么”，再为合法与越权请求各留一份验收结果。你当前更缺的是发现问题的机会，还是发现之后确认修好的证据？

资料核查于北京时间 2026 年 11 月 5 日。本文依据官方公告与文档分析，未启用服务实测；文中知识库场景与验收建议由本站编写。

[配图建议：一条业务权限规则连接到两份可核对的请求结果 + 与封面一致的暖色版画收尾风格。]