企业 Agent运行时安全的七域架构

大模型安全通常试图解决一个问题：如何让模型不生成错误、有害或违规的内容。

但当大模型从聊天助手变成能够调用数据库、发送邮件、执行命令和操作业务系统的 Agent 后，仅仅约束模型“说什么”已经不够。一次错误回答可能只是信息不准确，一次错误工具调用却可能直接删除文件、泄漏数据，甚至触发不可逆的业务操作。

论文《Deterministic Architectural Safety for Enterprise AI Agents: A Runtime Enforcement Framework》提出了一套面向企业 Agent 的运行时安全架构。

论文原文（PDF）

它没有继续寻找一种能够彻底阻止提示注入的模型，而是选择接受一个更现实的前提：

大模型的决策可能被操纵，但它产生的动作不能因此直接获得执行权。

基于这一前提，论文将 Agent 安全拆分为身份、凭据、权限、数据、审计、外部 AI 和治理七个安全域，并尝试通过策略执行点、确定性策略引擎和不可变审计，将安全控制从模型内部迁移到模型之外的执行路径上。

论文由 Rizwan Jahangir 和 Daisuke Ishii 撰写，目前仍处于审稿阶段。作者同时公开了 OPA/Rego 策略、25个测试场景、形式化模型和验证结果。

从“模型不能犯错”转向“错误不能落地”

现有大模型安全方案，大多属于概率性行为控制。

例如系统提示词、安全微调、输入输出检测模型、LLM Judge，以及让 Agent 在调用工具前进行自我反思。这些方法可以降低风险，却很难给出稳定的安全保证。

面对同一个输入，模型可能因为采样参数、上下文变化或模型升级而作出不同判断。即使一个安全模型能够拦截99%的攻击，对于删除数据库、转移资金、发送敏感文件等操作，剩下的1%仍然可能造成严重后果。

论文将这类机制称为“概率性行为控制”。它们试图让模型形成正确的安全行为，但最终仍然依赖模型本身作出判断。

确定性架构采用了另一条路线。

模型不再直接控制工具，而是只能产生一个结构化的动作请求。例如：

{ “action”: “execute”, “tool”: “send_email”, “resource”: “internal_email”, “destination”: “[email protected]”, “data”: [ { “id”: “report-001”, “class”: “Internal” } ] }

这个请求不会立即执行，而是先进入策略执行点，也就是 Policy Enforcement Point，简称 PEP。

PEP 会根据当前用户身份、Agent 权限、目标资源、数据类型和目标地址，将请求交给独立的策略决策系统。只有当所有策略都通过时，工具调用才会真正发生。

整个过程可以简化为：

用户任务
↓
大模型生成计划
↓
Agent 提出工具调用
↓
运行时策略执行点 PEP
↓
允许 / 拒绝 / 请求人工确认
↓
真实工具和业务系统

这里最关键的变化是，模型只能“建议做什么”，不能决定“是否真的执行”。

即使攻击者已经通过间接提示注入控制了模型，让 Agent 试图删除数据库，只要 Agent 没有对应权限，执行请求仍然会被拒绝。

因此，这套架构并不承诺阻止提示注入。作者在验证过程中也否定了“架构能够阻止所有提示注入攻击”这一说法，将其修正为“限制提示注入造成的影响”。

七个安全域如何构成运行时控制平面

论文没有把 Agent 安全简化为一个提示注入检测器，而是将其拆解为七个相互配合的安全域。

这七个安全域并不都直接部署在大模型网关，也不完全属于 Agent 框架。它们共同构成一套横跨身份系统、Agent Runtime、工具网关和业务资源的控制平面。

1. 身份域：Agent必须证明自己代表谁

传统应用中的操作主体通常是用户或服务账户。进入 Agent 系统后，操作链路会变得更复杂：

用户
↓
委托

主 Agent
↓
委托

子 Agent
↓
工具调用

当一个子 Agent 请求访问数据库时，仅记录“agent-123调用了数据库”是不够的。系统还需要知道：

• Agent 代表哪个用户行动
• 权限最初由谁授予
• 中间经过了几次委托
• 当前委托是否仍然有效
• 子 Agent 是否超出了父 Agent 的授权范围

论文将这种关系称为主体链或委托链。每一个安全相关动作都应当关联一个可验证的主体链。

例如：

员工 Alice └── 报表 Agent └── 数据分析 Agent └── read_db(customer_db)

权限在委托过程中只能保持不变或逐步收缩，不能扩大：

子 Agent 权限 ⊆ 父 Agent 权限 ⊆ 原始用户权限

