企业官网建设流程全解析

目录

一、Agent 安全的核心矛盾：能力越强，环境风险越高

（一）从聊天窗口到行动系统，风险发生了质变

1. 传统应用的权限通常是静态的

2. 模型不会自动理解企业边界

（二）Agent 的四类高风险能力

1. 代码执行：错误可以从文本变成进程

2. 外部连接：请求的目标与语义都可能失控

3. 凭证使用：能用不等于应该看见

4. 持久化变更：一次误判可能跨越多个系统

（三）安全目标不是“完全不出错”，而是把错误关在可接受边界内

1. 限制爆炸半径

2. 让高风险动作可暂停、可复核、可撤销

3. 让每一次执行都能还原

二、Tines 3B：把 Agent 行动放进企业治理平面

（一）它首先是一个构建、运行与治理环境

1. 不是把聊天机器人接上几个 API

2. Code-first 不等于 code-only

（二）Credential Proxy：把“持有密钥”改造成“申请一次受限请求”

1. 凭证与连接器绑定，而不是散落在步骤里

2. 出站请求在代理处完成认证

3. 代理解决了什么，又没有解决什么

（三）一次性容器与 gVisor：Tines 3B 的执行边界

1. 每个步骤是一次独立执行

2. 一次性不是“没有持久化”，而是“持久化必须显式发生”

3. gVisor 是强化容器，不是 microVM

（四）治理优势与适用边界

1. 优势在于统一控制面

2. 平台能力不能替代企业自己的安全设计

三、microsandbox：把不可信代码关进独立 microVM

（一）它解决的是运行时原语问题

1. 每个沙箱拥有自己的 Linux 内核

2. 本地优先与嵌入式生命周期

（二）隔离强度来自边界设计，而不只是“用了虚拟机”

1. 宿主侧进程无需默认以 root 运行

2. 客体与宿主只通过有限设备接触

3. 客体内部默认宽松，强化配置仍然必要

（三）网络默认值比“有无网络”更重要

1. 默认允许公网，不等于默认允许所有地址

2. 域名允许列表必须抵御 DNS 绕过

（四）Secrets：让真实值只在网络边界出现

1. 客体拿到的是占位符

2. “Secrets that can’t leak”有明确前提

3. Secret 来源本身也要安全

（五）工程优势与现实限制

1. 适合做可嵌入的安全执行底座

2. 它仍是底层能力，不是完整治理平台

四、Tines 3B 与 microsandbox 不是二选一，而是两个控制平面

（一）用“治理平面—执行平面”重新理解两者

1. 治理平面决定允许什么

2. 执行平面决定如何把风险关住

（二）三种常见落地模式

1. 采用 Tines 3B 的一体化模式

2. 基于 microsandbox 自建模式

3. 分层组合模式

（三）与普通 Container 的关系

1. Container 是打包与隔离基础，不是完整安全答案

2. 选择隔离强度要看工作负载，而不是追逐名词

五、从提示注入到宿主逃逸：一套面向 Agent 的威胁模型

（一）不要只问“能否逃逸”，还要问“逃逸之前能做什么”

1. 提示注入控制行动计划

2. 工具混淆放大权限

（二）五条典型攻击链

1. 文档提示注入 → 工具滥用 → 数据外传

2. 恶意依赖 → 安装脚本执行 → Secret 读取

3. SSRF → 云元数据 → 临时凭证横向移动

4. 合法连接器 → 过宽账号 → 业务破坏

5. 沙箱逃逸 → 宿主控制面受损

（三）可信计算基必须写清楚

1. Tines 3B 场景中的可信组件

2. microsandbox 场景中的可信组件

3. 第三方模型与工具也在边界内

六、企业级“受控工作间”的参考架构

（一）六道边界缺一不可

1. 身份边界与能力边界

1.1 默认不继承发起人的全部权限

1.2 工具目录应按风险动态裁剪

2. 凭证边界与执行边界

2.1 凭证以句柄进入任务

2.2 执行环境默认一次性

3. 网络边界与审计边界

3.1 记录决策，而不只是记录结果

3.2 审计链应支持重放与对账

（二）一条完整请求应该如何流动

1. 任务进入与预授权

2. 计划生成与高风险断点

3. 沙箱执行与受控出口

4. 结果校验、提交与销毁

（三）推荐的策略对象

1. 主体、任务与数据

2. 工具、凭证与目标

（四）日志与隐私要同时设计

1. 全量日志不等于高质量审计

2. 可观察性指标要能支持运营

七、落地路线：从试验性沙箱走向企业运行平台

（一）第一阶段：建立最小可信执行单元

1. 只做低风险、只读任务

2. 先证明“拒绝”有效

（二）第二阶段：引入连接器与凭证代理

1. 用低权限服务身份替换个人 Token

2. 为允许目标建立自动化测试

（三）第三阶段：增加写操作与人类审批

1. 把批准对象变成结构化变更集

2. 使用草稿、事务和幂等设计

（四）第四阶段：平台化与红队化

1. 统一策略与证据

2. 持续攻击验证

八、选型与验收：不要比较功能清单，要比较可证明的边界

（一）先问十个决定性问题

1. 业务与治理问题

2. 技术与安全问题

（二）Tines 3B 的重点验证项

1. 平台治理与连接器

2. 执行与运营

（三）microsandbox 的重点验证项

1. 宿主与 microVM 边界

2. 网络、Secret 与平台配套

（四）一份可执行的验收清单

1. 必须通过

2. 建议通过

九、结论：安全的 Agent 不是“更聪明”，而是“被正确地限制”

（一）真正的突破是把权力从上下文移到边界

