把受限凭据交给智能体

这是 AI 智能体沙箱的凭据部分： 如何铸造一个智能体可以安全持有的密钥，以及如何在不泄露更强密钥的情况下 把它交出去。今天即可使用。

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

1. 发放一个受限的智能体凭据

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

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

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

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

2. 正确地把它交给智能体

在干净的 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. 安全的循环

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

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：

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

它是什么（以及不是什么）

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

破窗应急

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