安全与隐私 FAQ
这里回答关于令牌安全、日志和权限最常见的问题，并给出可以直接照做的建议。涉及日志留存范围时，以控制台展示和管理员的实际配置为准。
请求内容会被保存吗
平台至少会保留调用的元信息，用来计费和排错：时间、模型、令牌、状态码、消耗等。是否保存请求正文和响应正文、保存多久，取决于当前的日志配置。
如果你有明确的合规要求，先在控制台的「使用日志」里确认能看到哪些字段，再据此判断，而不要凭默认假设。
谁能看到调用日志
一般是分级可见：
- 普通用户在「使用日志」里只看得到自己令牌的请求记录
- 管理员能看到更大范围的调用信息
「管理员能看日志」不等于「所有请求正文都可见」——正文是否记录，同样取决于日志配置。
不要把服务端令牌暴露在前端
最常见也最危险的错误，是把令牌写进网页、小程序或 App 的前端代码里。前端代码任何人都能查看，令牌一旦放进去就等于公开。
正确做法：
- 令牌只放在服务端（后端接口、环境变量、密钥管理工具里）
- 前端调用你自己的后端，由后端携带令牌去请求彼源 AI
- 确实要给浏览器插件或桌面客户端用时，为它单独签发一个权限最小的令牌
怎么安全地把令牌发给团队成员
不要这样发：
- 丢进群聊
- 放在长期不清理的在线文档里
- 直接提交进代码仓库
推荐这样做：
- 给每个成员或每个客户端单独签发令牌，不要共用一把
- 通过密钥管理工具或安全的环境变量传递
- 必须临时发送时，用完尽快轮换
给每个令牌只开必要的权限
在令牌管理里，按「够用就好」配置每个令牌：
- 只开放这个客户端实际会用到的模型
- 按需要设置过期时间
- 服务端或固定出口的令牌，加上来源 IP 限制
- 给不同团队、不同用途分别签发令牌，让测试流量和生产流量互不影响
这样即使一把令牌泄露，影响范围也被压到最小。
支持 IP 白名单或来源限制吗
支持在令牌上配置来源 IP 限制，适合来源固定的场景：
- 后端服务
- 固定出口的服务器
- CI / 定时任务
个人本地开发不建议一开始就设得太严，换网络时容易把自己挡在外面。对公网可访问的服务，建议同时配合限流，降低被盗刷的风险。
令牌泄露了怎么办
按这个顺序处理，先止损再分析：
- 立刻在令牌管理停用或轮换这把令牌
- 打开「使用日志」检查最近的请求和消耗，看有没有异常
- 再决定要不要收紧模型、分组或来源限制
已经怀疑泄露，就不要再留着旧令牌。
关键配置变更要留痕
调整令牌权限、分组、来源限制这类安全相关的配置时，最好留下记录：谁改的、什么时候改的、改了什么。团队协作时，重要变更走一次简单的审批或通知，能避免「配置被人悄悄改了却没人知道」。
令牌要不要长期保留
不建议所有令牌都设成永久有效。按用途区分：
- 临时测试：设短有效期
- 团队客户端：定期轮换
- 生产服务：用独立令牌，配套固定的轮换流程
401 和 403 跟安全有什么关系
401：令牌本身的问题——没带、无效或过期，先查令牌。403：先看错误文案——额度类（该令牌额度已用尽/用户额度不足）先处理额度；策略类再查分组、模型权限或来源（IP）限制。
完整的错误文案和处理办法见错误与状态码。