（二）最可靠的架构结论

可参考的文章与资料

干货分享，感谢您的阅读！

截至目前，Tines 3B 与 microsandbox 代表了两条相互补充的路线：前者从企业工作治理出发，把连接器、凭证、执行、监控和权限组织到一个统一平台；后者从运行时出发，用独立 microVM 承载不可信代码，并把文件、网络、资源和密钥注入做成可编程边界。它们不是简单的竞品，也不能被粗略概括为“一个企业版、一个开源版”。更准确的理解是：Tines 3B 主要回答“谁可以让 Agent 对哪些业务系统做什么”，microsandbox 主要回答“这段不可信代码应该在哪里、以什么资源和网络边界运行”。

本文不是对两份产品说明的改写，而是以它们为样本，重建一套可用于真实工程决策的 Agent 安全框架。文中涉及产品能力的描述以官方公开资料为依据；涉及组合架构、成熟度模型、威胁分析和落地方法的部分，是在这些资料之上的独立分析。

受控工作间不是一个“沙箱按钮”，而是身份、能力、凭证、执行、网络和审计六道连续边界。

一、Agent 安全的核心矛盾：能力越强，环境风险越高

（一）从聊天窗口到行动系统，风险发生了质变

1. 传统应用的权限通常是静态的

传统业务应用在上线前已经明确了页面、接口、数据库表和服务账号。开发者写下确定的代码路径，安全团队可以围绕身份认证、访问控制、依赖扫描、变更审批和运行监控建立相对稳定的防线。即使应用存在漏洞，攻击面通常仍由既定接口与部署结构限定。

Agent 则不同。它把自然语言目标转换为一串动态行动：阅读文件、生成程序、安装依赖、执行 Shell、查询知识库、调用 SaaS API、写入数据库，甚至再委派给其他 Agent。每一次推理都可能生成新的命令组合和参数。对安全团队而言，风险不再只是“这项功能是否安全”，而是“在当前任务、当前身份、当前数据和当前上下文下，这个行动是否仍然应该被允许”。

2. 模型不会自动理解企业边界

模型擅长完成目标，却不天然理解组织中的职责分离、数据分级、审批责任和事故成本。提示词中的“不要泄露密钥”“只读不要写入”能够改善行为，但它不是强制执行层。提示注入、上下文污染、错误推理、工具描述歧义或简单的程序缺陷，都可能让 Agent 偏离预期路径。

因此，企业不能把控制目标写进提示词后就宣布安全完成。真正可靠的做法，是让模型提出行动，由模型之外的策略与运行环境决定该行动能否发生。换句话说：意图由 Agent 生成，权限由系统裁决。

（二）Agent 的四类高风险能力

1. 代码执行：错误可以从文本变成进程

当 Agent 可以运行 Python、JavaScript 或 Shell 时，错误不再局限于回答内容。它可能消耗大量 CPU 和内存、递归创建进程、读取意外路径、覆盖工作目录、调用本机 Docker Socket，或利用运行时漏洞逃逸。允许安装软件包还会引入供应链风险：包名混淆、恶意安装脚本、被接管的依赖、构建阶段联网和不可复现版本，都可能绕过对最终代码的表面审查。

2. 外部连接：请求的目标与语义都可能失控

一个“读取工单并生成摘要”的任务，可能需要访问工单系统、对象存储和模型 API。若只给 Agent 通用互联网权限，它也获得了向任意外部站点发送数据的通道；若允许访问内网，它还可能触及元数据服务、管理后台、数据库和开发者机器。即使目标域名正确，Agent 也可能使用过宽的接口或构造危险参数，例如把“查询用户”变成“批量导出全部用户”。

3. 凭证使用：能用不等于应该看见

最常见的做法是把 API Key 作为环境变量注入执行环境。这对普通应用已经有风险，对可执行任意代码的 Agent 尤其危险：代码可以打印环境变量、读取/proc、写入日志、打包工作目录或把密钥发送给外部服务器。只要密钥明文进入工作负载，所谓“不让 Agent 看见”通常就只是界面层面的错觉。

4. 持久化变更：一次误判可能跨越多个系统

Agent 可以创建工单、更新客户信息、提交代码、发送消息、启动部署或删除云资源。单次错误可能经过自动化链路被放大，形成跨系统的连锁反应。OWASP 将“过度代理能力”列为生成式 AI 应用的重要风险，核心原因正是功能、权限和自主性超过完成任务所必需的范围。

（三）安全目标不是“完全不出错”，而是把错误关在可接受边界内

1. 限制爆炸半径

Agent 系统不可能保证模型永远正确，也不可能保证所有依赖永远无漏洞。更现实的目标是：即使某次执行被提示注入控制、生成恶意代码或调用错误接口，影响也被限制在一个任务、一个临时目录、一个低权限身份和一组被批准的目标之内。

2. 让高风险动作可暂停、可复核、可撤销

读取公开资料和删除生产数据不应共享同一种授权方式。系统需要按动作风险引入不同摩擦：低风险动作自动执行；中风险动作受策略和额度限制；高风险动作要求人类确认、双人审批、短时授权或模拟执行。对不可逆操作，还要提前设计备份、版本化、软删除和补偿事务。

3. 让每一次执行都能还原

事故分析不能只保留模型最后一句话。至少要知道：谁发起任务、使用哪个 Agent 和模型版本、看到了哪些输入、调用了哪个工具、传入什么参数、命中了哪条策略、使用哪个凭证句柄、在哪个运行环境执行、访问了哪些网络目标、产生了什么输出，以及是否有人批准。没有这条证据链，所谓“可控”无法被验证。