如果用户只能读取客户数据库，主 Agent 就不能把财务数据库权限授予子 Agent。

这一设计适合多 Agent 协同场景。它解决的不是“Agent叫什么名字”，而是让每一个动作都能追溯到真实授权来源。

不过，论文公开的 Rego 策略并没有真正验证身份签名、令牌有效期和委托链完整性。策略输入虽然包含 principal_chain，但实际执行逻辑没有引用这一字段。因此，身份域目前主要停留在参考架构和形式化模型层面。

2. 凭据域：Agent不应直接接触长期密钥

很多 Agent 应用会把数据库密码、云服务密钥或第三方 API Key 放进环境变量，再由 Agent 运行时直接读取。

这种方式存在明显风险。

一旦 Agent 被提示注入控制，攻击者可能诱导它读取环境变量、访问配置文件，或者通过工具返回结果泄漏密钥。

论文建议引入独立的 Secrets Broker，也就是凭据代理：

Agent 请求调用工具
↓
PEP 判断动作是否允许
↓
Secrets Broker 生成短期凭据
↓
凭据直接注入工具执行器
↓
工具代表 Agent 完成操作

在这个过程中，Agent 只知道自己可以调用某个工具，不需要看到真实密码。

短期凭据还可以绑定：

• 指定工具
• 指定资源
• 指定动作
• 指定时间窗口
• 指定 Agent 实例
• 指定调用次数

例如，一个报表 Agent 获得的不是完整数据库密码，而是一枚只能在5分钟内读取 customer_db 的临时令牌。

这样，即使令牌意外泄漏，其可利用范围也相对有限。

3. 权限域：工具和资源必须成对授权

权限域是论文当前实现最完整的部分。

作者要求所有具有真实副作用的操作都经过 PEP，不能允许 Agent 绕过网关直接调用数据库、Shell、文件系统或外部网络。

这里不仅要判断 Agent 是否有权使用某个工具，还要同时判断它是否有权通过这个工具访问当前资源。

权限应表示为工具与资源的二元组：

(read_db, customer_db) (write_db, financial_db) (send_email, internal_email)

不能分别维护：

允许的工具：read_db、write_db 允许的资源：customer_db、financial_db

因为分别判断可能产生权限组合漏洞。

例如某个 Agent 拥有两项合法权限：

read_db(customer_db) write_db(financial_db)

如果策略只检查“Agent拥有read_db工具”和“Agent能够访问financial_db资源”，就可能错误地允许：

read_db(financial_db)

Agent 原本只能读取客户数据库、写入财务数据库，却通过组合两个独立授权，获得了读取财务数据库的能力。

论文在构造测试场景时发现了这一 confused deputy，也就是“混淆代理”问题，随后将策略修改为工具和资源必须在同一条 capability 中同时匹配。

实际 Rego 策略如下：

capability_pair_allowed { some i input.agent.capabilities[i].tool == input.tool input.agent.capabilities[i].resource == input.resource }

只有当请求中的工具和资源共同出现在同一条权限记录中，动作才可能被允许。

这类机制很像传统操作系统和云平台中的强制访问控制，只是授权对象从“进程访问文件”扩展到了“Agent通过工具访问业务资源”。

4. 数据域：有权限调用工具，不等于可以发送任何数据

仅仅控制工具权限仍然不够。

假设一个 Agent 被允许使用 HTTP 工具访问网络。攻击者可以通过间接提示注入，诱导它读取内部文档，再将文档发送到外部服务器。

从工具权限看，Agent 的确拥有 http_post 权限；从安全结果看，这仍然构成数据泄漏。

因此，论文要求在权限判断之外增加数据流控制。

数据首先被划分为不同级别：

Public Internal Confidential Restricted

当工具调用携带 Confidential 或 Restricted 数据时，系统需要检查目标地址是否处于允许列表。

公开代码中的逻辑是：

permit { input.action == “execute” capability_pair_allowed data_flow_safe }

也就是说，动作只有同时满足以下条件才会执行：

• 请求是一个受支持的执行动作
• 工具和资源权限匹配
• 数据流向符合策略

当请求中不存在敏感数据时，data_flow_safe 返回允许；当存在 Confidential 或 Restricted 数据时，目标必须属于预先批准的地址。

这解决的是“有权限使用合法工具，但利用合法工具外泄数据”的问题。

但这里存在一个重要前提：数据标签必须可信。

论文测试中的数据标签由请求直接声明：

{ “id”: “doc1”, “class”: “Restricted” }

真实系统不能依赖 Agent 自己报告数据等级。被劫持的 Agent 完全可以不填写 data 字段，或者把 Restricted 数据标成 Public。

