现代 AI Agent 正在迅速获得操作权限------执行 Shell 命令、修改代码仓库、访问本地文件、操作云基础设施、管理开发者环境。
问题在于，大多数 AI 基础设施仍然依赖为可信人类操作者设计的安全模型。这个假设已经不成立了。
LLM 不是可信的执行权威。它们是暴露在提示注入、对抗性上下文、不可信文档、被操控工具输出和推理不稳定性中的概率性系统。然而许多 AI Agent 仍然以相当于 root 的权限运行。
这不是工具问题，是安全架构问题。
大多数 AI Agent 内部的隐藏假设
BoxAgnts 的查询循环清晰地展示了 LLM 如何成为运行时控制器------模型决定调用哪个工具、传递什么参数、访问哪些资源。在 boxagnts/query/src/query.rs 中：
ini
// 每一轮对话中，模型生成的内容被解析
// 如果包含 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 不理解操作风险、权限提升、生产安全、组织边界------它只预测合理的续写。
Prompt Injection 使宽泛权限变得更加危险
恶意指令可以嵌入网页、Markdown 文件、源代码、电子邮件、PDF、API 响应------模型无法仅靠提示词可靠区分"可信指令"和"恶意指令"。
因此核心问题不是"模型能否偶尔安全地行为"，而是"不受限的权限放大了每一次推理失败"。目标不是让模型可信，而是让不安全的行为可被遏制。这需要能力边界。
BoxAgnts 的 Agent tool 设计（boxagnts/tools/src/agent/mod.rs）体现了这个原则。Agent 可以配置 tools 限制------只允许特定工具集；可以设置 max_turns 硬上限；可以选择 isolation: "worktree" 在隔离的 Git 工作树中运行。这些都是能力约束的实例：
rust
#[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, // 异步隔离
}传统访问控制不够
RBAC、ACL、IAM 这些身份安全模型假设稳定的身份、可预测的工作流和人类操作者。AI Agent 违反全部三条------动态生成工作流、概率性调用工具、跨多 Agent 协调。
BoxAgnts 中的 PermissionMode 配置提供了更灵活的方案：
rust
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：
rust
// 出站连接检查
pub async fn socket_addr_check(
addr: SocketAddr,
addr_use: SocketAddrUse,
allowed_outbound_hosts: OutboundAllowedHosts,
blocked_networks: BlockedNetworks,
) -> bool {
// TCP 绑定？拒绝
// UDP 绑定？拒绝
// 出站连接？检查白名单和黑名单
}模型无法 override 这些约束------无论 LLM 在提示词中如何"推理"，WASM 沙箱的 TCP bind 始终返回 false。这就是能力安全的核心优势：安全不依赖模型意图，而依赖运行时强制。
能力安全与人类中心安全的区别
传统操作系统围绕可信人类用户演化------人类有上下文理解、组织意识、长期推理和问责制。LLM 完全没有这些。它无法一致评估文件是否敏感、命令是否危险、API 调用是否违反策略。
这就是为什么能力安全比 RBAC 更适合 AI：它削减了对模型判断的依赖。不是你期望 Agent 做出正确决策，而是你确保运行时约束了可能的决策。安全不应该依赖模型对齐，应该依赖运行时保证。
BoxAgnts 的 ToolContext 包含了这种设计意识的全部要素：
rust
pub struct ToolContext {
pub permission_mode: PermissionMode,
pub session_id: Option<String>,
pub current_turn: Arc<AtomicUsize>,
pub non_interactive: bool,
pub mcp_manager: Option<Arc<boxagnts_mcp::McpManager>>,
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 中，系统提示词明确了这个分层：
bash
你是 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 的实践表明：能力驱动的运行时提供受约束的执行、显式权限、确定性边界和可治理的基础设施。
AI Agent 应该接收能力，而不是 root 权限。
相关资源
- Boxagnts：github.com/guyoung/box...