二、Tines 3B：把 Agent 行动放进企业治理平面

（一）它首先是一个构建、运行与治理环境

1. 不是把聊天机器人接上几个 API

Tines 将 3B 定义为用于构建、运行和监控 Agent、应用与自动化的统一安全环境。其关注点不仅是生成代码，还包括连接器、凭证、隔离执行、运行历史、监控和审计。它试图解决的组织问题，是员工已经借助 AI 生成大量“野生代码”，但 IT 与安全团队看不到这些代码在哪里运行、访问什么数据、消耗多少成本、由谁维护。

这意味着 Tines 3B 的价值单位不是一次模型调用，而是一个可持续运营的工作负载。一个工作流由多个步骤组成；一次完整运行由多个执行记录构成；每个步骤可以有自己的代码、镜像、输入输出和日志。平台把这些对象纳入统一管理，安全团队因此可以在工作流层面而非单个脚本层面观察风险。

2. Code-first 不等于 code-only

官方资料强调 Tines 3B 采用 code-first 思路：步骤可以由 TypeScript、Python 或 Shell 等实现，并以 Dockerfile 描述环境。这样做降低了“可视化编排抽象”对复杂任务的限制，也使 AI 更容易把需求直接转为可运行代码。但 code-first 并不意味着把裸代码直接放到服务器执行；其安全意义恰恰在于，代码被包装成明确步骤，由平台构建、运行、计量和记录。

（二）Credential Proxy：把“持有密钥”改造成“申请一次受限请求”

1. 凭证与连接器绑定，而不是散落在步骤里

在 Tines 3B 中，API Key、OAuth Token、用户名密码或其他认证材料属于连接器。工作流步骤引用连接器，不需要把秘密粘贴进代码。这样可以集中轮换和吊销凭证，也能避免开发者复制工作流时顺带复制秘密。

官方文档描述了多层保护：许多凭证在浏览器端输入时即被封装；存储时使用按租户划分的密钥材料；真正请求发出时才在内存中短暂解封；运行结束后清理。这里最关键的不是“加密存储”四个字，而是明文出现的位置被压缩到受控组件和短暂时间窗口。

2. 出站请求在代理处完成认证

步骤中的代码不直接携带认证信息。出站请求经过 Credential Proxy 后，代理根据连接器和 URL 匹配规则判断是否注入相应认证。Slack 的令牌只应出现在被批准的 Slack 目标，请求若指向其他主机则不能获得该令牌。支持的认证方式包括 API Key、OAuth 2.0、Bearer Token、Basic Auth、AWS Signature V4 和 JWT 等。

代码只提交业务请求，凭证代理在命中连接器与目标规则后完成认证注入；密钥不进入步骤代码。

3. 代理解决了什么，又没有解决什么

Credential Proxy 显著降低了密钥被日志、代码仓库、提示上下文或任意进程直接读取的概率，也为域名级授权和集中轮换提供了控制点。但它不自动保证业务语义正确。一个拥有 CRM 写权限的连接器，即使只向正确域名发送请求，仍可能执行错误更新。因此，凭证代理必须与最小权限账号、接口级允许列表、参数校验、速率限制和高风险动作审批配合。

更进一步说，“目标域名正确”只是必要条件，不是充分条件。企业应把授权拆成三层：连接器决定可用哪个身份；策略决定可调用哪些能力；请求校验决定哪些资源与参数可被操作。只做第一层，仍可能发生“合法凭证执行非法业务动作”。

（三）一次性容器与 gVisor：Tines 3B 的执行边界

1. 每个步骤是一次独立执行

根据官方文档，Tines 3B 会把步骤构建为容器镜像，并在隔离沙箱中运行命令。每次执行都有输入、标准输出、标准错误、状态和耗时；重试会形成新的执行记录，而不是覆盖原记录。构建与运行分离，未变化的镜像层可以复用，从而在隔离与启动效率之间取得平衡。

2. 一次性不是“没有持久化”，而是“持久化必须显式发生”

执行容器在任务完成后销毁，普通工作目录和临时文件不会进入下一次运行；需要跨运行保存的内容必须写入平台的持久化存储层。这个设计把隐式状态变成显式状态：开发者不能依赖某个偶然残留的文件或进程，安全团队也更容易确定哪些数据会长期存在。

3. gVisor 是强化容器，不是 microVM

Tines 3B 官方文档明确指出其执行使用 gVisor。gVisor 通过用户态应用内核拦截系统调用，减少工作负载直接接触宿主内核的攻击面；它兼容 OCI 运行方式，但既不是普通的 Linux namespace 容器，也不是传统硬件虚拟机。把它称为“microVM”会混淆威胁模型：gVisor 的优势是较低固定开销和较强系统调用隔离，代价可能是系统调用密集型负载的性能开销与部分兼容性限制。

构建缓存可复用，但每次运行进入新的单次沙箱；需要保留的状态必须走显式存储。

（四）治理优势与适用边界

1. 优势在于统一控制面

Tines 3B 把业务人员的构建体验与 IT、安全团队的运行治理放在同一平台中。对于需要大量 SaaS 连接、可视化运行历史、集中凭证和跨团队权限管理的组织，这种一体化能显著减少拼装成本。它还支持自托管模式，官方资料给出的路径包括单机 Linux 虚拟机用于评估，以及 Kubernetes 用于生产、高可用和横向扩展；模型供应商则由客户自行选择。

2. 平台能力不能替代企业自己的安全设计

