AI Agent 隐私架构：本地化重点为什么是登录态与执行权限

"模型运行在本地"经常被当作 Agent 隐私架构的终点，但对能够操作浏览器、调用 MCP、发布内容的工作型 Agent 来说，这只是其中一层。

更直接的风险中心通常是三样东西：模型看到了什么、执行器持有什么身份、系统能够产生什么外部副作用。

为什么登录态比密码更容易被低估

用户登录网站后，浏览器会保存会话 Cookie 或令牌。它通常不是密码原文，但服务端会把携带有效令牌的请求识别为已认证用户。

OWASP Session Management Cheat Sheet 指出：认证会话建立后，会话 ID 或令牌在有效期内，临时等价于用户采用的最强认证方式。泄露会话令牌可能导致会话劫持，攻击者能够以受害者身份执行操作。

因此，下列两句话不能画等号：

模型没有看到密码
≠
Agent 没有获得账号权限

如果一个 Agent 使用持久登录的浏览器，它实际上已经位于身份边界之内。安全设计不能只检查 Prompt 是否含敏感词，还要检查 Cookie 存储、浏览器分区、工具权限和操作确认。

用三平面拆开 Agent 风险

1. 上下文平面：模型需要看到什么

任务上下文应遵循最小必要原则。

写一篇产品文章，模型可能需要产品资料、品牌口径和公开参考；它通常不需要平台 Cookie、完整文件系统、其他客户目录和所有历史会话。

这里可以在进入模型前做三件事：

• 只挂载当前岗位需要的资料源；
• 把账号 ID、密钥、手机号等字段脱敏或替换为不透明引用；
• 禁止工具把凭证、完整响应头和敏感日志回传到模型上下文。

2. 身份平面：谁持有 Cookie 和令牌

凭证应该由执行层持有，规划层只拿能力句柄。

type PlatformHandle = {
  platform: "csdn" | "juejin" | "toutiao";
  sessionRef: string;      // 不透明引用，不是 Cookie 原文
  allowedActions: ("prefill" | "submit" | "read_status")[];
  expiresAt: number;
};

模型可以提出"在掘金预填这篇文章"，本地执行器再检查句柄、平台和动作范围。模型不需要获得 Cookie 字符串，也不应该把它带到另一个 MCP 请求里。

MCP 授权规范强调了类似边界：访问令牌要绑定目标资源，服务器必须验证受众，收到的令牌不能原样透传给下游服务。这样才能避免一个工具拿着"本来不是发给它的令牌"冒充合法调用者。

3. 执行平面：哪些动作必须暂停

读取公开网页、生成草稿与公开发布的风险不一样。

可以按副作用分级：

级别	示例	默认策略
只读	搜索资料、读取公开页面	自动执行，保留来源
可逆写入	生成文件、保存草稿、预填编辑器	自动执行，记录产物
外部副作用	公开发布、发送消息、修改账号	提交前回读并确认
高价值动作	付款、删除、权限变更	强制人工确认或重新认证

OpenAI 的 ChatGPT Agent 安全文档也采用了相同方向：只启用任务需要的应用，敏感登录由用户接管，高影响动作保留确认与监控。

推荐的数据流

一条较稳妥的工作型 Agent 数据流可以写成：

用户目标
  ↓
上下文裁剪与脱敏
  ↓
云端或本地模型：生成计划
  ↓ 仅返回结构化动作
本地工具路由：验证岗位与权限
  ↓
本地浏览器会话：预填页面
  ↓
字段回读 + 人工确认
  ↓
最终提交 + 成功页/作品记录

这个设计允许更换模型，而不需要把浏览器会话跟着模型迁移。它还把 Prompt Injection 的影响限制在"计划建议"一侧，执行器仍能根据允许动作、目标域名和人工检查拒绝越权请求。

当然，这不是银弹。恶意页面仍可能影响模型判断，本地插件也可能有漏洞，所以还需要域名白名单、输出编码、审计日志、版本更新和最小权限。

"留在本地"仍然可能做错

本地化最常见的误区，是把所有东西写进一个 JSON 文件，然后认为"没有上传就安全"。

OWASP 明确警告，不应把认证令牌、会话 ID、JWT 或刷新令牌存进 localStorage 或 sessionStorage，因为同源页面里的 JavaScript 可以读取它们。

本地执行层至少还需要考虑：

• 使用系统安全存储或受控浏览器 Cookie，而不是明文配置；
• 不同平台、不同岗位使用隔离的会话分区；
• 令牌过期、撤销和重新认证；
• 日志默认不记录 Cookie、Authorization 头和完整工具返回；
• 私有 MCP 只挂载给真正需要它的 Agent；
• 发布、删除、付款等动作永远不从模糊指令直接触发。

云端模型是否一定不安全

也不能这么判断。

OpenAI API 当前文档显示，符合资格并获批的客户可以使用 Modified Abuse Monitoring 或 Zero Data Retention。ZDR 会让 Responses 和 Chat Completions 的 store 被视为 false，但文档同时提醒某些能力仍可能保存应用状态。

因此，选本地模型还是云端模型，应由数据敏感度、性能、成本和合规要求共同决定。无论选哪一种，凭证都不该作为普通上下文自由流动。

Tipkay 的产品取舍

这也是我们做 Tipkay 时画的一条边界。

Tipkay 支持切换不同模型，但官网当前明确写着：平台登录态留在本机；AI 员工按岗位配置 MCP 和 Skill；发布等关键动作仍由用户确认。

模型负责理解任务和生成计划，本地客户端负责调用已授权的平台会话，博客发布助手先填写标题、正文、图片、标签和声明，再由用户或明确授权的流程完成最终提交。

这不等于"客户端天然安全"。本地存储、插件来源、会话隔离和工具实现仍需持续审查。它解决的是信任边界问题，而不是替代所有安全工程。

一份最小检查清单

构建或选择工作型 Agent 时，可以先问：

1. Cookie、Token 会不会进入模型上下文或日志？
2. 每个 Agent 是否只加载岗位需要的工具？
3. MCP 令牌有没有绑定正确受众，是否存在透传？
4. 不可信网页能否诱导 Agent 调用另一个高权限工具？
5. 公开发布、删除和付款前是否有独立确认？
6. 最终结果来自按钮点击，还是成功页与作品记录？
7. 会话能否过期、撤销和重新授权？

本地优先不是把模型搬回电脑这么简单。更重要的是，让身份留在正确的边界里，让每次高风险动作都有明确的负责人。

参考资料

• OWASP Session Management Cheat Sheet：https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
• MCP Authorization Specification：https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• OpenAI ChatGPT Agent Safety & Privacy：https://help.openai.com/en/articles/11752874-chatgpt-agent
• OpenAI Agent Link Safety：https://openai.com/index/ai-agent-link-safety/
• OpenAI API Data Controls：https://developers.openai.com/api/docs/guides/your-data#default-usage-policies-by-endpoint
• Tipkay：https://www.tipkay.com/