jev模型本身不处理权限，权限控制必须由调用方在api入口层、问题定义、响应路由及日志审计四方面自主实现。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Jev 模型本身不处理权限设置，它的响应格式里没有权限字段、不包含访问控制逻辑、也不执行鉴权动作。它只做一件事：根据你传入的 state（状态文本）和 questions（预定义的问题），返回结构化判断结果——比如选哪个选项、打几分、是不是——每个答案附带概率和置信度。
权限控制这件事，必须由调用方系统自己实现，放在 Jev 的上游或下游。你可以把它理解成：Jev 是个“裁判”，但谁有资格递上比赛录像（state）、谁有权查看裁判打分（response）、谁被允许提哪类问题，这些全得靠你自己的服务来管。
1. 权限应设在 API 调用入口层
Jev 通过 HTTP 接口调用（如 POST https://taotoken.net/api），真正的权限控制点是：
- API Key 管理：每个 Key 对应一个调用方、一个环境、一个预算。TaoToken 控制台支持按项目/团队/环境创建独立 Key，天然隔离权限。
-
Key 绑定角色与范围：比如 dev 环境 Key 只能调用
jev-preview，staging Key 不允许使用score类型问题，生产 Key 需双因素确认才可调高阈值。 -
请求头或参数校验：你的网关可在转发前检查
X-Project-ID、X-Team等自定义头，拒绝未授权来源。
✅ 建议做法：用 Nginx 或云厂商 WAF 设置 IP 白名单 + Key 白名单 + 请求路径限制（如只允
/v1/decide）。
2. 权限也体现在问题定义（questions）中
Jev 允许你在一次请求里提交多个问题，但每个问题的类型（Choice/Score/Noul）和选项范围，本身就是一种“语义权限”：
-
Choice问题必须显式列出所有合法选项，模型不会跳出这个集合； -
Score问题需指定有序图例（如["low", "medium", "high"]），模型只在这三个等级间打分； - 如果某业务线无权判断“客户影响严重性”，那它的服务就根本不构造那个 Score 问题。
✅ 实际控制方式：把
questions的 schema 做成配置项，由权限中心动态下发。例如管理员关闭某租户的Noul类型开关后，其 SDK 自动过滤掉所有"type": "noul"问题。
3. 响应内容本身无需加权限字段，但要用好置信度做策略路由
Jev 返回的每个答案都带 confidence（仅 Choice/Score）或完整概率分布（Noul），这可以成为你权限决策的依据：
- 低置信度响应（如
confidence ）可触发“仅限高级权限用户查看”逻辑； - 某些高风险判断（如“是否涉及金融欺诈”）的结果，只对
role: fraud_analyst开放原始概率分布，普通客服只能看到{"decision": "review"}这种脱敏摘要。
✅ 示例路由逻辑：
{ "question": "Is this refund request valid?", "type": "noul", "response": { "yes_prob": 0.92, "confidence": 0.88 } }→ 若当前用户角色为
agent，返回"action": "auto_approve"；
→ 若为trainee，则返回"action": "escalate"并隐藏yes_prob。
4. 日志与审计权限必须独立建设
Jev 不记录谁调用了它、为什么调用、结果怎么用。这部分责任完全落在调用方：
- 所有请求必须打标：
project_id、env、user_id（或 service account ID）； - 响应结果入库时，脱敏敏感字段（如原始 state 文本），只存
question_id+answer+confidence+timestamp； - 审计日志需支持按权限组回溯：“过去24小时，哪些 team 触发了
score类型且 confidence
✅ 工具建议：用 OpenTelemetry 打点，结合 Loki + Grafana 做权限维度查询。
不复杂但容易忽略。