企业仍需确认租户与空间隔离、管理员权限、日志保留、数据驻留、密钥恢复、镜像供应链、网络例外、灾难恢复和供应商退出方案。特别是自托管部署，控制权增加的同时，补丁、集群、镜像、密钥和监控责任也会转移给客户。所谓“安全平台”只是提供可实施控制的基础，不会自动替组织完成风险分级。

三、microsandbox：把不可信代码关进独立 microVM

（一）它解决的是运行时原语问题

1. 每个沙箱拥有自己的 Linux 内核

microsandbox 将每个沙箱实现为轻量虚拟机。官方安全文档说明，沙箱拥有独立 Linux 内核、内存和虚拟 CPU，通过 Linux KVM 或 macOS Hypervisor.framework 等硬件虚拟化能力运行，并由 libkrun 提供虚拟机监控器。工作负载即使攻陷客体内核，首先得到的仍是客体内核，而不是宿主内核。

这正是 microVM 相对普通容器的关键安全差异：普通容器共享宿主内核，命名空间、cgroup、seccomp 和 Linux 安全模块共同构成隔离；microVM 则在工作负载与宿主之间加入硬件虚拟化边界。当然，microVM 并非不可逃逸，VMM、虚拟设备或 Hypervisor 漏洞仍可能突破边界，只是攻击面和防御假设发生了变化。

2. 本地优先与嵌入式生命周期

microsandbox 的 SDK 可以由应用直接创建沙箱子进程，无需长期运行的守护服务；同一套 CLI 与 SDK 也可以使用托管后端。它支持 OCI 镜像与类似 Docker 的镜像、命令、卷和 Shell 工作流，并提供 TypeScript、Rust、Python、Go、Ruby 等 SDK。README 给出的基准描述是部分环境下平均启动时间低于 100 毫秒，但该数字与硬件、缓存、镜像和配置相关，不应直接当作生产 SLA。

宿主通过有限虚拟设备和受控通道管理客体；每个沙箱独立内核、内存、文件层和网络网关。

（二）隔离强度来自边界设计，而不只是“用了虚拟机”

1. 宿主侧进程无需默认以 root 运行

在 Linux 上，启动进程需要访问/dev/kvm，通常通过kvm组获得，而不要求 setuid 或额外 capabilities；在 macOS 上则使用带相应 entitlement 的 Hypervisor.framework。每个沙箱由普通宿主进程承载，这使“客体 root”与“宿主 root”被清晰分开。

2. 客体与宿主只通过有限设备接触

官方列出的主要虚拟设备包括用于控制通道的virtio-console、网络的virtio-net、显式挂载目录的virtio-fs、磁盘的virtio-blk和随机数设备。有限设备集合减少了通用硬件直通带来的攻击面。控制通道由宿主发起，客体返回结果；宿主应把来自客体的每个帧都视为不可信输入。

3. 客体内部默认宽松，强化配置仍然必要

microsandbox 把虚拟机边界视为主要隔离，因此客体命令默认可用 root 运行，以提高现实镜像、init、sudo 和 Docker-in-Docker 的兼容性。但在不可信代码场景中，仍应选择非 root 用户与 restricted profile。后者会设置no_new_privs、减少挂载管理能力，并对用户挂载施加nosuid,nodev。这不是取代 Hypervisor，而是减少客体内部被攻陷后的横向空间。

（三）网络默认值比“有无网络”更重要

1. 默认允许公网，不等于默认允许所有地址

官方网络文档描述的默认姿态是：沙箱可以访问公网与网关 DNS，但私有地址、回环、链路本地、云元数据地址和宿主被拒绝；入站只有显式发布端口可达，且默认绑定宿主127.0.0.1。这能降低 SSRF 访问内网数据库、开发者机器或云元数据凭证的风险。

需要注意，“允许公网”仍然意味着存在数据外传通道。对于会处理敏感文件或使用凭证的 Agent，更稳妥的策略是出站默认拒绝，只允许必要域名与端口；纯计算任务则应关闭网络。最强的网络过滤，是根本没有网络接口。

2. 域名允许列表必须抵御 DNS 绕过

简单的字符串域名列表挡不住 DNS rebinding、检查与连接之间的 TOCTOU、硬编码 IP、SNI 欺骗和域前置。microsandbox 的文档描述了 DNS pin、私网地址重写、SNI 与目标 IP 绑定、HTTPHost或 HTTP/2:authority对齐等检查。对企业来说，这一细节非常重要：网络策略必须约束实际连接，而不是只校验代码里写下的 URL。

（四）Secrets：让真实值只在网络边界出现

1. 客体拿到的是占位符

microsandbox 的 Secret 机制把真实值留在宿主进程内存中，只向客体环境变量放入占位符。当请求发往被允许的主机且满足 DNS、TLS 身份和 authority 等条件时，宿主侧网络栈在出站边界把占位符替换为真实值。发送到其他主机时，占位符仍是无意义字符串。

真实 Secret 留在宿主侧；只有命中目标约束的请求才会在出口处完成替换。

2. “Secrets that can’t leak”有明确前提

这项保证主要防止真实凭证从客体被直接读取，或被发送到未授权主机。它不阻止被允许的目标滥用收到的凭证，也不覆盖宿主进程被攻陷。官方文档还说明了若干边界：Secret 真实值在沙箱生命周期内以普通字符串存在于宿主内存；某些 HTTP/2 请求体、压缩体或超大固定长度请求体不支持替换；TLS 绕过或纯 HTTP 会影响身份校验和替换能力。系统设计者应把这些条件写进验收测试，而不是只引用一句营销口号。

3. Secret 来源本身也要安全

