把 AI 关进沙箱，就能放心让它操作业务了吗？
企业开始让 AI 动手以后，一个很自然的想法是：先给它划一块地方。
只允许读取指定文件，只能连接几个必要的网站，不能随便操作整台电脑。即使模型理解错了任务，或者读到了不可靠的内容，也尽量把影响限制在可控范围内。
11月5日，微软在安全产品月度更新中再次介绍了 Microsoft Execution Containers，简称 MXC。它为 AI 工作负载提供由操作系统执行的隔离边界，限制对文件、网络、进程和界面等资源的访问。这个方向的正式可用公告发布于10月7日。
这类能力很有价值。让一项工作只能使用它需要的资源，企业才更有条件把任务交出去。原来靠提示词反复强调的“不要碰那些文件”，可以获得实际的执行约束。
不过，当工作区开始连接订单、库存、支付和客户系统时，还要继续追问：允许 AI 进入的地方，究竟允许它发生什么？
设想一家连锁企业，运营人员让 AI 整理当天的退款申请，把符合常规条件的列出来，供财务处理。
技术团队给它配置了隔离环境：只能连接商城域名，文件也只能写入临时目录。为了查询订单，它还接入了一个能够访问后台的业务账号。
在这个假设里，额外的业务动作限制尚未配置。AI 查完订单，发现一笔申请理由充分，便继续调用同一系统里的退款功能。账号恰好有权限，接口也接受了请求，退款真正发生了。
整个过程没有访问陌生网站，没有读取个人文件，也没有逃出隔离环境。
技术团队设置的资源限制可能全部生效了。问题发生在允许访问的系统内部：整理退款申请，为什么变成了决定并执行退款？
限制 AI 能接触的资源之后，企业仍需明确它被委托完成的业务动作。
这与我们使用普通软件时的经验是一致的。
员工能登录财务系统，不代表可以批准里面的每一笔付款；能查询所有门店的库存，也不代表可以把货调往任意门店。系统入口、岗位权限和一次具体工作所允许的范围，本来就有不同含义。
AI 让这件事变得更值得关注，是因为它会根据目标选择下一步。人说“帮我处理一下”，它可能整理资料，也可能试着把整件事办完。如果执行环境只知道它可以进入哪些地方，就还需要其他机制判断，这一步是否在本次委托之内。
因此，隔离环境的完整与业务授权的完整，需要分别检查。
微软自己的文档也明确提醒：隔离限制工作负载的能力，却不会自动让生成的指令、输出或获准执行的动作变得可信；策略应由可信的宿主代码决定，结果也需要验证。
沿着这个边界往下看，企业需要补充的内容就更具体了。
同一个商城域名里，有查询订单、修改地址、申请退款、审核退款等许多能力。即使已经只开放退款能力，退款对象属于哪家门店、允许退多少、是否已经退过、由哪个岗位决定，仍然会改变一次操作能否成立。
“可以退款”还要落到“可以对哪些订单，在什么条件下，依据谁的决定退款”。到了这一步，规则才真正贴近企业准备承担的后果。
这也说明，给 AI 单独建一个账号，虽然有助于区分执行渠道，却仍然需要定义这个账号承接了怎样的委托。若直接复制管理员权限，新的账号名并不会自动缩小它能造成的影响。
回到刚才的场景，可以先让 AI 完成订单查询和退款清单整理。如果任务需要进一步执行，就把允许的订单、金额范围和决定依据一起明确下来。
其中一部分工作完全可以预先授权。例如，组织可以制定规则，让符合明确条件的小额重复扣款自动进入退款流程，按该规则检查后执行。此时，系统应记录适用的自动化规则及检查结果，无须把每笔操作都包装成人工逐一批准。
另一部分工作需要财务作出决定。财务确认的应是具体退款事项；执行时应核对实际提交的对象和金额是否仍与确认内容相符。模型在对话里说“财务已经同意”，不能替代这个检查。
这样做的目的，是把企业愿意交出去的工作交得更完整。条件清楚的可以自动完成，超出范围的再交给相应岗位，避免每一步都找人点击，也避免把所有决定都交给模型临时揣测。
真正落实时，这些限制还需要放在请求必须经过、且 AI 不能自行改掉的地方。
如果只在一个工具入口限制退款，而同一个 Agent 仍能带着相同权限直接访问退款接口，它就还有另一条路。同样，把审批放在一个单独页面，并不代表已经形成可靠的人工确认；如果 AI 也能自行操作那个页面，问题仍然存在。
重要的是，实际业务变更是否必然经过有效检查。检查可以由已有业务系统、授权服务或接入层共同完成，具体如何安排，要看现有系统具备什么能力。
如果某个网关已经能按具体订单、金额和委托条件限制操作，这正是在落实业务约束。企业可以复用它。共同语言的意义，是让不同组件能准确理解并传递这些要求，减少接入时的歧义。
而最终提交时，业务系统仍要看当前事实。
财务同意退款以后，订单可能已被其他渠道处理；执行过程中，员工权限也可能变化。之前的确认提供了行动依据，但实际请求到达时，订单状态、主体权限和业务条件仍需要检查。
这里还有一个容易被忽略的认识：沙箱不一定是一个“做错了也无所谓”的演练场。
一个隔离环境完全可能被允许连接生产系统。AI 在里面使用受限文件、受限网络，也可能通过被允许的接口发出一笔真实付款。只要这条连接保留，相关业务后果就可能真实发生。
关闭沙箱，也不会让已经成功提交的退款自动消失。一次请求失败或超时，能否重试，同样要结合业务状态判断。运行环境的边界与远端业务的结果，需要能够对应起来。
这会影响企业评估 AI 项目的方式。
过去，验收可能侧重“它是否能完成任务”，安全检查则侧重“它是否能访问不该访问的资源”。现在还值得增加一组测试：资源都允许访问时，AI 会不会做出超出委托的动作？系统能不能拦住？
例如，同样给它商城访问能力，分别安排三个任务：只整理退款清单、按有效规则处理指定订单、对一笔尚未获准的退款尝试提交。
第一种应完成整理，第二种应顺利办成，第三种应停在需要补充决定依据的位置。检查时既看对话，也看实际订单和资金状态。若只是界面显示“已阻止”，业务却已经发生，边界仍未成立。
同时，也要检查合法任务有没有被无谓阻断。什么都不能做的环境容易获得表面的安心，却很难产生业务价值。好的约束应让获准工作可靠地完成，让超出范围的请求获得清楚的解释和处理路径。
这正是我们持续推进 A2B、ACC 和 BailingHub 的原因。
我们用 A2B，Agent-to-Business，描述智能体接受人或组织的委托，进入业务系统办理真实事务的这类场景。关注点包括机器如何接入，也包括它如何代表委托方行动，以及业务后果如何被确认和承接。
从一套系统走向多套系统，这些问题会反复出现。商城把“审核通过”理解成财务决定，客服系统可能只是表示材料已经核对；同一句“可以处理”，到了不同系统里，可能对应不同动作。协作越广，越需要把含义说清楚。
ACC 是我们围绕这类问题整理的开放能力契约参考，尝试让能力范围、主体要求、风险和审批意图等信息有共同的表达方式。这样，接入方可以在调用前理解相应要求，执行方也能据此安排检查，而不必每接一个入口都重新解释一遍。
声明本身还需要运行机制落实。BailingHub 把相关思路做成可运行的开源控制面，让能力开放、人工介入和执行记录等安排进入实际业务链路。业务系统则继续保留最终权限和业务状态检查。
这些工作可以与资源隔离、身份管理及已有审批体系协作。我们的长期目标，是让不同的 AI 进入不同的业务系统时，都能按照共同可理解、可检查的行动规则办事。
当企业换模型、换客户端，甚至把一部分工作交给新的设备和机器人时，工作入口可以变化；允许谁对哪些业务作出什么动作、依据什么决定、结果如何核实，仍然需要清楚。
这类规则积累下来，自动化范围才有条件持续扩大。企业可以根据实际表现，把更多工作从临时确认变成明确委托，把员工的精力留给真正需要判断的例外。
AI 越来越能干，执行环境也在变得更可控。接下来值得认真建设的，是它在可控环境里与真实业务发生关系的方式。
当我们允许 AI 进入一间办公室，还需要让它知道，这次受托来办什么事；真正办事时，也要有系统把这份委托守住。
拓展阅读
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)