把受限凭据交给智能体

发放一个按能力、项目和过期时间受限的 API 密钥，并安全地让 AI 智能体对你的数据库运行。

这是 Agent-Safe Change Control 的凭据部分：如何铸造一个智能体可以安全持有的密钥，并在交出它时不泄露一个更强的密钥。执行部分——预算、通道、风险检查、提升策略——是 Guardrails。今天即可使用。

对智能体安全的凭据是一个带有三重边界的 Kisenon API 密钥—— 能力、范围和过期时间——并在干净环境中交给智能体。一句话的规则：限定智能体凭据的范围，并且不要把一个更强的凭据留在智能体够得着的地方。

1. Provision a scoped agent credential

铸造一个三个维度全部设定好的 API 密钥：

capability = agent —— 可以驱动沙箱，但 keon connection-string main（以及每一条可写 main 的路由）都会返回 403。智能体可以提议变更；它绝不持有能写入生产环境的凭据。
scope = project —— 限定于单个项目。一次泄露无法触及你的其他项目。
expires_at（短） —— 泄露时爆炸半径有界。以天计，而非永久。

在控制台中铸造它——在 kisenon.com 的 Settings → API keys 中——设定 Capability = agent、Scope = 某个项目 以及 Expires。API 密钥从已登录的浏览器会话中铸造；一个普通的 CLI 密钥无法铸造另一个密钥。在可写 main 的路由上使用该密钥会精确返回：

agent-scoped API keys cannot retrieve data-plane credentials or perform
branch-admin role/database operations; use the sandbox flow

2. Hand it to the agent correctly

在干净的 shell 或容器中，把受限密钥作为智能体的唯一凭据交给它：

export KEON_API_KEY=nsk_<agent-key>   # the scoped agent key, and ONLY this
unset DATABASE_URL                    # no full connection string in the env
# also: no personal `keon login` session (no ~/.config/keon/credentials.json),
# no ~/.pgpass, no admin DATABASE_URL reachable from the agent's process.

两部分规则，两者都必须：

限定你交给智能体的凭据的范围（第 1 步）。
移除它本可捡起的更强凭据——一个完整的 DATABASE_URL、一个 ~/.pgpass，或同一 shell 中已登录的 keon 会话。

3. The safe loop

智能体提议；由人——或它自身有界的提升——来定夺：

keon sandbox run \
  --migrate "alembic upgrade head" \
  --verify  "pytest tests/db"

keon sandbox run 会 fork 该分支，把一个短期的智能体令牌铸造进一个隔离的 home，并把 fork 的受限 URL 作为 DATABASE_URL 注入到你的命令中——因此即使一个在沙箱内尝试 keon connection-string main 的命令也会撞上智能体密钥并得到 403。审阅捕获的 diff，然后按项目的 promote_mode 进行提升：

`promote_mode`	由谁提交到 `main`
`self`（默认）	检查通过后，智能体运行 `keon sandbox promote <id>`。
`human`	智能体提议；owner/admin 在审阅 diff + 日志后运行 `keon sandbox approve <id>`。

使用 keon projects update --promote-mode human 开启人工审核。

What this is (and is not)

它是给协作型智能体的护栏，而非给敌意代码的牢笼。 限定凭据的范围只限制你交给智能体的东西；它并不能约束一个已经拥有主机文件系统或网络访问权限的子进程。真正的隔离——一个净化过的环境、无法访问主机凭据、出站流量仅限于沙箱端点——是另一层。当智能体的代码不可信时，也请加上这一层。
cp 是 main 的唯一写入者。 提升在服务端重放捕获的语句；智能体绝不持有可写 main 的凭据。

Break-glass

按照设计，不存在特殊的"破窗应急"开关。直接可写 main 的路径只是由人持有的一个普通 read_write 凭据（keon connection-string main，或控制台）——特意做成从智能体密钥无法触及。对于经过审计的事件处置路径，运维人员使用自己的 read_write 会话；每一次提升和批准都会在服务端归因。