CLI 推荐引用宿主环境变量，而不是把原始值写在命令行；SDK 若直接传入原始值，配置文件可能以明文保存。由此可见，“客体看不到秘密”并不等于“秘密在整个系统中都安全”。密钥管理系统、宿主启动环境、配置落盘、日志脱敏、内存读取权限和轮换流程仍然属于可信计算基的一部分。

（五）工程优势与现实限制

1. 适合做可嵌入的安全执行底座

microsandbox 很适合编码 Agent、用户脚本、插件、CI 任务、浏览器自动化和不可信文档转换等场景。开发团队可以直接在应用中创建一个带 CPU、内存、卷、网络和生命周期限制的沙箱，而不必先建设完整远程执行集群。OCI 兼容也降低了迁移既有工具链的门槛。

2. 它仍是底层能力，不是完整治理平台

仓库目前明确提示处于 beta，可能存在破坏性变更、缺失能力和粗糙边角。使用者还需要自行建设身份与租户映射、策略管理、审批、镜像治理、调度、配额、日志归档、告警、运营控制台和合规证据。macOS 需要 Apple Silicon，Linux 需要 KVM，Windows 需要 WHP；在不支持嵌套虚拟化或受限云实例上，部署方式也要重新评估。

四、Tines 3B 与 microsandbox 不是二选一，而是两个控制平面

（一）用“治理平面—执行平面”重新理解两者

1. 治理平面决定允许什么

治理平面处理人与组织语义：用户属于哪个团队，Agent 被授予哪些连接器，哪些动作需要审批，凭证由谁维护，日志保存多久，预算和速率如何限制，异常由谁响应。Tines 3B 的主要价值集中在这一层，并同时提供自己的隔离执行实现。

2. 执行平面决定如何把风险关住

执行平面处理机器边界：代码在哪个内核和文件系统中运行，能挂载哪些目录，可访问哪些地址，能用多少 CPU 与内存，多久后销毁，如何注入 Secret，怎样收集 stdout、stderr 和网络记录。microsandbox 的主要价值集中在这一层。

治理平面分配任务、身份与策略；执行平面提供单任务隔离、资源边界和受控出口；两者由不可篡改的审计链贯通。

（二）三种常见落地模式

1. 采用 Tines 3B 的一体化模式

适合希望快速建立企业统一入口、以 SaaS/内部 API 自动化为主、需要业务团队自助构建且不想自行维护执行平台的组织。重点评估连接器覆盖、URL 作用域、空间隔离、审批能力、日志导出、自托管责任和高风险工作负载兼容性。

2. 基于 microsandbox 自建模式

适合运行时是核心产品能力、需要本地嵌入、希望完全控制镜像和 microVM 生命周期，或已有 IAM、策略、审计与调度基础设施的团队。它提供更原子的隔离构件，但平台工程与安全工程投入更高。

3. 分层组合模式

大型组织可以让上层 Agent 平台负责身份、任务编排、工具目录、审批和凭证句柄，把高风险代码步骤下沉到独立 microVM 执行。此时必须避免“双重控制假象”：上层策略与下层网络规则要有单一事实来源，任务 ID、主体身份、策略版本和审计 ID 必须贯穿两层；否则事故发生时会出现两套日志无法对应、两套允许列表互相冲突的问题。

（三）与普通 Container 的关系

1. Container 是打包与隔离基础，不是完整安全答案

普通容器具有启动快、密度高、生态成熟和工具丰富的优势。对可信内部代码、低敏数据和稳定依赖，它通常足够。但容器共享宿主内核，NIST SP 800-190 将共享内核、运行时漏洞、无限网络访问、错误配置、恶意镜像和明文秘密等列为需要专门治理的风险。

2. 选择隔离强度要看工作负载，而不是追逐名词

技术团队应评估代码信任度、数据敏感度、多租户程度、内核攻击可能性、性能与密度要求、兼容性、取证需求和运维成熟度。gVisor、microVM、传统 VM 与原生容器各有边界；没有一种技术能单独解决凭证最小权限、业务授权或人为审批问题。

五、从提示注入到宿主逃逸：一套面向 Agent 的威胁模型

（一）不要只问“能否逃逸”，还要问“逃逸之前能做什么”

1. 提示注入控制行动计划

Agent 读取网页、邮件、代码仓库或文档时，外部内容可能夹带指令，诱导模型忽略原目标、调用高权限工具、读取额外数据或输出秘密。即使运行时绝对隔离，Agent 仍可能在被允许的边界内做出不合业务意图的事情。因此，输入信任标记、工具描述最小化、上下文隔离和高风险动作审批与运行时沙箱同样重要。

2. 工具混淆放大权限

一个名称为“同步客户”的工具，底层可能同时具备查询、更新和删除能力；一个通用 HTTP 工具可能绕开所有结构化连接器。工具接口应按任务拆成窄能力，并使用类型化参数、资源范围与动作枚举。Agent 获得的不是“数据库凭证”，而应是“读取指定视图的能力”；不是“GitHub Token”，而应是“在指定仓库创建草稿 PR 的能力”。

（二）五条典型攻击链

1. 文档提示注入 → 工具滥用 → 数据外传

攻击内容让 Agent 读取客户文件，再通过通用网络工具上传。控制措施需要跨层联动：不可信内容标记阻止其提升指令优先级；工具策略限制可读目录；出站默认拒绝阻断未知目标；DLP 识别敏感数据；审计关联读取与网络请求。

2. 恶意依赖 → 安装脚本执行 → Secret 读取

Agent 安装一个名称近似的包，安装脚本尝试枚举环境变量并外传。应使用固定镜像、私有镜像仓库、依赖允许列表与版本锁定；构建阶段和运行阶段分开联网；Secret 不以真实环境变量进入客体；沙箱出站只允许业务目标。

