AI产品的输入框看似简单，背后却隐藏着多层校验与安全防线。从文件上传到模型调用，每一个环节都可能成为攻击的入口。本文通过实际案例，剖析产品在公网暴露后遭遇的扫描与攻击，揭示安全设计必须从产品定义阶段就开始，而非事后补救。

现在很多AI产品的首页，看上去都差不多：中间放一个大输入框。

用户输入一句话，挂一张图片或者一份文件，剩下的事情交给AI完成。这种交互有个名字，叫LUI，也就是Language User Interface。

即梦现在的创作页就是一个很典型的例子。

站在用户这边看，它就是一个上传入口加一个输入框。只把这个界面画出来，代码可能并不多。真要放到线上，麻烦的全在后面。

最后到底是七八百行还是上千行，取决于框架和实现方式。但增加出来的大部分东西并不是这个框，而是后面那一堆用户看不见的判断。

上传一张21:1的图片，接不接？

图片很模糊，还能不能进入后面的生成任务？

上传的是PDF，系统能不能解析？

文件有10GB怎么办？

一次上传几十份文件怎么办？

内容涉及色情、暴力或者其他违规信息，又应该在哪一层拦住？

这里面至少有格式、大小、比例、分辨率、清晰度、数量、内容安全和解析状态等多层校验。后面还连接着文件存储、内容审核、模型调用、失败重试和费用计算。

所以输入框变简单了，不代表产品也变简单了。很多原来能写在页面上的限制，现在全被推到了后台。

用户看到的是“我可以让它做什么”。

产品团队还要回答另一半：什么情况下，系统必须拒绝。

产品面对的，从来不只是预期用户

我们之前做一款模拟面试产品时，设计的流程很清楚：用户选择岗位，AI提问，用户回答，系统继续追问，最后生成评价。

把这条核心链路跑通，产品看上去就已经能用了。

真正交给用户后，有人一上来就试探系统提示词，有人根本不面试，直接和AI聊失恋，还有人发送色情内容，看模型会怎样回答。

这些行为不全是攻击。

聊失恋是偏离场景，发送违规内容是内容安全问题，套取系统提示词更接近对模型边界的试探。

它们不是一类问题。

但最后都会把产品逼到同一个问题上：我们只设计了用户应该怎样使用，却没有想清楚用户不这样使用时，系统怎么办。

还是拿上传来说。

一个正常用户上传了不符合要求的大文件，可能只是一次产品异常。有人连续上传几百个超大文件，不断触发解析和模型任务，就是在滥用正常功能。如果提交的是专门构造的恶意文件，目的是寻找解析漏洞，这就不是异常处理了，而是主动攻击。

所以不一定要多出一个新入口才会有危险。同一个正常功能，换个频率、规模和意图，风险就完全不一样了。

我上一篇写0-1和1-N，重点是产品上线以后怎样持续迭代，怎样继续变好。

这一篇其实是往1-N里面再拆一层：产品得先扛过这些事，才有机会进入第二版。

而且安全、限损和恢复也不是做完1-N以后再补。产品准备公开内测时就要开始做，后面还得一直补。

产品还没几个用户，攻击已经先到了

我们在做Lollipop时，从刚开始内测就持续遭受扫描和攻击。

产品还没赚到钱，也没抢谁的生意，为什么会有人盯着它？

后来我们回查了一台对外服务器大约32天的认证日志和访问日志，重新统计出约125万条与连接探测、密码尝试和Web扫描有关的日志事件。

这个数据我稍微解释一下啊。

125万不是125万个攻击者，也不能直接理解成125万次相互独立的攻击。一次SSH连接可能同时留下连接探测、密码失败和无效用户名等多条记录。它证明不了有125万人在盯着我们的产品。

所以并不是说一个产品做成功了才会有人攻击。

你的产品可能还在起步阶段，甚至都没有用户，扫描和攻击就已经来了。

日志里既有大量SSH连接探测和密码爆破失败，也有对.env、.git、各类.php路径的探测，还有带着常见扫描工具特征的访问。

对方未必知道Lollipop是什么，也不关心它有没有收入。很多攻击本来就是自动化的：扫描一批IP和域名，寻找开放端口、弱密码、暴露文件和已知路径，撞不中就换下一个，撞中了再决定这台机器能拿来做什么。

一台机器一旦被拿下来，可以用来拿数据，也可以用来偷算力、继续扫描，或者成为下一次攻击的跳板。

所以，“我这么小，谁会攻击我”这个问题本身就不太成立。

自动化程序不会先研究你的产品值不值得攻击。只要服务暴露在公网，它就可能被塞进同一批扫描任务里。

