Agent会话不是沙箱：微软这次把两个最容易混的隔离轴拆开了
内容提要
微软指出，Agent 的用户身份与沙箱会话是两条独立隔离轴：身份决定数据访问权限，会话 ID 对应代码与文件沙箱，二者不应合并为同一 session 字段，否则易导致跨用户数据泄露。托管会话不等于对话。实践中需在服务端做授权映射、校验身份、限制沙箱复用与凭据，并测试拒绝路径。
延伸解读
身份与沙箱：两条轴为何不能合并
文章强调，用户身份决定数据访问权限，而沙箱会话ID对应代码与文件隔离环境。若将两者绑成同一个session字段，同一用户的不同任务可能共享临时文件，跨用户也可能复用沙箱，导致数据泄露。解耦后，身份由可信中间层传递，沙箱ID由服务端授权后复用，业务规则可显式决定是否共享。
托管会话不等于对话：生命周期差异
官方指出，Foundry hosted session不是conversation。对话保存消息与工具调用历史，托管会话保存沙箱计算环境和持久文件。删除聊天不一定删除文件，恢复聊天也不一定恢复同一运行环境。应用可以一对一映射，也可以显式选择不同映射，但必须理解两者生命周期不同，避免误以为删除对话就清理了沙箱。
三个常见陷阱与日志隔离
文章列出三个坑：把对话ID当沙箱ID、相信前端传来的用户标识、为省冷启动共享沙箱。此外，日志也是隔离面的一部分，若追踪系统将不同租户的Prompt、工具参数和文件名写入同一可搜索索引，运维或调试Agent仍可能跨边界看到数据。日志应带租户标签、访问控制和保留期，敏感值默认脱敏。
上线前需回答的问题与测试
文章建议上线前回答五个问题：谁认证用户、谁创建沙箱、谁能恢复它、沙箱多久销毁、删除用户数据时哪些对象要级联清理。并补充三类测试：用户A枚举不到用户B的会话；旧沙箱不能读取新任务凭据；中间层伪造或缺失身份时默认拒绝。同时注意，Foundry托管Agent已正式可用，但相关SDK仍为预发布版本，接口和恢复行为需按锁定版本复核。
Q&A
微软提出的Agent双轴隔离具体指哪两条轴？
一条是用户身份轴，决定请求代表谁、能访问谁的数据；另一条是沙箱会话轴，对应代码与文件所在的虚拟机隔离环境，决定旧文件和进程可能被谁复用。
为什么不能把用户身份和沙箱会话合并成一个session字段？
合并后容易导致跨用户数据泄露。例如同一员工的不同任务可能共享临时文件，或不同用户复用同一沙箱，从而越权访问数据。是否共享应由业务规则决定，而非SDK对象的生命周期。
Foundry托管会话和对话有什么区别？
对话保存消息与工具调用历史；托管会话保存沙箱计算环境和持久文件。二者可以一对一，也可以由应用显式选择不同映射。
在服务端实现双轴隔离时，身份和沙箱ID应如何校验？
可信中间层先认证用户，再传递稳定、不可猜测的委托标识；用户身份必须每次校验，沙箱ID必须在服务端授权后才能复用。前端传来的任意agent_session_id不能直接当作访问票据。
实施双轴隔离时最容易踩哪些坑？
三个常见坑：把对话ID直接当沙箱ID；相信前端传来的用户标识；为省冷启动把所有人放进共享沙箱。这些做法可能导致文件未清理、身份伪造或横向越权。
上线前需要回答哪些关键问题并做哪些测试？
需回答：谁认证用户、谁创建沙箱、谁能恢复它、沙箱多久销毁、删除用户数据时哪些对象要级联清理。并补三类测试：用户A枚举不到用户B的会话；旧沙箱不能读取新任务凭据；中间层伪造或缺失身份时默认拒绝。
