AI 代理技能的供应链治理边界，不应停留在“技能包是否含有恶意代码”这一层面。对企业而言，真正需要治理的是一条由技能来源、更新机制、代理配置、工具权限、项目上下文和执行环境共同构成的信任链。技能可能由指令文件、脚本、配置和工具描述组成，即使没有传统意义上的二进制插件，也可能改变代理的决策路径和操作范围。
边界首先在“内容”与“能力”之间
技能本身只是风险载体，代理被授予的能力决定了风险上限。一个只能读取当前工作区的技能，与能够修改文件、执行命令、访问网络或读取凭据的技能，不应采用同一套准入标准。前者的影响相对可控，后者已经接近高权限软件组件，必须纳入软件供应链治理和身份权限管理。
因此，企业审核技能时，不能只核对名称、下载来源或文件哈希，还要回答四个问题：谁发布，改了什么，能访问什么，如何撤销。哈希可以确认内容是否变化，却不能证明发布者可信；来源可信也不意味着技能拥有合理权限。技能的版本、来源、变更记录和审批状态，应进入企业内部组件目录，并保留可回滚的旧版本。
自动更新是治理边界的分水岭
公共仓库、个人仓库和无法审计的自动更新链路，不应直接进入核心研发环境。更稳妥的做法是由受控源同步技能，在隔离环境检查后，经代码所有者和安全团队审批，再分发到开发环境。对于拥有命令执行、批量读写或网络访问能力的技能，自动更新尤其应改为人工审批或受控更新。
权限隔离同样不可后置。代理应尽量运行在容器、虚拟机或短生命周期远程环境中，只能写入当前工作区或临时目录，不能接触生产凭据、个人密钥和无关源码。企业还需记录技能版本、代理账号、命令摘要、文件路径和网络目的地，以便发现异常后完成溯源、凭据轮换和快速回滚。
这套边界的核心不是全面禁止 AI 代理，而是把“可被代理理解的内容”视为供应链对象，把“可被代理调用的能力”视为权限对象。只有来源可审计、权限可限制、行为可监控、版本可撤销，技能才适合进入企业研发流程。