后来我们确实一直在打补丁、加强防火墙。但回头看，补丁和防火墙只解决了其中一层。网络入口挡住了一部分流量，产品内部的权限、资源和模型动作，仍然要靠业务自己定义。

攻击借用的，往往就是产品自己的能力

有些攻击甚至都不会进入产品逻辑，它们先在外面批量试门。

它们寻找的是开放端口、常见后台、暴露配置、弱密码和已知漏洞。这类问题通常发生在服务器和网络层，也是防火墙、WAF、补丁和安全配置最先处理的地方。

再往里，是绕过页面直接调用接口。

页面上没有按钮，不代表能力不存在。普通用户只能查看自己的任务，如果修改一个任务ID就能读取别人的数据，问题不在页面有没有藏好，而在服务端没有再次确认：当前账号是谁，这份数据属于谁，他有没有资格执行这个动作。

还有一些攻击根本不需要拿下服务器。它只要把产品的正常能力用到失控。

AI产品的一次请求，后面可能连着文件解析、向量检索、模型推理、图片生成和第三方服务。有人批量创建任务、提交超长内容或者反复触发重试，最后不一定偷走数据，却可能让模型费用持续上涨、队列被占满，正常用户反而用不了。

OWASP把这类问题称为“不受限制的资源消耗”。它特别提醒，上传大小、执行时间、单次操作数量和第三方服务支出都需要限制，因为简单的API请求就可能被并发放大。

到了AI产品这里，还得多防一件事：模型手里开始有工具了。

当模型可以读取网页、文档和知识库，还能发送消息、修改数据或者调用内部工具时，恶意指令可能藏在用户输入或外部内容里。问题也不再只是模型答错一句话，它可能真的替用户做了原本不该做的事。

OWASP把这种情况叫作“过度代理权”，常见原因就三个：

功能给得太多，权限给得太大，模型自己决定的空间太宽。

放到产品里，就是模型不需要读的内容不要给，不需要调用的工具不要挂，高影响动作不要只靠模型自己决定。

你能用AI做产品，别人也能用AI提高攻击的试错速度

其实网络攻击早就自动化了。扫描、撞库、漏洞探测和蠕虫传播，一直都可以按预设规则批量运行。

AI现在又让这套流程多了一点判断和调整能力。

最近的预印本《AI Agents Enable Adaptive Computer Worms》把本地开放权重模型、Agent工具链和传统网络蠕虫组合到了一起。

程序可以观察目标环境，选择攻击路径，失败以后读取反馈，再调整下一步。

研究团队在一个由33台Linux、Windows和IoT设备组成的隔离网络里做了15次实验。

每次让系统自主运行7天，平均取得23.1台主机的高权限，并传播到20.4台主机。

不过，这个实验不能直接套到现实互联网。

实验环境里的每台目标都预先存在至少一个可利用问题，没有部署EDR等主动端点防御，脆弱主机的密度也高于真实生产网络。所以我不会把它写成“AI蠕虫已经在现实里大规模传播”。它至少说明，这种“观察、执行、反馈、再调整”的组合已经可以跑起来了。

我觉得产品团队更应该警惕的是，攻击者反复尝试的成本还在下降。

以前脚本遇到不同系统、不同报错和不同配置，可能只能停止，或者等人重新改规则。接入模型以后，其中一部分环境理解、方案生成和失败调整可以继续自动运行。

你能用AI更快地做产品，攻击者也能用AI更便宜地理解入口、生成变体和反复试错。

防守不是多装一道墙，而是把拒绝条件写进产品

很多团队谈到安全，第一反应是加强防火墙。

防火墙和WAF当然重要。我们自己遇到攻击以后，也确实做了这类加强。但它们主要处理网络连接、异常流量、扫描和一部分已知攻击。

它们不知道一个模拟面试用户为什么连续创建几百场面试，不知道当前账号有没有资格查看某份报告，也不知道模型能不能读取一段内部资料、调用某个工具。

防火墙处理的是流量，产品仍然要回答自己的业务规则。

如果只能做一轮检查，我会先从产品里找三类动作：

• 最贵的动作：模型生成、文件解析、图片和视频处理、付费第三方调用；
• 最敏感的动作：读取用户数据、下载报告、访问内部资料；
• 最难撤回的动作：发送消息、修改数据、支付和删除内容。

同一个动作可能同时属于三类。越贵、越敏感、越难撤回，越应该优先检查。

找到关键动作以后，不需要先背完所有攻击名称。对着每一个动作，问清三个问题就够了：边界在哪里，上限在哪里，退路在哪里。

边界在哪里：什么能进入，谁能让系统做什么

先看输入。

文件格式、大小、数量、比例、分辨率和内容审核，应该尽量发生在昂贵处理之前。不符合要求的内容，能在上传或解析前拒绝，就不要等文件存完、模型跑完、费用产生以后再报错。