3. SSRF → 云元数据 → 临时凭证横向移动

Agent 被诱导请求169.254.169.254，获得实例角色凭证后访问云资源。防御重点不是要求模型识别该地址，而是在网络边界硬性阻断元数据、私网、回环和链路本地地址，并确保域名允许列表抵御 DNS rebinding。

4. 合法连接器 → 过宽账号 → 业务破坏

Agent 使用正确的域名和正确的凭证，却批量关闭工单或修改客户数据。防御依赖低权限服务账号、只读默认、资源范围、参数约束、速率与金额阈值、幂等键、事务、审批和可撤销机制。这个场景说明：凭证不泄露不等于行为安全。

5. 沙箱逃逸 → 宿主控制面受损

恶意代码利用客体内核、VMM、虚拟设备、gVisor 或容器运行时漏洞突破边界。应通过专用执行节点、无长期云凭证、最小宿主服务、快速补丁、设备面收缩、节点分池、单租户高敏任务、异常系统调用与网络告警，以及执行节点可重建来降低后果。

每一条攻击链至少需要两个独立控制点；仅依赖模型拒绝或仅依赖沙箱都不足以构成纵深防御。

（三）可信计算基必须写清楚

1. Tines 3B 场景中的可信组件

至少包括身份系统、Tines 控制面、Credential Proxy、连接器配置、密钥管理、gVisor 与容器运行时、执行节点、持久化存储、日志与管理员账户。自托管时，还包括 Kubernetes 控制面、镜像仓库、节点 OS、网络插件和备份系统。

2. microsandbox 场景中的可信组件

至少包括创建沙箱的宿主应用、宿主用户权限、KVM/Hypervisor.framework、libkrun 与设备实现、宿主侧用户态网络栈、Secret 来源、镜像与挂载目录。microVM 可以隔离客体，但不能保护一个已经被攻陷的宿主控制程序。

3. 第三方模型与工具也在边界内

若任务数据会发送到外部模型，模型供应商、API 端点、保留策略、区域、训练使用条款与子处理方都属于数据路径。工具返回内容还可能成为下一轮提示输入，形成间接提示注入。供应商无关不等于风险无关，切换模型也不会自动消除数据治理责任。

六、企业级“受控工作间”的参考架构

（一）六道边界缺一不可

1. 身份边界与能力边界

身份边界把每个任务绑定到真实主体、服务身份、租户、设备与会话。能力边界把“可用工具”压缩成任务所需的最小集合，并区分读取、创建、修改、删除和管理权限。策略决策应发生在工具调用之前，执行点则位于无法被 Agent 修改的代理或网关中。

1.1 默认不继承发起人的全部权限

人类用户可能有广泛权限，但 Agent 任务应使用更窄的委托身份。委托应短时、可撤销、绑定任务与目标资源，并能区分“代表某人执行”和“平台服务账号执行”。

1.2 工具目录应按风险动态裁剪

同一个 Agent 在不同任务中看到的工具集可以不同。对只读分析任务，不应向模型暴露删除或部署工具；被策略隐藏的能力最好不出现在工具列表中，减少误调用和提示注入利用空间。

2. 凭证边界与执行边界

凭证边界保证工作负载只能“使用”特定能力，而不持有长期秘密；执行边界保证每个任务在独立、有限、可销毁的环境中运行。二者必须同时存在：只有沙箱而把真实密钥放进去，密钥仍可外传；只有凭证代理而在宿主进程直接执行不可信代码，宿主仍可能被破坏。

2.1 凭证以句柄进入任务

任务上下文包含连接器 ID、Secret 引用或能力令牌，而不是原始值。真实认证只在可信出口组件处出现，并受目标、方法、路径、资源和有效期约束。

2.2 执行环境默认一次性

每个任务使用新的文件系统层、进程树和网络上下文；跨任务状态只能写入显式存储。挂载默认只读，写入范围限定在任务目录；长期卷需要单独审批和恶意内容扫描。

3. 网络边界与审计边界

网络边界应出站默认拒绝，并分别处理公网、私网、宿主、元数据、DNS、TLS 和代理绕过。审计边界则保证 Agent 无法关闭或修改自己的关键日志，且能够把自然语言目标、工具调用、执行记录、网络访问和外部系统结果关联到同一任务。

3.1 记录决策，而不只是记录结果

日志应保留策略输入、策略版本、允许或拒绝原因、审批人、凭证句柄、目标、响应状态和资源消耗。为了减少敏感数据二次扩散，应对请求体、响应体和模型上下文实行字段级脱敏与分层保留。

3.2 审计链应支持重放与对账

对确定性步骤，可使用相同镜像摘要、输入和配置重放；对非确定性模型步骤，则至少保存模型、参数、工具响应摘要和重要中间决策。系统还应把 Agent 的“认为成功”与外部系统的实际状态对账，避免网络超时后重复执行不可幂等动作。

（二）一条完整请求应该如何流动

1. 任务进入与预授权

网关验证用户与设备，把自然语言目标、数据级别、预算、截止时间和允许的结果类型组成任务上下文。策略服务根据主体、任务类型和环境生成能力清单、网络规则、资源上限与审批条件。

2. 计划生成与高风险断点

Agent 只看到被裁剪后的工具。它生成计划后，系统进行静态检查：是否包含写操作、批量操作、权限变更、外部发送、代码安装、持久化或不可逆动作。命中阈值时暂停，由人类审阅“将做什么、影响多少对象、使用哪个身份、如何撤销”，而不是只看一段模糊自然语言。

