检查清单
简短回答
在同事使用你用AI做的应用之前，先检查四件事：没有人能绕过企业登录，只有你们公司的账号能进来，浏览器里运行的代码中没有密钥，数据库不经过应用就读不到。然后检查应用里谁能做什么，以及你离开后它归谁负责。
用AI做的应用发生的泄露，大多不是什么高明的攻击，而是门没关：一个公开链接，一个关掉了访问规则的数据库，一个写在页面里的密钥。这份清单写给做应用的人，也写给负责审查的IT同事。每一项都说明会出什么问题、怎么用简单的方法检查，以及TeamOnly负责哪些、哪些仍然要靠你。
01为什么重要
AI工具很擅长让应用跑起来，却不太在意还有谁能用它。过去两年的三项发现说明了这个规律。
这些都不需要什么高明的攻击者，门本来就开着。好消息是：开着的门很容易检查，而且不用读代码就能做到。
核对于2026年10月26日。来源：Security Boulevard on Red Access’s findings（2026年5月）、Matt Palmer, statement on CVE-2025-48757（2025年）、Spracklen et al., “We Have a Package for You!”（USENIX Security 2025）。
02检查清单
按顺序来。前几项把外人挡在外面，后几项找出公司内部的疏漏。
hd设置只是缩小账号选择列表的范围，Google也提醒不要依赖它，因为请求可以被篡改。域名必须在服务器端检查。npx teamonly access only priya@acme.com。每次请求都会检查，所以移除某人会在一分钟内生效。site:加上你应用的网址。在你用来做应用的平台上检查项目的可见性设置。如果显示公开，先改掉它，再做别的。yourapp.yourcompany.teamonly.app。每个响应，包括登录页，都会告诉搜索引擎不要收录，登录页上也只显示应用名称和登录方式。VITE_或NEXT_PUBLIC_开头的变量里。发送到浏览器的一切，任何打开应用的人都能读到。Supabase说它的secret密钥绝不能出现在浏览器里，因为它会跳过所有数据库规则。VITE_变量或已提交的.env文件里，有没有任何密钥、令牌或密码？”在浏览器里打开开发者工具，在加载的文件中搜索key、secret和sk_。如果某个密钥曾经暴露过，到签发它的服务那里更换。npx teamonly secrets set NAME保存在代码之外，只有你应用的服务器端代码能读取。TeamOnly添加的说明要求你的AI工具绝不使用VITE_密钥。但没有什么能阻止你自己把密钥粘贴进代码，所以仍然要检查。ctx.user）和你在控制台里分配的角色（ctx.user.roles），伪造的身份标头会被移除。说明会要求你的AI工具使用查询占位符，并在服务器端检查输入。在每个路由里检查角色，是你应用的代码要做的事。TeamOnly不会审查它。package.json。遇到不认识的名字，就去npmjs.com查一下：真实的包有历史记录、关联的源代码仓库和稳定的下载量。部署前运行npm audit，并删掉应用不再使用的包。03打印出来
十一个是非题。任何一个“否”，就是下一件要修的事。
site:搜索应用的网址，什么都搜不到。package.json里的每个包都真实存在，并且仍在使用。想要纯文本版？本页的Markdown版本里有现成的清单可以粘贴（英文）。
04面向IT
和搭建者一起花十五分钟，共享屏幕。你检查的是配置，而不是逐行读代码。
拿到网址。用一台没有登录的设备打开，再用个人账号打开。问清楚它托管在哪个平台、用谁的账号付费。如果是个人账号，这是第一件要改的事。
问清楚输入了什么、数据从哪里来。客户个人数据、支付数据、健康数据或其他系统的密码会提高要求，可能意味着这个应用应该只开放给指定名单。
列出应用调用的每个外部服务。每个密钥都应该放在托管平台的密钥设置里，权限只限于应用需要的范围，并且不与其他应用共用。凡是曾经出现在代码或聊天里的密钥，都要更换。
让搭建者以普通用户身份登录，或者请一位同事来登录，试试管理员操作。请搭建者让他的AI工具列出每个API路由，以及在哪里检查角色。这里的漏洞要在应用的代码里修复。
一起看package.json，并运行npm audit。要求代码放在公司的Git仓库里，而不只是在搭建者的笔记本电脑上。
把应用、负责人、备用负责人、数据和用户写进你的应用清单。约定好负责人离职时怎么办。影子AI应用指南里有一页可以直接复制的制度。
可以做到。常见的问题出在应用放在哪里、怎么配置：公开链接、没有真正的登录、密钥放在浏览器里、数据库规则被关掉。每一项都能在几分钟内检查完。发链接之前，先按本页的清单过一遍。
不登录就能访问到的数据。通常有两种情况：应用放在公开链接上，前面没有登录；或者数据库直接响应请求，而它的访问规则是关着的（Supabase里的行级安全（RLS））。两者都是配置问题，而不是AI写了糟糕的代码。
anon或publishable密钥本来就是给浏览器用的，但前提是行级安全限制了它能访问的范围。如果某张表关掉了行级安全，任何拿到这个密钥的人都能读取和修改它。secret或service_role密钥绝不能出现在浏览器里：它会跳过所有规则。
单靠它不行。默认情况下任何Google账号都能登录，包括个人Gmail。Google的hd设置只是缩小账号选择列表的范围，Google也说不要依赖它。应用的服务器必须在每次请求时，检查经过验证的登录令牌里的域名。
在Google搜索site:加上你应用的网址，比如site:myapp.lovable.app。如果出现了页面，说明应用是公开的，并且已被收录。把应用设为私密，或者移到企业登录之后；如果域名是你的，再用Search Console里的“移除”工具请Google删除这些页面。
要，而且给它固定的说明比偶尔叮嘱一次更好。项目里的规则文件（CLAUDE.md、AGENTS.md或Cursor规则）会告诉工具密钥放在哪里、怎么写数据库查询、在哪里检查角色。npx teamonly init会为TeamOnly应用添加这些说明。之后仍然要自己检查：说明能减少错误，但不能消除错误。
不会。TeamOnly会在每个应用前面加上企业登录，把每个应用的数据和密钥分开，并让应用不出现在搜索引擎里。它不会审查你的代码、扫描你的依赖包，也不会检查应用内部的规则。清单上的这些项目仍然由你负责。
它托管在哪里、谁能访问、登录是怎么限制的、密钥放在哪里、里面有什么数据、谁是负责人，以及这个人离职后怎么办。本页的“面向IT”部分是一份简短的审查，你和搭建者花15分钟就能完成。
核对于2026年10月26日。其他来源：Google, OpenID Connect（hd参数）、Supabase, API keys、Supabase, Row Level Security、Supabase, Database Advisors、OWASP Top 10:2025、Retool, Secure vibe coding（一份更长的清单，适合自己运维托管的团队）。
抢先体验
一条命令部署，应用就在你的企业登录之后，不进搜索引擎，自带数据库和密钥。免费试用14天，无需绑卡。
有问题请发邮件到hello@teamonly.dev，会有真人回复。