因此，企业落地时还需要补充：

• 数据来源标记
• 敏感字段识别
• 污点传播
• 内容与标签绑定
• 编码和摘要后的标签继承
• 工具输入输出之间的数据流追踪

否则，数据域的策略虽然是确定性的，策略判断依据却可能是错误的。

5. 审计域：不只是记录日志，而是保证动作无法脱离日志

Agent 轨迹通常包含模型调用、工具选择、参数、结果和中间状态。

但普通应用日志并不等于安全审计。

如果系统采用“先执行动作，再异步写日志”的方式，就可能出现：

动作已经执行
↓
日志服务故障
↓
没有留下审计记录

论文要求对安全相关动作使用“日志先于提交”或者原子提交机制：

策略判断允许
↓
写入不可变审计记录
↓
提交真实动作

只有当审计记录成功写入后，动作才真正生效。

审计记录至少需要包括：

• 用户身份
• Agent 身份
• 委托链
• 工具和资源
• 完整参数摘要
• 策略版本
• 策略判断结果
• 数据等级
• 人工审批记录
• 执行结果和错误信息

论文的形式化模型给出了一条审计完整性定理：如果所有动作都采用原子的“记录后提交”机制，那么每一个已经提交的安全动作都存在对应审计记录。

不过，公开代码只测试了 OPA 策略判断，并没有实现不可变日志、日志签名或事务性动作提交。因此，审计域目前仍是一项架构要求，而不是已经验证的工程能力。

6. 外部AI域：调用第三方模型也是一种数据外发

企业 Agent 经常需要调用多个外部模型。

一个 Agent 可能使用企业内部模型完成任务规划，再将部分文本发送给外部模型进行翻译、摘要或代码生成。

从传统大模型网关的角度看，这只是一次模型请求；从数据安全角度看，它实际上是一条外部数据传输通道。

外部 AI 域需要判断：

• 允许调用哪些模型供应商
• 哪类数据可以发送给哪些供应商
• 是否需要对上下文进行脱敏
• 供应商是否允许保留输入数据
• 数据是否跨境
• 请求是否携带用户身份或业务秘密
• 模型输出能否进入后续高权限工具

论文把外部模型调用放在专门的 AI Gateway 之后，并要求敏感数据只能发送至批准的模型服务。

公开策略中的白名单包含内部接口和批准的外部 AI 服务：

approved := { “api.internal.example.com”, “secure-ai.example.com” }

当 Restricted 或 Confidential 数据被发送至其他地址时，策略拒绝执行。

但目标地址白名单只能解决“数据去了哪里”，不能完全判断“数据为什么被发送”。

如果攻击者的目标恰好是一个已批准的模型供应商，或者白名单服务本身遭到入侵，现有策略仍然无法阻止泄漏。作者也明确将“批准供应商未被攻破”列为信息流保证成立的前置假设。

7. 治理域：把企业制度转化为可执行策略

前六个安全域解决具体的运行时控制问题，治理域则负责管理这些控制本身。

企业安全制度通常写在文档中，例如：

• 客户数据不得发送至外部服务
• 财务操作必须由两人审批
• 高风险 Agent 不得直接访问生产环境
• 权限变更需要经过安全审核
• 敏感操作日志至少保留三年

问题在于，文档中的制度不会自动约束 Agent。

治理域的任务，是将这些制度转化为机器可执行、可追踪的策略，并建立完整的策略生命周期：

制度要求
↓
机器可读策略
↓
评审与审批
↓
发布和生效
↓
运行时执行
↓
效果监测
↓
版本回滚

每一次策略判断都应关联具体的策略版本。否则当安全事故发生时，很难回答“当时系统执行的究竟是哪一版规则”。

作者还将部分控制要求映射到 NIST SP 800-207、ISO/IEC 27001和ISO/IEC 42001，例如身份验证、执行前授权、敏感数据传输、审计日志和策略版本管理。

不过，标准条款映射只能说明设计方向与标准要求存在对应关系，并不代表系统已经通过合规认证。

四条不变量：确定性安全究竟证明了什么

为了描述这套架构，论文建立了一个状态转移模型。

系统中包含用户、Agent、工具、资源、数据对象、策略、动作和审计日志。每次 Agent 提出的动作都会推动系统从一个状态迁移到另一个状态。

安全系统需要持续保持四条不变量：

身份有效 动作已授权 数据流向安全 审计记录完整

第一条是不允许不存在有效主体链的动作。

第二条是所有工具调用必须经过授权，并且工具与资源同时处于 Agent 的能力范围内。

第三条是 Restricted 等敏感数据不能发送到未经批准的目标。