3. 沙箱执行与受控出口

执行服务用固定镜像摘要创建一次性沙箱，挂载只读输入和有限写目录，设置非 root、CPU、内存、进程数、磁盘、时限与网络策略。代码请求外部系统时，出口代理验证目标与请求语义，再使用短时凭证或代理注入认证。

4. 结果校验、提交与销毁

输出先经过格式、恶意内容、敏感数据和业务规则校验。需要写回时采用幂等键、事务或草稿状态；完成后记录外部对象 ID 与版本，销毁沙箱，回收 Secret 和临时卷。失败则保留必要证据，并避免自动重试非幂等动作。

任务从身份校验开始，经能力裁剪、审批、一次性执行、出口授权、结果校验，最终提交并销毁。

（三）推荐的策略对象

1. 主体、任务与数据

主体字段包括用户、服务身份、团队、租户、设备状态和认证强度；任务字段包括类型、来源、风险级别、预算、时限与父任务；数据字段包括分类、所有者、区域、保留要求和是否允许发送给外部模型。

2. 工具、凭证与目标

工具字段应细分动作、资源、最大批量和幂等性；凭证字段应标明身份、权限、轮换、来源与允许目标；网络目标应包括域名、端口、协议、DNS 约束、TLS 检查、私网例外和请求路径。把这些对象结构化，才能实现自动化审计和策略差异比较。

（四）日志与隐私要同时设计

1. 全量日志不等于高质量审计

把所有提示、文件和响应永久保存，会制造新的敏感数据仓库。审计应以事件和证据为中心：关键决策保留较长时间，敏感正文按必要范围采样、哈希或脱敏，访问日志本身也需要权限与告警。对调试需要的原始内容，可以使用短期加密保留和受审批解封。

2. 可观察性指标要能支持运营

建议监控拒绝率、审批率、异常出站、Secret 注入命中与失败、沙箱启动和销毁失败、超时、资源耗尽、镜像漂移、非幂等重试、外部系统对账差异、人工回滚和安全事件。只有这些指标进入日常运营，控制措施才不是上线时的一次性配置。

七、落地路线：从试验性沙箱走向企业运行平台

（一）第一阶段：建立最小可信执行单元

1. 只做低风险、只读任务

从公开数据、脱敏文档、测试仓库和只读 API 开始。每个任务进入一次性沙箱，关闭不必要网络，限制 CPU、内存、磁盘、进程数和时长，禁止挂载宿主敏感路径。镜像使用摘要固定，构建阶段与运行阶段分离。

2. 先证明“拒绝”有效

验收不仅要看正常任务能否完成，还要主动测试：读取宿主文件、访问元数据地址、连接私网、向未知域名外传、打印环境变量、绕过代理、重复运行、占满资源和写入持久卷。安全控制的价值主要体现在拒绝路径，而不是演示成功路径。

（二）第二阶段：引入连接器与凭证代理

1. 用低权限服务身份替换个人 Token

每个连接器使用专用服务身份，权限按动作和资源最小化，设置短时有效期或可快速吊销机制。密钥不进入 Agent 提示、代码、镜像、环境变量明文或日志；任务只拿到连接器句柄或占位符。

2. 为允许目标建立自动化测试

测试正确域名、相似域名、子域通配、重定向、硬编码 IP、DNS rebinding、SNI 不一致、域前置、HTTP/2、压缩请求体和大请求体。对 Tines 3B，应验证连接器 URL pattern 的边界；对 microsandbox，应验证 Secret 替换与 TLS/DNS 策略的组合行为。

（三）第三阶段：增加写操作与人类审批

1. 把批准对象变成结构化变更集

审批界面应展示目标对象、字段差异、数量、影响范围、使用身份、估计成本和回滚方式。批准的是一个带摘要哈希的具体计划，不是“允许 Agent 继续”这种无限授权。计划变化后应重新审批。

2. 使用草稿、事务和幂等设计

能创建草稿就不直接发布；能软删除就不永久删除；能在事务中提交就不逐条裸写；所有重试使用幂等键。对外发消息、付款、权限变更、生产部署和大规模数据修改，默认要求人类确认或双人控制。

（四）第四阶段：平台化与红队化

1. 统一策略与证据

将身份、任务、工具、数据、凭证、网络、镜像、审批和日志模型统一，建立策略即代码、版本审查和灰度发布。每个事件使用全局任务 ID 串联控制面与执行面，保证审计、告警和成本可归因。

2. 持续攻击验证

红队测试应覆盖提示注入、工具混淆、依赖投毒、文件穿越、符号链接、压缩炸弹、SSRF、DNS 绕过、Secret 外传、日志注入、跨租户卷、沙箱逃逸、审批重放和异常重试。新模型、新工具、新镜像和新网络例外上线前都应触发回归。

八、选型与验收：不要比较功能清单，要比较可证明的边界

（一）先问十个决定性问题

1. 业务与治理问题

第一，主要使用者是业务团队、开发团队还是平台团队？第二，任务以 SaaS 自动化为主，还是以任意代码执行为主？第三，谁负责审批高风险动作？第四，是否需要自托管、离线或特定区域？第五，日志与任务内容允许保留多久？

2. 技术与安全问题

第六，工作负载是否完全不可信、是否多租户？第七，需要哪些宿主目录、内网和外部域名？第八，Secret 能否保证不进入客体明文？第九，是否能按任务限制 CPU、内存、进程、磁盘和时长？第十，能否从一次外部变更追溯到主体、计划、策略、审批、执行和凭证？

（二）Tines 3B 的重点验证项

