BoxAgnts运行时评测：无需Root的能力安全方案
现代 AI Agent 的操作权限正快速扩张——它们能执行 Shell 命令、修改代码仓库、访问本地文件、操控云基础设施、管理开发者环境。权限列表每增加一项，潜在风险就成倍上升。
症结在于，现有 AI 基础设施大多仍沿用为可信人类操作者设计的安全模型。这一基础假设在当下已然失效。
必须认清一个事实：LLM 并非可信执行权威。它们是概率性系统，时刻暴露于提示注入、对抗性上下文、不可信文档、被操纵的工具输出以及推理不稳定性等威胁中。然而，众多 AI Agent 仍以近似 root 的权限运行。
这并非工具选型问题，而是安全架构的核心缺陷。
大多数 AI Agent 底层隐藏的权限假设
BoxAgnts 的查询循环演示了 LLM 如何扮演运行时控制器的角色——模型决定调用哪个工具、传递什么参数、访问哪些资源。在 boxagnts/query/src/query.rs 中，核心逻辑如下：
// 解析模型生成的每轮输出
// 若含 tool_use 块，执行对应工具
for tool_use_block in tool_uses {
let tool_name = &tool_use_block.name;
let tool = find_tool(&tools, tool_name);
let result = tool.execute(tool_input, tool_ctx).await;
// 结果以 ToolResult 消息返回模型
}
关键问题在于，运行时通常授予模型过于宽泛的隐式权限——无限制的文件系统、无限制的网络、无限制的 Shell。LLM 本身无法理解操作风险、权限提升、生产安全或组织边界——它唯一擅长的是预测下一个最合理的 token。
提示注入进一步放大了宽泛权限的风险
恶意指令可以轻易嵌入网页、Markdown 文件、源代码、电子邮件、PDF 以及 API 响应……模型无法仅凭提示词可靠区分“可信指令”与“恶意指令”。
那么核心问题是什么？并非“模型能否偶尔安全执行任务”，而是“无约束的权限会放大每一次推理失败的风险”。我们的目标不应是让模型变得可信——而是要让不安全行为得到切实遏制。这要求明确的能力边界。
BoxAgnts 的 Agent tool 设计（boxagnts/tools/src/agent/mod.rs）完美体现了这一原则。Agent 可通过配置 tools 限制工具集；可设置 max_turns 硬上限；可选择 isolation: "worktree" 在隔离的 Git 工作树中运行。这些都是能力约束的典型实践：
#[derive(Debug, Deserialize)]
struct AgentInput {
description: String,
prompt: String,
tools: Option<Vec<String>>, // 限制子 Agent 可用工具集
max_turns: Option<u32>, // 对话轮次硬上限
isolation: Option<String>, // 隔离模式（如 worktree）
model: Option<String>, // 指定模型
run_in_background: bool, // 异步隔离执行
}
传统访问控制模型难以适配 AI Agent
RBAC、ACL、IAM 等传统身份安全模型，依赖稳定的身份、可预测的工作流和负责任的人类操作者。AI Agent 则完全违背了这三条——工作流动态生成、工具调用概率性进行、多个 Agent 协同操作。
BoxAgnts 的 PermissionMode 枚举提供了更灵活的方案：
pub enum PermissionMode {
BypassPermissions, // 跳过权限检查（禁止用于生产）
Default, // 标准权限校验
AcceptEdits, // 自动接受编辑
Plan, // 规划模式（只读）
}
即便此模型，粒度仍嫌不足。实际需要的是：“Agent 可读取 /workspace/project，可写入 /workspace/tmp，但禁止访问 ~/.ssh，禁止访问生产密钥”——这种精确的白名单式权限描述。
能力安全：从“你是谁”转向“你被允许做什么”
能力安全的核心思想极为朴素：不为 Agent 提供 root 密码，而是交给它一份精确的权限清单。
BoxAgnts 的 WASM 执行模型正是在工程层实现了这一理念。在 RunOption 中，每项能力均需显式声明：
work_dir → 文件系统：仅暴露工作目录
allowed_outbound_hosts → 网络：白名单出站连接
env_vars → 环境：选择性传递环境变量
wasm_timeout → 时间：执行超时限制
wasm_max_memory_size → 内存：内存上限硬约束
wasm_fuel → 计算：指令数上限
网络能力控制尤为精细。以 boxagnts/wasm-sandbox/src/extension/net.rs 为例：
// 出站连接权限校验
pub async fn socket_addr_check(
addr: SocketAddr,
addr_use: SocketAddrUse,
allowed_outbound_hosts: OutboundAllowedHosts,
blocked_networks: BlockedNetworks,
) -> bool {
// TCP 绑定？直接拒绝
// UDP 绑定？直接拒绝
// 出站连接？检查白名单与黑名单
}
模型无法绕过这些约束——无论 LLM 在提示中如何“推理”，WASM 沙箱的 TCP bind 始终返回 false。这正是能力安全的核心优势：安全不依赖模型意图，而依赖运行时的强制执行力。
能力安全 vs 人类中心安全
传统操作系统的安全设计，均围绕可信人类用户演化——人类具备上下文理解、组织意识、长期推理与问责能力。LLM 则完全缺乏这些能力。它无法一致判断文件是否敏感、命令是否危险、API 调用是否违反策略。
这正是能力安全相较传统 RBAC 更适配 AI 的原因：它降低了对模型判断的依赖。并非期望 Agent 做出正确决策，而是通过运行时约束，确保其仅能在安全范围内决策。安全不应依赖模型对齐，而应依赖运行时保证。
BoxAgnts 的 ToolContext 结构体完整体现了这一设计理念：
pub struct ToolContext {
pub permission_mode: PermissionMode,
pub session_id: Option<String>,
pub current_turn: Arc,
pub non_interactive: bool,
pub mcp_manager: Option>,
pub config: Config,
pub allowed_outbound_hosts: Vec<String>,
pub block_url: Option<String>,
}
每个工具执行时均携带此上下文。务必注意：allowed_outbound_hosts 和 block_url 并非建议值——它们是传递给 WASM 运行时的硬性约束。
多 Agent 系统的能力边界管理
在 BoxAgnts 的 Managed Agent 模式下，Manager 负责任务分配与分发，将工作委派给多个 Executor。每个 Executor 可拥有独立的能力集合、模型配置及工具访问权限。
在 boxagnts/query/src/managed_orchestrator.rs 中，系统提示词明确展示了分层关系：
你是 MANAGER，负责规划与推理层。
你无法直接使用文件/bash工具——必须委托给 executor agent。
每个 executor 使用模型 {executor_model}，轮次上限 {max_turns}。
最多允许 {max_concurrent} 个 executor 并行执行。
这种层次结构本身即是能力安全的具体运用——Manager 的能力是“委托”，Executor 的能力是“执行”。Manager 不会意外执行危险的 Shell 命令，因为它根本不具备 Shell 工具。
能力图：未来运行时核心原语
随着 AI 系统复杂度持续增长，能力本身可能演变为可编排的资源。未来的运行时可能需要管理能力委托、临时权限授予与撤销、执行追踪、能力继承、资源核算等一系列复杂操作。
BoxAgnts 当前的架构已为这些扩展预留了空间：ToolContext 作为每个工具执行的上下文载体，可自然扩展为“能力上下文”——不仅携带当前 Agent 的权限集，还可携带继承链、委托关系及审计日志。
结语
AI Agent 正从对话系统进化为执行系统。这一转变从根本上重塑了安全需求。LLM 天生暴露于对抗性指令、不可信上下文及概率性执行路径中——只要其仍以宽泛隐式权限运行，就在结构上不安全。
解决方案并非盲目优化提示词，而是通过运行时强制实现能力隔离。BoxAgnts 的实践清晰证明：能力驱动的运行时，能提供受约束的执行环境、显式权限声明、确定性安全边界以及可治理的基础设施。