第四条是所有已经执行的安全相关动作都必须存在不可变审计记录。

在这些基础上，论文给出了四个定理：

这些证明在逻辑上成立，但都是条件化结论。

以“不变量保持”为例，它依赖三个重要前提：

• PEP 不可绕过
• PEP 正确实现了策略
• 策略完整表达了安全要求

如果 Agent 可以直接访问网络，绕过 Tool Gateway，证明就不再成立。

如果策略漏掉了某种工具副作用，证明也无法覆盖该风险。

如果数据标签错误，信息流策略即使执行完全正确，也可能放行真实的敏感数据。

因此，论文证明的不是“Agent整体行为已经被确定性控制”，而是：

在可信输入、正确策略和不可绕过的执行边界成立时，明确写入策略的安全属性可以被确定性执行。

这个区别非常重要。

“100%拦截”背后，其实是一组OPA策略测试

论文最引人关注的数据是：

• 14个恶意场景全部拦截
• 11个正常场景全部允许
• 恶意行为遏制率100%
• 正常行为误拒率0%

公开仓库中的25个场景主要覆盖三类风险：

作者使用真实的 OPA 二进制执行 Rego 策略，而不是自己模拟一个策略引擎。运行结果显示25个场景全部符合预设标签。

不过，这个“100%”不能被理解为系统能够拦截所有 Agent 攻击。

测试中没有真实大模型，也没有完整 Agent。

每个场景都是提前写好的 JSON 请求。例如，一个恶意场景直接构造：

{ “tool”: “delete_db”, “resource”: “customer_db”, “capabilities”: [ { “tool”: “read_db”, “resource”: “customer_db” } ] }

策略发现 Agent 只有读取权限，没有删除权限，于是返回拒绝。

这实际上验证的是：

对于作者预先编写的25个结构化输入，OPA策略输出与作者预先设置的期望标签一致。

它没有测试：

• 真实提示注入过程
• 模型如何生成工具参数
• 多步骤任务轨迹
• 多工具组合攻击
• 动态权限和资源状态
• 工具内部隐藏副作用
• 编码和混淆后的数据泄漏
• 自适应攻击者
• 生产环境中的延迟和吞吐

仓库也明确说明，测试 Harness 不包含实时 LLM，只是模拟一个已经被攻破的模型所生成的违规工具调用。延迟和吞吐则被列为未来工作。

此外，作者在构造测试场景的过程中，先后发现了工具—资源组合漏洞和 Confidential 数据遗漏问题，随后修改策略，再获得25/25的结果。

这种做法适合作为策略回归测试，但不足以证明策略能够泛化到未知攻击。

因此，论文的实验结果更准确的表达应当是：

当前Rego策略正确处理了25个已知测试用例。

而不是：

七域架构已经实现了对企业Agent攻击的100%拦截。

真正的工程难点，不是写出一条拒绝规则

论文公开的核心策略并不复杂：

default permit = false

permit { input.action == “execute” capability_pair_allowed data_flow_safe }

这套策略采用默认拒绝原则。只有工具—资源组合正确，并且数据流向安全，动作才被允许。

真正困难的不是让 OPA 对一段 JSON 返回 true 或 false，而是如何构造可信、完整且不会被 Agent 操纵的策略输入。

以一次邮件发送为例，PEP 至少需要得到：

{ “principal”: “[email protected]”, “agent_id”: “report-agent-01”, “delegation_chain”: [“alice”, “report-agent”], “tool”: “send_email”, “recipient”: “[email protected]”, “attachments”: [“financial-report.xlsx”], “data_class”: “Restricted”, “task_id”: “task-20260728-001”, “policy_version”: “v3.2” }

其中每一个字段都有可能成为薄弱点。

身份不能由 Agent 自己填写，必须来自身份系统或签名令牌。

权限不能放在 Agent 可修改的请求正文里，必须来自权威权限中心。

数据等级不能完全依赖模型判断，需要与文件、字段和数据来源绑定。

目标地址不能只检查字符串，还要考虑重定向、DNS变化、代理和二次转发。

策略允许结果还要绑定具体参数，防止授权和执行之间发生状态变化。

因此，企业真正需要建设的不是一个单独的 Rego 文件，而是一条可信决策链：

身份系统
  + 权限中心
  + 工具注册中心
  + 数据分类与污点追踪
  + Agent轨迹
  + 资源实时状态
↓
统一策略输入
↓
确定性策略判断
↓
绑定参数的执行令牌
↓
工具执行

Harness、工具网关和模型网关应该如何分工