1. 平台治理与连接器

验证空间与角色模型、连接器可见性、凭证维护职责、URL pattern 精度、认证方式、私网与网络路由、审批和审计导出。检查管理员能否越权读取凭证、日志是否包含敏感请求体、服务账号权限是否可比个人账号更窄。

2. 执行与运营

验证 gVisor 隔离配置、只读文件系统与 scratch 范围、持久存储权限、资源限制、构建缓存、镜像来源、执行历史、重试语义、异常告警、自托管升级与灾备。若步骤依赖特殊系统调用、内核特性或高 I/O，应进行兼容性与性能压测。

（三）microsandbox 的重点验证项

1. 宿主与 microVM 边界

验证 KVM/WHP/Hypervisor.framework 支持、宿主进程权限、VMM 与内核更新、虚拟设备面、restricted profile、非 root 运行、跨沙箱卷和端口。高敏任务应评估专用节点与单租户策略。

2. 网络、Secret 与平台配套

验证默认公网访问是否符合组织要求，建议对敏感任务改为默认拒绝；测试私网、元数据、DNS、SNI、TLS MITM、DoH/隧道与代理绕过；确认原始 Secret 是否落盘、宿主内存边界、轮换、日志脱敏。另需评估 beta 版本升级、API 兼容、调度、配额、审计、镜像签名与供应商支持。

（四）一份可执行的验收清单

1. 必须通过

• 每个任务可绑定到唯一主体、租户和策略版本。

• 默认工具集最小化，删除、部署、权限变更和外发可单独控制。

• Secret 不以明文进入提示、代码、镜像、客体环境、工作目录或普通日志。

• 网络默认拒绝或至少阻断宿主、私网、回环、链路本地和云元数据。

• 沙箱可限制 CPU、内存、磁盘、进程、时长和持久化，并在任务后可靠销毁。

• 镜像可按摘要固定，依赖和构建过程可追溯。

• 高风险动作审批绑定具体变更集，计划改变会导致批准失效。

• 重试具有幂等保护，外部系统结果可对账。

• 审计记录不可由 Agent 关闭，并能串联模型、工具、执行、网络、凭证和外部对象。

• 安全团队能模拟吊销凭证、阻断目标、隔离租户和停止全部任务。

2. 建议通过

• 具备策略即代码、回归测试、灰度和回滚。

• 支持对提示注入、SSRF、依赖投毒和跨租户访问进行持续红队测试。

• 能区分构建网络与运行网络，并对包仓库实施代理和允许列表。

• 日志支持字段级脱敏、短期原文封存和访问审批。

• 能统计每个主体、Agent、连接器和工作流的成本与异常率。

九、结论：安全的 Agent 不是“更聪明”，而是“被正确地限制”

（一）真正的突破是把权力从上下文移到边界

Tines 3B 与 microsandbox 的共同启示，不是 Agent 终于拥有了一个新容器或一个新代理，而是系统开始承认：模型生成的代码与请求都应被视为不完全可信。密钥不必交给工作负载，网络不必天然开放，文件不必默认可写，身份不必继承全部权限，执行不必在宿主长期存活，日志也不必由 Agent 自己决定是否记录。

两者的差异同样重要。Tines 3B 以企业工作治理为中心，使用连接器、Credential Proxy、一次性容器、gVisor、监控和审计形成一体化路径；microsandbox 以可嵌入的 microVM 运行时为中心，用独立内核、有限虚拟设备、用户态网络策略和宿主侧 Secret 替换提供更底层的隔离原语。前者不是 microVM，后者也不是现成的企业治理套件。

（二）最可靠的架构结论

如果把整篇文章压缩成一句工程原则，就是：让 Agent 拥有完成当前任务所需的最小、短时、可观察、可撤销能力，并让每一种能力都在模型无法修改的边界上被执行。

由此可以推导出四条落地纪律：第一，提示词只表达意图，策略系统负责授权；第二，工作负载只持有句柄或占位符，真实凭证只在受控出口短暂出现；第三，每个高风险任务进入独立、资源受限、网络受控、可销毁的执行环境；第四，从自然语言目标到外部系统变更必须形成可对账的证据链。

Agent 的能力仍会继续增长。今天是写代码和调 API，明天可能是操作浏览器、控制机器人、管理云基础设施和协同多个子 Agent。能力越接近现实世界，越需要把“受控工作间”当作基础设施，而不是可选插件。安全的目标也不应是阻止所有行动，而是让组织能够有依据地说“可以”：可以运行，但只能在这个房间；可以使用凭证，但看不到秘密；可以访问系统，但只到这些目标；可以做出改变，但必须留下证据，并且在必要时能够停下和撤回。

可参考的文章与资料

1. Tines 3B 产品页（Product Hunt）

2. Tines：Introducing Tines 3B, the next generation of Tines

3. Tines 3B Docs：What is Tines 3B?

4. Tines 3B Docs：Credentials

5. Tines 3B Docs：Credential proxy

6. Tines 3B Docs：Containerized / Isolated execution

7. Tines 3B Docs：Execution

8. Tines 3B Docs：Self-hosted

9. superradcompany/microsandbox GitHub 仓库

10. microsandbox Docs：Introduction

11. microsandbox Docs：Isolation boundary

12. microsandbox Docs：Network defenses

13. microsandbox Docs：Secret handling

14. microsandbox Docs：Hardening

15. gVisor 官方文档：What is gVisor?

16. NIST SP 800-190：Application Container Security Guide

17. NIST SP 800-207：Zero Trust Architecture

18. OWASP：LLM06:2025 Excessive Agency