再看身份、对象和动作。

一次读取报告的请求，至少要检查当前账号是谁、报告属于谁、当前账号能不能读取，以及他要执行的是查看、下载还是修改。页面把别人的报告藏起来，只能说明界面没展示。权限一定要在服务端再校验一次，不能只靠前端藏按钮。

模型和工具也一样。

模型不需要读的数据，不要塞进上下文；不需要调用的工具，不要挂给它。系统提示词也不应该被当成存放密钥、内部地址和敏感规则的保险箱。

即使模型判断应该调用某个工具，服务端仍然要重新校验这次动作是否被允许。模型可以提出动作，不应该成为最终的权限系统。涉及发送、修改、支付和删除时，还要根据影响增加用户确认或人工审批。

边界是否生效，不能靠“页面上已经没有入口”来验收。要用低权限测试账号绕过页面直接请求接口，确认服务端确实拒绝、响应里没有目标数据，日志还能记录拒绝原因。

上限在哪里：一次异常最多能造成多大损失

每一个昂贵动作都应该有上限。

上传入口要限制单个文件大小、文件数量和单次处理量；接口要限制一定时间内的调用频率；模型要有Token、次数和费用额度；任务队列要限制同一账号的并发数；失败重试也要有次数和总时长，不能无限循环。

这些阈值不能靠“正常用户应该不会这样用”来决定。它们要结合真实使用基线、套餐权益、单次成本和系统容量设置，再随着上线后的数据调整。

上限也不一定只有一个数字。接近阈值时可以提醒，继续增加时可以排队或者降级，达到硬上限后必须停止。

验收时要确认，超过测试阈值以后，系统是在模型或第三方服务调用之前停下来的，调用次数和费用不再继续增长；一个测试账号持续创建任务，也不能拖慢其他正常账号。

限损不是保证异常永远不发生，而是先把一次异常最多能吃掉多少资源定下来。

退路在哪里：出事以后能不能看见、停住并恢复

校验做得再细，也不可能提前覆盖所有问题。

第三方模型会超时，密钥可能泄露，新版本可能带来新的权限问题，原本正常的功能也可能突然被批量滥用。

所以日志至少要能回答：谁在什么时间发起了请求，访问了什么对象，执行了什么动作，消耗了多少资源，最后是否成功。

告警不能只负责“发出来”，还要明确谁来接、什么情况下升级、负责人不在线时谁接手。

模型调用、文件解析、工具调用和第三方服务最好能够独立暂停。出现问题时先关掉风险最大的能力，不要让整个产品只能一起下线。

费用也要有告警和熔断。密钥泄露后要能及时撤销并替换。涉及数据修改的动作，还要提前考虑怎样回滚，恢复服务以后怎样避免重复执行、重复计费和数据错乱。

这些东西都要演练。

测试告警能不能真的找到负责人，功能开关能不能停止新任务，权限能不能撤销，错误数据能不能回滚。没有被实际按过的紧急开关，只是一份心理安慰。

把三个问题写进一张行动卡

这张卡不是让产品经理自己去做渗透测试，更不是让人越过安全边界去测试别人的系统。产品经理要做的是把边界、上限、退路和通过标准写进需求与验收，再和开发、测试、运维、安全一起把它们做出来。

如果团队没有现成的安全检查流程，可以从一张空白卡开始。对产品里每一个最贵、最敏感或者最难撤回的动作，填一张。

#关键动作

它为什么需要优先检查：最贵／最敏感／最难撤回

#边界

什么输入可以进入，什么必须拒绝

谁可以发起

可以访问什么数据、操作什么对象

身份、对象和动作由哪一层校验

#上限

单次、并发、频率、重试和费用上限

接近上限时怎样处理

达到硬上限后在哪里停止

#退路

需要记录哪些日志什么情况触发告警，由谁处理

怎样单独关闭这项能力

怎样撤销权限、替换密钥并恢复服务

#验收

用什么测试账号、合成数据和临时阈值验证

什么证据能够证明控制已经生效

这些测试只应该在团队自己的测试环境中进行，使用测试账号、合成数据和临时阈值。不要拿生产用户数据验证风险，也不要把主动攻击别人的系统理解成“做一下产品验收”。

上一篇文章最后问，产品有没有第二个版本。

这一篇想补上前面那个问题：它有没有机会活到第二个版本？

现在用AI做出一款产品越来越快，但跑通只代表成功路径有了。错误输入能不能拒绝，恶意调用能不能限住，真的出事以后还能不能停下来、恢复，才决定它能不能上线。

做出来已经越来越便宜了。

一个产品能活下来，本身就是门槛。