这篇论文也为一个常见问题提供了参考：Agent 行为安全究竟应该部署在 Agent 框架、大模型网关，还是独立安全模块中？

答案不是三选一。

Agent Harness负责理解轨迹

Agent Harness 最接近 Agent 的规划和执行过程，能够看到：

• 当前用户任务
• 模型生成的计划
• 已执行步骤
• Tool、MCP和Skill调用
• 工具返回结果
• 多 Agent 消息
• 当前记忆和上下文

因此，任务对齐、轨迹分析、多步骤风险识别和用户确认适合部署在 Harness 层。

例如，Agent先读取客户名单，随后压缩文件，再调用邮件工具。单看每一步可能都合法，但结合轨迹后可能形成数据泄漏链路。

Tool Gateway负责不可绕过的硬控制

Tool Gateway位于真实副作用发生之前，适合承担：

• 工具和资源授权
• 参数约束
• 短期凭据注入
• 数据流向控制
• 高风险操作审批
• 速率和影响范围限制
• 不可变审计

即使 Agent Harness 被攻击或修改，真实业务系统仍然不应该接受未经 Tool Gateway 授权的调用。

大模型网关负责模型调用和上下文安全

大模型网关更适合处理：

• 模型供应商白名单
• 请求内容脱敏
• 输入输出内容检测
• 模型调用审计
• Token和成本控制
• 模型路由
• 外部模型数据合规

它能够看到模型请求，却通常看不到工具执行的完整语义和系统状态，因此很难独立完成 Agent 行为授权。

比较合理的生产架构是：

Agent Harness
负责理解任务、计划和轨迹
↓
Tool Gateway / PEP
负责不可绕过的确定性授权
↓
资源侧访问控制
负责在数据库、文件系统和业务系统再次校验

模型网关则位于每次模型调用的入口，负责上下文和外部 AI 供应链控制。

确定性策略只能守住“明确边界”

七域架构最擅长处理的是规则清晰的风险：

没有delete权限，不允许删除 没有financial_db权限，不允许访问 Restricted数据不能发送至外部地址 超过1万元的转账必须人工确认 生产环境不允许执行任意Shell

这些规则可以结构化，可以通过代码确定执行。

但大量 Agent 风险并不是简单的权限越界，而是“授权范围内的错误行为”。

例如，一个客服 Agent 有权退款，但它可能因为理解错误，对不符合条件的订单进行退款。

一个邮件 Agent 有权向客户发送邮件，但它可能发送不准确、带有误导性的承诺。

一个代码 Agent 有权修改仓库，却可能在合法文件中植入后门。

一个运维 Agent 有权重启服务，却可能在错误时间重启核心生产系统。

这些动作从工具和资源权限上看都是合法的，真正的问题在于：

• 是否符合当前任务
• 是否符合用户真实意图
• 参数是否合理
• 时机是否正确
• 是否偏离历史行为
• 多个合法步骤组合后是否形成风险

这类问题很难仅用静态规则解决，仍然需要模型检测、任务对齐、异常行为识别和人工确认。

因此，企业 Agent 安全更合理的组合是：

确定性策略 负责明确、不可突破的硬边界

语义安全模型 负责识别难以枚举的行为风险

人工确认 负责处理高影响和高不确定性动作

三者不是替代关系。

从输入输出护栏走向执行控制平面

这篇论文没有提出一种新的提示注入检测算法，也没有真正实现完整的七域安全系统。

身份验证、凭据代理、不可变审计和治理平台主要停留在架构设计阶段。公开实验只验证了权限和简单数据流策略，25个场景也不足以证明其具备真实 Agent 环境中的泛化能力。

但论文仍然提出了一个值得重视的判断：

企业 Agent 的核心安全边界不应建立在大模型是否听话之上，而应建立在真实动作是否经过不可绕过的运行时控制之上。

对于聊天机器人，输入输出护栏可能已经能够覆盖主要风险。

对于能够调用工具的 Agent，安全控制必须继续向下延伸到：

• Agent代表谁行动
• 权限从哪里获得
• 凭据如何使用
• 哪些工具可以访问哪些资源
• 数据可以流向哪里
• 每次动作如何审计
• 策略如何发布和治理

这正是七域架构的价值。

它没有让模型变得确定，也没有消除提示注入，而是尝试在不确定的模型和确定的业务系统之间，建立一个可验证、可审计、默认拒绝的执行控制平面。

未来企业部署 Agent 时，真正需要回答的可能不再只是“模型有没有安全护栏”，而是另一个更具体的问题：

当模型判断错误，甚至已经被攻击者控制时，系统中还有哪一道边界能够阻止错误动作真正发生？