安全
智能体可能产生的每一个副作用——写文件、运行 bash、执行 git 推送——都会经过权限策略。
先从 ask 或 deny 兜底开始,再列出应被 allow(放行)、deny(拒绝)或进入 ask(询问)
路径的模式。若要引入人工把关,可加上确认策略:ask 决策会在 confirmation_required
事件处暂停,让你的应用(或人工)对每次调用进行批准或拒绝。只要智能体面向真实仓库运行,
就应使用这套机制。
添加安全提供器
DefaultSecurityProvider 会启用输入污点追踪和输出净化,独立于权限策略对工具的输入输出
进行筛查。通过 securityProvider(Node)/ security_provider(Python)传入;省略则完全
关闭安全功能。
说明
defaultDecision是所有未被allow/deny/ask匹配到的模式的兜底决策(取值为allow、deny或ask之一)。真实仓库优先使用ask,仅对自动化确实需要的部分逐步放开。- 设置
enabled: true的confirmationPolicy才会把ask决策变成会暂停的confirmation_required事件。通过session.confirmToolUse(toolId, approved, reason?)逐个处理;若在defaultTimeoutMs内未收到答复,则由timeoutAction(reject)决定结果。 - 除非最终步骤由受控自动化负责,否则 release 和 publish 操作(
bash(git push*)、bash(npm publish*))应保持在ask或deny路径上。 session.tool()、session.bash()、session.git()这类宿主直接调用都是特权操作。 它们由你的应用代码发起,应在调用 SDK 前先由宿主授权;上面的 permission policy 管控的是send、run和stream内由模型选择的工具调用。
可运行的确认循环示例位于
crates/code/sdk/node/examples/streaming/hitl_confirmation_loop.ts 和
crates/code/sdk/python/examples/hitl_confirmation_loop.py。