临时授权

Beta 功能

临时授权的核心机制已上线，但 4 档预设 TTL、撤销 UI、审计字段对接仍在完善中。功能描述以 v0.2.x 为目标。

它要解决的问题

下面几个场景，传统密码管理器搞不定：

临时支援：同事 Alice 周末帮你看一下 prod 库，但你不想把 readonly 凭据永久给她
一次性 AI 任务：让 Cursor 帮你做一次性的数据迁移，做完就该取消授权
审计需要：合规要求"每次外部访问都有时限 + 责任人"

Sigil 的临时授权一句话讲：签发一个有时限、可撤销、有作用域、有审计的代理 Token。

怎么用

打开 临时授权 页 → "新增授权"。

字段	内容	说明
凭据	选一条已有凭据	这条凭据本身不外发
TTL	30 分钟 / 1 小时 / 4 小时 / 8 小时	到期自动失效
范围	全部 / 白名单 / 黑名单	限定哪些能力可用
持有人备注	"alice@acme - 临时支援"	仅用于审计标识
单次使用限制	可选：最多 N 次调用	用满即失效

确认后获得一个临时 Token：sk_sigil_tmp_xxxxxxxxxx（一次性显示）。

把这个 Token 给到对方，他在自己的 MCP 客户端配置里替换 Authorization 头即可。

它本质上是什么

长期凭据：github-personal（Token: ghp_xxx）
                ↓
                ↓  Sigil 内部"借出代理"
                ↓
临时授权：sk_sigil_tmp_yyyy（仅在 Sigil 范围内有效）
   ├ TTL: 4h
   ├ scope: [git_query, http_request]
   └ max_calls: 50

持有者使用 sk_sigil_tmp_yyyy 调用 MCP：

Sigil 校验它没过期、未用满
在内部替换为 github-personal 的真实 Token
真的去调 GitHub API
脱敏 + 返回 + 审计

持有人从未见过 ghp_xxx——他持有的 sk_sigil_tmp_yyyy 本身在 Sigil 之外没有任何价值。

到期与撤销

触发方式	行为
TTL 到期	立即失效；后续调用返回 `unauthorized`
用满次数	同上
手动撤销	在临时授权列表里点"撤销"，即时生效
凭据被删	关联的临时授权全部失效
Kill Switch	暂停（不撤销）；关闭 Kill Switch 后剩余 TTL 仍可用

撤销和到期都是强一致的——MCP Server 在每次请求时实时查状态，不缓存。

审计字段

经临时授权的能力调用，审计记录的 via_temp 字段会标为 true，并多记几个字段：

字段	例
`via_temp`	true
`temp_id`	tmp_yyyy（前缀 + hash 前段，可定位）
`temp_holder`	"alice@acme - 临时支援"
`temp_remaining_ttl`	02:15:42

事后追溯特别方便：过滤 via_temp = true 就能看到所有"代理使用"。

三个典型场景

场景 1：临时支援

背景：周末有人告警，同事 Bob 帮你看一下生产数据。做法：

选 prod-db-readonly 凭据 → TTL 4h → 范围"仅 db_query" → 备注"bob@acme - oncall"
把临时 Token 通过加密渠道发给 Bob
他配到自己的 Claude Code，查问题、找出根因
4h 后自动失效，你不用做任何操作

完事后看一下审计：via_temp=true + holder=bob 的全部调用，写进事故报告。

场景 2：一次性 AI 任务

背景：Cursor 要帮你做一次性的数据库迁移脚本。做法：

选 staging-db-admin 凭据 → TTL 30min → 范围"白名单：db_query + db_execute" → 单次使用限制 20 次
给 Cursor 用这个临时 Token
它做完一次完整的迁移工作（read schema → write migration script → execute）
用满 20 次或 30min 到期，自动失效

防止 AI 在背后"顺手"做超出意图的事。

场景 3：合规审查

背景：合规要求"每月一次的对账访问需要可追溯到具体人 + 时间"。做法：

每月对账人申请：选 billing-readonly → TTL 8h → 范围"仅 db_query" → 备注实名
完成后审计页 → 过滤 temp_holder → 导出 CSV → 归档

合规审计员拿着 CSV 反查任意一次调用，能定位到"什么人在什么时候用了什么能力查了什么"。

与 Scope Policy 的关系

临时授权的范围是凭据 Scope Policy 的交集子集：

凭据 prod-db-readonly 的 Scope Policy 已经是：
  [db_query, db_execute]
                ↓
临时授权可以从中选子集：
  [db_query]  (✅ 合法)
  [db_query, db_execute]  (✅ 合法 = 全集)
  [db_query, ssh_exec]    (❌ 非法 = 超出凭据范围)

不能用临时授权"扩权"——它只能在凭据已被授予的范围内细化。

比直接给 Token 强在哪

维度	直接给 Token	临时授权
时效	永久	自动到期
撤销	要去源头平台改 / revoke	一键
范围	受 Token 本身权限限制	可继续细化
追溯	看 GitHub / DB 日志	Sigil 审计直接关联 holder
滥用风险	一旦泄漏全盘崩	时限和范围限定，影响面有限

下一步

看完整能力清单：能力体系 →
看审计可以查到什么：审计日志 →
看安全模型：安全总览 →

临时授权 ​

它要解决的问题 ​

怎么用 ​

它本质上是什么 ​

到期与撤销 ​

审计字段 ​

三个典型场景 ​

场景 1：临时支援 ​

场景 2：一次性 AI 任务 ​

场景 3：合规审查 ​

与 Scope Policy 的关系 ​

比直接给 Token 强在哪 ​

下一步 ​