如何在不制造风险的情况下让 AI 智能体访问你的游戏数据

访问控制假定使用访问权限的人就是获得权限的人，并且此人能够区分提问与命令。智能体打破了这两个假设。

在构建 GameAnalytics MCP 服务器时，我们在开发开始前进行了一次隐私与安全审查。基于这项工作，我的立场是——有些人会不同意：主要风险不在模型本身，而在于你赋予它的访问权限。

智能体带来的三个新问题

智能体会使用你交给它的凭据中的每一项权限，而不具备人会运用的判断力。2025 年，研究人员展示了一个编码智能体，它通过一个绕过所有行级安全的角色连接到 Supabase 数据库。

它也会随时间生效。当生产者离开时，你会移除其仪表板访问权限。他们 AI 助手里的连接会在同一时刻停止吗？许多团队从未测试过这一点。供应商也会出错：Asana 发现其 MCP 服务器存在一个缺陷，导致约 1,000 名客户的数据对其他组织可见。访问模型本身就是错的。

正如 Simon Willison 所说，

“LLM 无法根据指令的来源可靠地区分其重要性。”

Invariant Labs 展示了这意味着什么：公共 GitHub 仓库中的一个恶意 issue 让用户的 agent 将其私有仓库中的详细信息（包括薪资）复制到一个公开的 pull request 中。

游戏数据中充斥着别人写的文本：玩家名称、公会名称、客服工单、商店评价、聊天记录。每一处都是指令可能藏身的地方。

智能体检索到的内容会发送给 AI 提供商，并且在你撤销用户访问权限后仍留在聊天历史中。你可以切断连接，却无法收回已经给出的回答。

2023 年，三星在工程师将源代码粘贴进 ChatGPT 后禁止员工使用生成式 AI 工具，因为那些数据难以检索和删除。智能体则会自动执行这一过程，一次一个查询。对工作室而言，风险更高，因为玩家数据可能涉及儿童，这在 GDPR 和 COPPA 下会提高风险。

代理应以用户身份行事，仅拥有用户的权限，不得更多。不使用共享服务账户，不在配置文件中放置管理员密钥，默认只读。

对每个请求都检查访问权限，而不是仅在登录时检查一次。MCP 规范指出，服务器“必须验证所有入站请求”。在我们的场景中，这是最关键的控制措施：当有人离开组织时，其代理发出的下一个请求就会失败，即使该连接仍显示在其助手中。

团队的大多数问题都关乎趋势：DAU、群组留存率、按国家划分的收入。这些都不需要玩家 ID。默认向代理提供聚合结果，并将玩家级别的访问视为一个单独项目，需经过独立审查。

如果智能体从不持有玩家记录，那么可泄露的内容就很少，可供隐藏指令的玩家撰写文本也更少。

要像提示注入终有一天会成功那样来设计。限制被骗的智能体能做的事：不向外发送数据，不写回数据。然后记录每一次调用、调用者、所用工具和结果，但不记录内容，否则你的日志就会成为你想保护的数据的第二份副本。

在将智能体连接到游戏数据之前，请检查：

如果供应商无法明确确认这些，我不会连接它。

我的预测：18个月内，游戏领域首个被广泛报道的AI数据事件不会来自被入侵的服务器。它将来自一个拥有超出所需权限、并遵循了玩家所写文本中隐藏指令的智能体。

能避开这一问题的工作室不会拥有最好的模型。他们会在早期就决定其智能体被允许看到什么。在GameAnalytics，我们在写第一行代码之前就做出了这个决定。我建议你在第一个智能体上线之前也做出这个决定。