北京
Google I/O 2026上，Firebase AI Logic正式GA。开发者可以直接从网页或移动应用调用Gemini，无需后端服务器、无需在代码包里塞API密钥、也无需管理基础设施。听起来很理想，但把AI端点直接暴露在互联网上，攻击面也随之打开。
目前大多数讨论只提到了Google提供的其中一种安全机制。实际上有四层，它们组合工作。以下是完整拆解。
先明确威胁模型
在谈代码之前，需要精确界定可能出问题的环节：
配额耗尽——任何人找到你的端点并编写脚本，就能耗尽你的token预算。每次AI调用都直接产生账单。
提示注入——如果系统指令存在于客户端代码中，攻击者可通过二进制反编译或网络拦截提取，进而利用。
Token重放——即使短期有效的认证token也可能被拦截复用。5分钟的窗口期足够脚本疯狂请求。
推理时的不安全内容——用户输入默认不会被模型层消毒。缺乏推理层强制管控时，对抗性输入可能穿透。
下面四层防护分别直接封堵上述缺口。
第一层：代理架构
封堵：API密钥盗窃导致的配额耗尽
朴素做法是把Gemini API密钥嵌入应用包直接调用。但应用包可被反编译，网络流量可被观测，终将暴露。
Firebase AI Logic在架构层面解决此问题。所有SDK请求都路由经过Firebase的代理服务器。你的Gemini API密钥驻留在Firebase基础设施上，永远不会传输到客户端。
代码示例显示，Firebase Web API密钥只是项目标识符，受安全规则约束；而携带计费权限的Gemini API密钥从不会出现在代码库中。
第二层：服务端提示模板 + 仅模板模式
封堵：提示注入与提示提取
如果系统指令放在客户端代码，两件事会出问题：反编译应用二进制可直接读取完整提示；动态组合用户输入时，精心构造的输入可能突破边界。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
