企业把 AI 助手分发给客户或内部终端用户时，安全评审常先问两件事：它能不能联网？它能不能写文件、跑命令？这两问不该等到上线前才讨论。更稳妥的顺序是：先按「这个应用」定死能力边界，再谈每次调用时要不要弹确认。
近期行业讨论也在强调同一顺序。NIUX 2026-10-22 周刊转述 Eon 在多云 MCP 接入上的做法：先盘点工具与敏感数据，明确谁能读、写，再让模型用工具；统一网关把散落在本机的凭据改成可审计、可撤权的链路。InfoQ（腾讯新闻同步，约 2026-10-10）谈生产环境 MCP 时进一步指出：网关只能管认证、授权与审计的一部分，执行路径、出站信任与工具定义漂移还要另设强制点——出站限制和作用域令牌是其中一层。QuestMobile 2026 年三季度报告显示，办公类 Agent 在 PC 客户端用户规模同比约 +512%，助手从「聊天框」进入「能动手的生产力入口」；能动手，就更要先答「这个应用默认允不允许动手」。
本文回答应用级能力边界怎么定，以及它和运行时权限确认差在哪里。它不是完整接入教程，也不承诺绝对安全。
行业问题先答完：默认该关什么
把助手交给客户前，至少要分开三层：
- 应用有没有这项能力——产品形态层面：这个应用该不该出现写文件、Shell、联网搜索、外接 MCP。
- 这一次调用要不要人点确认——运行时权限：某次
write或某次 MCP 工具是否询问用户。 - 业务上能不能动这条数据——你们自己的登录、租户隔离与接口授权。
三层不能互相替代。只做第 2 层弹窗，却在第 1 层默认放开 Shell 和联网，评审时仍会问：万一确认通道失效、或模型连续发起危险调用，应用边界在哪里？InfoQ 文中「出站信任」一层也说明：工具名在允许列表上，并不等于它能访问任意外网目标。
因此，给客户分发前，更合理的默认是：写文件、改文件、Shell、联网抓取/搜索/HTTP、MCP、Skills 先关；只读检索与业务自定义工具按需开。 需要哪一项，再在控制台为该应用显式打开，并留下变更记录。紧急撤回时，还要能停掉仍在跑的会话——只改配置不保证旧会话立刻丢工具表。
Tansr 怎样把「应用有没有」落到装配
Tansr 把「这个应用有没有该能力」做成平台按应用配置的能力位，经应用 bundle 下发。令牌档下，SDK 在装配期按能力位裁剪工具，平台网关再做一次硬校验。版本基线以资料站为准：当前公开页写 @tansr/sdk 0.19.0 / @tansr/serve 0.15.1（均已于 2026-10-10 发布）。
创建应用时先选平台类型，它决定「能力与配额」可配范围与缺省档，并随 bundle 的 app.platform 下发：
| 类型 | 适用 | 能力面要点 |
|---|---|---|
| 桌面应用 | Electron 等，SDK 进程内 | 工具位与平台位均可按应用配置 |
| 移动应用 | Android / iOS / 鸿蒙，经你们的会话服务 | 文件/命令族固定关；公网工具缺省关，在服务端执行 |
| 服务端应用 | Node 后端嵌 SDK | 能力面同桌面 |
一应用一平台，多端多 appid，便于分吊销面、分用量归因。
平台缺省档偏保守。资料站「能力位」表写明：tools.write、tools.edit、tools.shell、tools.webFetch、tools.webSearch、tools.http、tools.mcp、tools.skills、tools.agent 等缺省关；read / glob / grep / list / todoWrite / askUser / customTools 缺省开。媒体与平台联网通道相关平台位也缺省关。联网搜索是唯一同时占用两道门的能力：tools.webSearch（会话词表允不允许出现该工具）与 platform.webSearch（平台计费搜索通道有没有给这个应用开通）；SDK 形态没有「自带搜索商密钥」的旁路——那正是应用密钥防盗模型要避免的反模式。
装配时还有一条可读的失败约定：
- 代码显式点名一项已被关闭的能力 → 直接
capability_disabled，消息含控制台修复指引，不会静默少装一个工具。 - 词表外名字 →
invalid_options。 - 选项里不写该项 → 按位「有则用之」静默收缩，不把缺席当成强制主张。
令牌档不能在代码里传 capabilities 覆盖平台下发；能力位恒由 bundle 供给。改移动应用能力位后，新建会话或从存储重新装配的会话才带上新工具表；换票与提示词刷新不会改活动会话的工具表。紧急撤回要停止对应会话。
能力位解决什么、解决不了什么
原来要自行组织的： 在客户端或进程配置里散落开关、靠约定「别打开某工具」、或等用户每次确认才发现应用其实装了 Shell。分发后难以证明「这个应用默认不能写盘、不能联网」。
Tansr 接手的： 按应用下发能力位；装配期裁剪；网关再校验；显式主张被关能力时 fail-fast 报 capability_disabled。移动拓扑下文件/命令族固定关，公网工具即便开启也在会话服务主机执行，不由手机代发。
应用因此能完成的： 安全评审可以指着「应用级默认关写文件 / Shell / 联网 / MCP」说明分发边界；开发联调时关掉的能力不会「看起来偶发没工具」，而是立刻可读报错。
仍须你们配合的： 业务数据授权、操作系统权限、MCP 服务自身的出站与凭据最小化、运行时权限确认与审计。能力位不等于业务授权，也不等于操作系统隔离，更不替代单次工具确认。不承诺绝对安全。
什么时候不必先关这些位
若助手只做纯文本生成、从不装配本地工具与 MCP，能力位表对你几乎无感——但仍建议在控制台确认应用类型与缺省档，避免后续加工具时从「全开」起步。
若你们完全自管模型与工具、不走平台令牌档 bundle，则应用级能力位合同不适用；出站与工具边界要在你们自己的网关与策略里落实——这与 InfoQ 强调的分层控制并不冲突，只是强制点换了位置。
说明见 平台装配与 bundle。本文对照 2026-10-23 资料站，未在控制台逐一点开「能力与配额」截图，也未实际触发 capability_disabled 留运行日志。
