Policy Engine：AI Agent 时代的策略决策与安全执行核心
Policy Engine：AI Agent 时代的策略决策与安全执行核心
摘要
在传统企业系统中，权限控制通常由 RBAC、ABAC、ACL 等机制完成。但随着 AI Agent 从“生成内容”逐渐演变为“自主调用 Tool、访问数据、操作系统和执行现实世界动作”，传统权限模型开始暴露出明显局限。
Agent 不仅需要回答“用户是谁”，还需要回答：
- 这个 Agent 能否调用这个 Tool？
- 当前用户是否有权让 Agent 执行这个操作？
- Agent 能否访问这个 Resource？
- 当前参数是否满足安全规则？
- 当前数据是否允许流向目标系统？
- 当前风险是否需要人工审批？
- 当前调用是否违反租户、环境、时间或金额限制？
这些问题不能依赖 LLM 的 Prompt 来解决，而应该由一个独立、确定性、可审计的 Policy Engine 负责。
本文从 Policy Engine 的基本模型开始，深入分析 RBAC、ABAC、ReBAC、PBAC、Capability Security、Policy Decision Point、Policy Enforcement Point、Policy-as-Code、OPA/Rego、Cedar、规则编译、缓存、分布式一致性、AI Agent Tool Authorization、Risk-based Policy、Human-in-the-Loop、数据流控制以及企业级架构设计。
1. 什么是 Policy Engine
Policy Engine 可以简单理解为：
输入一个安全决策请求，输出一个确定性的策略决策。
最简单的模型：
Policy Engine
Input:
Subject
Action
Resource
Context
Output:
ALLOW
DENY
REVIEW
例如：
Subject:
user-123
Action:
customer.read
Resource:
customer-456
Context:
tenant = bank-a
Policy Engine：
DENY
因为：
user-123
没有访问
customer-456
的权限。
2. Policy Engine 与传统权限代码的区别
很多 Java 系统直接这样写：
if (user.isAdmin()) {
allow();
}
随着系统复杂化，代码逐渐变成：
if (
user.isAdmin()
|| (
user.department.equals(resource.department)
&& resource.status.equals("ACTIVE")
&& currentTime.isBefore(deadline)
&& request.amount < 10000
)
) {
allow();
}
然后继续：
if (tenant.equals(resource.tenant)
&& region.equals(resource.region)
&& environment.equals("production")
&& ...
)
最终：
Authorization Logic 开始污染业务代码。
这就是 Policy Engine 存在的核心原因。
业务代码负责：
Business Logic
Policy Engine 负责：
Security Decision
3. Policy Engine 的核心职责
一个企业级 Policy Engine 通常负责：
Authentication Context
|
v
Authorization
|
v
Policy Evaluation
|
+-- RBAC
+-- ABAC
+-- ReBAC
+-- Capability
+-- Risk
+-- Data Policy
+-- Network Policy
+-- Tenant Policy
+-- Compliance
|
v
Decision
它并不一定负责：
Identity Authentication
Tool Execution
Database Execution
更典型的职责边界是：
PDP
Policy Decision Point
而执行权限的系统叫：
PEP
Policy Enforcement Point
4. PDP 与 PEP
这是理解 Policy Architecture 最重要的两个概念。
PDP
Policy Decision Point：
"Should this action be allowed?"
负责：
Evaluate Policy
PEP
Policy Enforcement Point：
"Enforce the decision."
负责：
ALLOW -> Execute
DENY -> Block
完整流程：
User
|
v
Agent
|
v
PEP
|
| authorization request
v
PDP
|
| ALLOW / DENY / REVIEW
v
PEP
|
v
Tool
例如：
Agent
|
| call send_email
v
Tool Gateway
|
| PEP
v
Policy Engine
|
| DENY
v
Tool Gateway
|
X
Execution blocked
5. 为什么 Agent 特别需要 Policy Engine
传统应用：
User
|
v
API
|
v
Business Logic
Agent：
User
|
v
LLM
|
+-- Tool A
+-- Tool B
+-- Tool C
+-- Tool D
LLM 具有：
Non-determinism
Autonomy
Planning
Context dependence
Tool selection
因此不能把安全规则写成：
System Prompt:
Never call delete_user.
因为：
Prompt
!=
Security Boundary
真正安全的架构应该：
LLM
|
| "I want to call delete_user"
v
Policy Engine
|
| DENY
v
Tool Gateway
|
X
6. Policy Engine 的基本数学模型
可以将 Policy Decision 抽象成：
Decision = P(S, A, R, C)
其中：
S = Subject
A = Action
R = Resource
C = Context
例如：
P(
user-123,
customer.read,
customer-456,
{
tenant: bank-a,
ip: 10.10.1.20,
time: 10:30
}
)
返回：
DENY
更复杂的 Agent 场景：
Decision =
P(
User,
Agent,
Tool,
Action,
Resource,
Data,
Context,
Risk
)
因此 Agent Policy 比传统 RBAC 丰富得多。
7. Policy Decision 不应该只有 Allow / Deny
传统：
ALLOW
DENY
Agent 系统更适合：
ALLOW
DENY
REVIEW
STEP_UP
REDACT
TRANSFORM
例如：
send_email
如果发送内部邮件：
ALLOW
如果发送外部邮件：
REVIEW
如果包含 Secret：
DENY
如果只是包含 PII：
REDACT
例如：
Original:
Customer SSN:
123-45-6789
Policy：
REDACT
最终：
Customer SSN:
***-**-6789
因此 Policy Engine 可以从：
Authorization Engine
逐渐演化成：
Decision Engine
8. RBAC：Role-Based Access Control
RBAC 是最经典的权限模型：
User
|
v
Role
|
v
Permission
例如：
Alice
|
+-- ADMIN
|
+-- user.read
+-- user.write
+-- user.delete
优点：
简单
易理解
容易实现
容易管理
缺点：
角色爆炸
上下文能力弱
资源粒度不足
不适合复杂 Agent
例如：
customer-support-agent
不能简单地拥有：
customer.read
因为还需要判断：
哪个 customer？
哪个 tenant？
什么 purpose？
当前用户是否有权限？
9. Role Explosion
例如企业存在：
Department
Region
Level
Tenant
Environment
组合以后：
Engineer-US-Prod
Engineer-US-Dev
Engineer-EU-Prod
Engineer-EU-Dev
Manager-US-Prod
Manager-US-Dev
...
最终角色数量：
RoleCount =
Department × Region × Level × Environment × Tenant
这就是典型：
Role Explosion
因此现代 Policy Engine 通常会从：
RBAC
扩展到：
ABAC
10. ABAC：Attribute-Based Access Control
ABAC 不再只看：
Role
而是看：
Attributes
例如：
Subject:
department = finance
level = manager
Resource:
department = finance
classification = confidential
Context:
environment = production
Policy：
ALLOW if:
subject.department == resource.department
AND
subject.level >= manager
AND
resource.classification <= confidential
ABAC 的核心优势：
权限来自属性，而不是角色本身。
11. Agent 最适合 ABAC + RBAC
实际企业系统不应该简单选择：
RBAC vs ABAC
而应该：
RBAC
+
ABAC
例如：
Role:
customer-support
Attributes:
tenant = bank-a
region = US
clearance = confidential
Policy：
ALLOW customer.read
IF:
role == customer-support
AND
resource.tenant == subject.tenant
AND
resource.region == subject.region
这样既保留：
Role 管理简单
又具备：
Attribute 灵活性
12. ReBAC：Relationship-Based Access Control
ReBAC 进一步回答：
Subject 与 Resource 是什么关系？
例如：
User
|
+-- member_of --> Team A
|
+-- owns -------> Project A
|
+-- manages ----> Department A
Resource：
Project A
Policy：
ALLOW
if user is member of project.team
这种模型非常适合：
GitHub
Google Drive
Slack
Jira
CRM
Enterprise Knowledge Base
因为权限通常来自：
User
|
Relationship
|
Resource
13. Agent + ReBAC
例如：
Agent:
customer-support-agent
User:
Alice
Ticket:
Ticket-123
关系：
Alice
|
assigned_to
|
Ticket-123
Policy：
ALLOW
if
user.assigned_to(ticket)
Agent 可以代表 Alice 查询：
Ticket-123
但不能查询：
Ticket-999
这比：
customer.read = true
安全得多。
14. Capability Security
在 Agent 世界中，Capability Security 非常重要。
一个 Capability 可以表示：
Can perform action X
on resource Y
under constraints Z
例如：
Capability:
email.send
Resource:
internal.company.com
Constraint:
maxRecipients = 10
Agent 获得：
Capability
而不是：
Full Role
因此：
Agent
|
+-- customer.read
+-- ticket.create
+-- email.send
这是 Agent 最自然的权限模型之一。
15. Policy Engine 的输入模型
企业级 Policy Request 可以定义：
{
"subject": {
"id": "user-123",
"type": "user",
"roles": ["support"]
},
"agent": {
"id": "support-agent",
"version": "2.1"
},
"action": "customer.read",
"resource": {
"type": "customer",
"id": "customer-456",
"tenant": "bank-a"
},
"context": {
"environment": "production",
"ip": "10.0.1.10"
}
}
Policy Engine：
Request
|
v
Policy Evaluation
|
v
Decision
16. Decision Response
可以返回：
{
"decision": "ALLOW",
"policy": "customer-read-v3",
"reason": "same-tenant",
"obligations": []
}
或者：
{
"decision": "REVIEW",
"policy": "external-email-v2",
"reason": "external-recipient",
"obligations": [
"human_approval"
]
}
或者：
{
"decision": "DENY",
"policy": "secret-exfiltration-v1",
"reason": "secret-to-external-destination"
}
这比单纯：
true / false
更加适合企业系统。
17. Policy-as-Code
Policy Engine 最重要的技术思想之一：
Policy as Code
不要：
if (...) {
}
把所有权限逻辑硬编码在 Java。
而是：
Policy
|
v
Version Control
|
v
Testing
|
v
Review
|
v
Deployment
例如：
policies/
├── customer.rego
├── payment.rego
├── email.rego
├── tenant.rego
└── data.rego
这样 Policy 可以：
Git
Code Review
CI/CD
Versioning
Rollback
Testing
18. OPA：Open Policy Agent
OPA 是 Policy-as-Code 的经典实现。
架构：
Application
|
| Query
v
OPA
|
v
Policy
Policy 使用 Rego 表达。
例如：
package agent.authz
default allow = false
allow {
input.subject.tenant == input.resource.tenant
input.action == "customer.read"
}
Java 服务：
Spring Boot
|
v
OPA
|
v
ALLOW / DENY
这样业务代码不需要知道具体权限规则。
19. Rego 的思想
Rego 不是传统：
if / else
而是：
Policy =
Data
+
Rules
例如：
allow {
input.user.role == "admin"
}
或者：
allow {
input.user.department == input.resource.department
input.action == "read"
}
这种方式特别适合：
Complex Authorization
Infrastructure Policy
Kubernetes Policy
API Authorization
Agent Security
20. Cedar：另一种现代 Policy Language
Cedar 的核心思想也是：
Policy as Code
例如概念上：
permit (
principal,
action == Action::"Read",
resource
)
when {
principal.department == resource.department
};
它强调：
Formal Authorization Model
Predictable Evaluation
Typed Entities
因此现代企业可以根据场景选择：
OPA / Rego
Cedar
自研 Policy DSL
21. Policy Engine 的内部架构
一个成熟 Policy Engine 内部可以分为：
Policy Engine
|
+-------------+-------------+
| | |
v v v
Policy Store Compiler Schema
| | |
+-------------+-------------+
|
v
Evaluation Core
|
+------+------+
| |
v v
Decision Explain
|
v
Cache Layer
核心组件：
Policy Store
Policy Loader
Policy Compiler
Schema Validator
Evaluation Engine
Decision Cache
Explain Engine
Audit
22. Policy Store
Policy 可以存储在：
Git
Database
Object Storage
Config Service
Kubernetes ConfigMap
推荐：
Git
+
CI/CD
+
Policy Distribution
例如：
Git
|
v
Policy CI
|
+-- Syntax Check
+-- Unit Test
+-- Security Test
|
v
Policy Bundle
|
v
Policy Engine
23. Policy Compilation
如果每次请求都解析：
YAML
JSON
Rego
DSL
性能会非常差。
因此：
Policy Source
|
v
Parse
|
v
Compile
|
v
Optimized Representation
|
v
Runtime Evaluation
请求路径只做：
Evaluate
而不是：
Parse + Compile + Evaluate
24. Policy Evaluation 性能
在高并发系统中：
API Request
可能达到：
100k QPS
如果每次都：
Network -> Policy Server -> DB
延迟可能非常高。
例如：
Application
|
v
Policy Engine
|
v
Database
形成：
P99 = 50ms
对于一个简单 API：
Business logic = 10ms
Authorization = 50ms
明显不可接受。
25. Sidecar / Embedded Policy Engine
解决方案之一：
Application
|
+-- Policy Sidecar
|
+-- Business Service
或者：
Application
|
+-- Embedded Policy Engine
架构：
Service Pod
+---------------------+
| |
| Application |
| | |
| v |
| Policy Engine |
| |
+---------------------+
优点：
低延迟
无网络 Hop
高吞吐
缺点：
Policy Distribution
Memory
Version Consistency
需要解决。
26. Policy Distribution
假设有：
1000
个微服务实例。
Policy 更新：
v10 -> v11
需要：
Policy Control Plane
|
v
Distribution
|
+------+------+------+
| | | |
v v v v
Pod1 Pod2 Pod3 PodN
常见方式：
Polling
Push
Pub/Sub
Kafka
gRPC Streaming
Config Center
27. Policy Consistency
一个非常重要的问题：
Pod A -> Policy v10
Pod B -> Policy v11
这时：
同一个请求
可能：
A -> ALLOW
B -> DENY
因此 Policy Engine 需要：
Policy Version
例如：
{
"decision": "DENY",
"policy_version": "2026.08.23.17"
}
这样审计时可以知道：
这个决策是在什么版本的 Policy 下产生的？
28. Decision Cache
Policy Decision 很多时候具有高重复性。
例如：
user-123
customer.read
customer-456
连续调用 100 次。
可以缓存：
Cache Key =
subject
+
action
+
resource
+
context
+
policyVersion
例如：
ALLOW
TTL = 30s
但必须注意：
Authorization Cache 最大的问题不是性能，而是权限撤销后的 stale decision。
29. Cache Invalidation
例如：
10:00
User has permission
10:01
Admin revokes permission
10:02
Cache still says ALLOW
于是：
Security Violation
因此高风险权限：
Payment
Delete
Production
Secret
不应该简单使用长 TTL。
可以采用：
Risk-based TTL
例如：
READ:
60s
WRITE:
10s
PAYMENT:
0s
DELETE:
0s
30. Explainability：为什么允许？
企业 Policy Engine 必须解决：
Why was this request allowed?
例如：
ALLOW
还需要：
Policy:
customer-read-v3
Reason:
same tenant
Matched:
subject.tenant == resource.tenant
这叫：
Policy Decision Explanation
对于：
Compliance
Audit
Security Investigation
Production Debugging
非常重要。
31. 为什么 Agent 更需要 Explainability
例如 Agent：
Agent:
customer-support-agent
突然调用：
delete_customer
Security Team 必须回答：
Who allowed this?
Which policy?
Which user?
Which agent version?
Which resource?
Which context?
所以一个完整的 Agent Decision Trace：
User Request
|
v
Agent Reasoning
|
v
Tool Selection
|
v
Policy Request
|
v
Policy Decision
|
v
Tool Execution
必须全部可以关联。
32. Policy 与 Agent Tool Security
对于 Tool Security，可以定义：
Tool Policy
例如：
tool: send_email
allow:
- agent: support-agent
recipient_domain:
- company.com
deny:
- data.classification: SECRET
review:
- recipient.external: true
于是：
LLM
|
| send_email
v
Policy Engine
|
+-- recipient
+-- data
+-- agent
+-- user
+-- risk
|
v
Decision
33. Risk-Based Policy
传统 Policy：
ALLOW / DENY
Agent 更适合：
Risk
例如：
Risk = f(
tool,
data,
user,
resource,
destination,
amount,
context
)
然后：
Risk < 30
ALLOW
30-70
ALLOW + MONITOR
70-90
REVIEW
> 90
DENY
34. Policy 与 Risk Engine 的区别
两者不能混为一谈。
Policy Engine：
"Is this allowed?"
Risk Engine：
"How dangerous is this?"
因此：
Risk Engine
|
v
Risk = 82
|
v
Policy Engine
|
v
REVIEW
架构：
Tool Request
|
+---------+---------+
| |
v v
Authorization Risk Engine
| |
+---------+---------+
|
v
Policy Engine
|
v
ALLOW / DENY / REVIEW
35. Policy Obligation
Policy 不仅可以返回：
ALLOW
还可以返回：
Obligation
例如：
{
"decision": "ALLOW",
"obligations": [
"mask_pii",
"audit",
"limit_to_10_records"
]
}
于是：
Tool Gateway
执行：
Mask PII
+
Limit Results
+
Audit
这使 Policy Engine 从：
Authorization
扩展到：
Control Plane
36. Policy 与数据安全
例如：
Resource:
customer-profile
Classification:
PII
Tool：
send_email
Destination：
external
Policy：
IF
data.classification == PII
AND
destination == external
THEN
DENY
或者：
THEN
REDACT
这种设计可以实现：
Data-centric Security
而不是只做：
API-centric Security
37. Policy Engine 与 Zero Trust
Zero Trust 的核心：
Never Trust
Always Verify
Policy Engine 正是 Zero Trust 的决策核心。
每一次：
Tool Call
API Call
Data Access
Production Operation
都应该：
Authenticate
Authorize
Evaluate
Enforce
Audit
因此：
Agent Security
+
Policy Engine
+
Zero Trust
天然适配。
38. Multi-Tenant Policy
SaaS / Enterprise Agent 必须支持：
Tenant
例如：
Tenant A
Tenant B
Tenant C
Policy：
ALLOW
if
subject.tenant == resource.tenant
这是最基础的 Tenant Isolation。
更复杂：
tenant.policy
每个租户可以拥有：
Allowed Tools
Data Classification
External Domains
Approval Rules
Retention
Region
例如：
tenant: bank-a
tools:
allow:
- customer.read
- ticket.create
external_domains:
allow: []
approval:
payment: required
39. Policy Hierarchy
企业 Policy 经常存在多层：
Global Policy
|
v
Organization Policy
|
v
Tenant Policy
|
v
Agent Policy
|
v
User Policy
最终：
Effective Policy
可以定义：
EffectivePolicy =
Global
∩
Organization
∩
Tenant
∩
Agent
∩
User
注意：
权限通常应该取交集，而不是并集。
这样可以防止下层策略绕过上层安全约束。
40. Policy Conflict
假设：
Global:
DENY external email
Tenant:
ALLOW external email
最终应该：
DENY
因为：
Global Security Boundary
不能被 Tenant Policy 放宽。
可以定义 Policy Priority：
Deny
>
Allow
或者：
Security Level
>
Tenant Level
>
Agent Level
41. Policy Evaluation Algorithm
一种典型流程：
1. Load Subject
2. Load Agent
3. Load Resource
4. Load Action
5. Load Context
6. Load Data Classification
7. Evaluate Global Policy
8. Evaluate Tenant Policy
9. Evaluate Agent Policy
10. Evaluate User Policy
11. Evaluate Risk
12. Resolve Conflict
13. Generate Decision
14. Generate Obligations
15. Audit
最终：
Decision
42. Policy Engine 的 Java 架构
对于 Spring Boot，可以设计：
com.example.policy
|
+-- controller
| +-- PolicyController
|
+-- model
| +-- AuthorizationRequest
| +-- Decision
| +-- PolicyContext
|
+-- engine
| +-- PolicyEngine
| +-- RuleEvaluator
| +-- ConflictResolver
|
+-- repository
| +-- PolicyRepository
|
+-- cache
| +-- DecisionCache
|
+-- audit
| +-- PolicyAuditService
核心接口：
public interface PolicyEngine {
Decision evaluate(
AuthorizationRequest request
);
}
43. AuthorizationRequest
public record AuthorizationRequest(
Subject subject,
AgentContext agent,
String action,
Resource resource,
Map<String, Object> context
) {}
Decision：
public record Decision(
DecisionType type,
String policyId,
String reason,
List<Obligation> obligations
) {}
其中：
public enum DecisionType {
ALLOW,
DENY,
REVIEW
}
44. Policy Evaluation Pipeline
可以采用责任链：
public Decision evaluate(
AuthorizationRequest request) {
Decision global =
globalPolicy.evaluate(request);
if (global.isDenied()) {
return global;
}
Decision tenant =
tenantPolicy.evaluate(request);
if (tenant.isDenied()) {
return tenant;
}
Decision agent =
agentPolicy.evaluate(request);
if (agent.isDenied()) {
return agent;
}
return userPolicy.evaluate(request);
}
但生产系统中不建议无限堆叠 if。
应该抽象成：
Policy Evaluation Pipeline
45. Policy Rule Engine
可以设计：
public interface PolicyRule {
boolean matches(PolicyContext context);
Decision evaluate(PolicyContext context);
}
例如：
public class SameTenantRule
implements PolicyRule {
@Override
public boolean matches(
PolicyContext context) {
return context.subject().tenant()
.equals(context.resource().tenant());
}
@Override
public Decision evaluate(
PolicyContext context) {
return Decision.allow(
"same-tenant"
);
}
}
这样规则可以：
组合
测试
替换
排序
版本化
46. Policy DSL
企业规模继续扩大后，可以设计 DSL：
permit customer.read
when
subject.tenant == resource.tenant
and subject.role in ["support", "manager"]
and context.environment != "sandbox"
或者：
deny email.send
when
data.classification == SECRET
DSL 的价值：
Security Policy
可以由：
Security Team
Platform Team
Compliance Team
共同维护，而不需要所有人修改 Java。
47. Policy Testing
Policy-as-Code 最大的优势之一是：
Policy 可以像代码一样测试。
例如：
Given:
user.department = finance
And:
resource.department = finance
When:
action = read
Then:
ALLOW
测试：
Given:
user.department = finance
And:
resource.department = hr
Then:
DENY
48. Property-Based Policy Testing
更高级的方式：
不只测试具体案例，而是测试安全属性。
例如：
Property:
If subject.tenant != resource.tenant,
decision must never be ALLOW.
可以形式化：
∀ request:
request.subject.tenant
!=
request.resource.tenant
=> DENY
这对于：
Multi-Tenant
Data Isolation
Financial Systems
非常重要。
49. Policy Mutation Testing
还可以故意修改 Policy：
Original:
deny secret -> external
Mutation：
allow secret -> external
然后：
Security Test
必须失败。
如果测试仍然通过：
Policy Test Suite 不够强。
这是非常值得企业安全平台采用的方法。
50. Policy Engine 的高可用设计
Policy Engine 如果挂掉：
所有业务请求
可能受到影响。
因此需要：
Policy Engine Cluster
例如：
Load Balancer
|
+---------+---------+
| | |
v v v
PDP-1 PDP-2 PDP-3
| | |
+---------+---------+
|
Policy Store
Policy 本身尽可能：
Read-only
Immutable
Locally Cached
这样即使：
Policy Store
短暂不可用：
PDP
仍然可以继续决策。
51. Fail Open vs Fail Closed
这是 Policy Engine 最关键的架构选择之一。
如果 Policy Engine 不可用：
ALLOW
叫：
Fail Open
如果：
DENY
叫：
Fail Closed
对于：
Payment
Delete
Secret
Production
应该：
Fail Closed
对于：
Public Read
Search
Non-sensitive operation
可以根据业务考虑：
Fail Open
因此更合理的是：
Risk-based Failure Mode
52. Policy Engine 的性能目标
对于在线 Tool Authorization：
建议关注：
P50
P95
P99
QPS
CPU
Memory
Cache Hit Rate
Policy Load Time
例如目标：
P99 < 5ms
如果采用：
Local PDP
Compiled Policy
In-memory Data
可以达到非常低的延迟。
但如果：
Application
-> Network
-> PDP
-> Database
延迟会明显增加。
53. Policy Engine 与 Redis
Redis 很适合：
Decision Cache
Policy Metadata
Short-lived Authorization Context
Rate Limit
Revocation State
例如：
policy:decision:
user-123:
customer.read:
customer-456
但是：
Redis 不能成为 Policy 的唯一 Source of Truth。
更推荐：
Git / Policy Store
|
v
Policy Distribution
|
v
PDP Memory
|
v
Redis / Local Cache
54. Policy Engine 与 Kafka
Kafka 可以用于：
Policy Update Event
例如：
Policy Repository
|
v
Policy Updated
|
v
Kafka
|
+----+----+----+
| | | |
v v v v
PDP1 PDP2 PDP3 PDPN
每个 PDP 收到：
policy-version = 2026.08.23.18
然后加载新 Policy。
这样可以构建：
Event-driven Policy Distribution
55. Policy Engine 与 OpenTelemetry
Policy Engine 也应该被纳入 Trace。
例如：
Trace
|
+-- agent.request
|
+-- tool.call
|
+-- policy.evaluate
|
+-- tool.execute
Policy Span：
policy.id
policy.version
decision
reason
subject
action
resource
evaluation.time
注意：
不要把密码、Token、Secret、完整 PII 放入 Trace Attributes。
Observability 本身也必须遵守 Data Security Policy。
56. Policy Engine 的安全边界
Policy Engine 本身是高价值目标。
攻击者如果能够：
Modify Policy
那么：
整个安全系统
都可能被绕过。
因此必须保护：
Policy Source
Policy Distribution
Policy Engine
Policy Cache
Policy Update API
特别是：
Policy Update
必须具备：
Authentication
Authorization
Approval
Versioning
Audit
Rollback
57. Policy Signing
进一步可以对 Policy Bundle 进行签名：
Policy Source
|
v
Compile
|
v
Bundle
|
v
Sign
|
v
Deploy
PDP：
Bundle
|
v
Verify Signature
|
v
Load
这样可以防止：
Policy Supply Chain Attack
58. Policy Supply Chain Security
企业 Agent 平台可能依赖：
Policy Package
Tool Package
MCP Server
Model
Prompt
Plugin
这些都形成：
AI Supply Chain
Policy Engine 必须关注：
Who created policy?
Who approved it?
Which version?
Who deployed it?
Was it modified?
这与传统：
Software Supply Chain Security
非常类似。
59. Policy Engine 与 MCP
如果 Agent 使用 MCP Tool：
Agent
|
v
MCP Client
|
v
MCP Server
|
v
Tool
推荐增加：
Policy Gateway
变成：
Agent
|
v
MCP Client
|
v
Policy Gateway
|
v
MCP Server
|
v
Tool
Policy Gateway 可以控制：
Which MCP Server
Which Tool
Which Resource
Which User
Which Tenant
Which Data
因此：
MCP 解决 Tool Communication，Policy Engine 解决 Tool Authorization。
60. 一个完整的 Agent Policy Decision
例如用户：
帮我把客户 123 的资料发送到外部邮箱。
Agent：
Tool:
send_email
Policy Request：
{
"subject": "user-123",
"agent": "support-agent",
"action": "email.send",
"resource": "customer-123",
"destination": "external",
"dataClassification": "PII"
}
Policy Engine：
1. User has customer.read
2. Agent has email.send
3. Customer belongs to user tenant
4. Data = PII
5. Destination = external
6. External PII prohibited
最终：
DENY
注意：
Agent 即使已经：
成功读取客户资料
也不意味着：
可以把资料发送到任何地方。
这就是：
Fine-grained Policy Enforcement
61. Policy Engine 的最终架构
一个完整企业级架构可以设计成：
User
|
v
+-------------+
| Identity |
+------+------+
|
v
+-------------+
| AI Agent |
+------+------+
|
v
Tool Request
|
v
+----------------------+
| Policy Gateway |
+----------------------+
|
+----------------+----------------+
| | |
v v v
Identity Policy PDP Risk Engine
| | |
| +-----+-----+ |
| | | |
| v v |
| RBAC ABAC |
| | | |
+----------+-----------+----------+
|
v
Decision Resolver
|
+------------+------------+
| | |
v v v
ALLOW REVIEW DENY
|
v
DLP / Obligation
|
v
Tool Executor
|
+------+------+
| |
v v
Enterprise External
Systems Systems
|
v
Audit
|
v
OpenTelemetry
62. Policy Engine 最核心的设计思想
如果只记住几个概念，可以记住：
Policy
=
Who
+
Can Do What
+
To What
+
Under Which Conditions
对于 Agent：
Policy
=
User
+
Agent
+
Tool
+
Action
+
Resource
+
Data
+
Context
+
Risk
最终：
Decision
=
ALLOW
|
DENY
|
REVIEW
|
OBLIGATION
63. Policy Engine 与传统 RBAC 的演进
整个权限技术可以看成：
ACL
|
v
RBAC
|
v
ABAC
|
v
ReBAC
|
v
PBAC
|
v
Capability Security
|
v
Risk-based Authorization
|
v
Agent Policy Engine
未来 Agent Security 很可能不是某一种模型取代另一种模型，而是：
RBAC
+
ABAC
+
ReBAC
+
Capability
+
Risk
+
Data Policy
统一进入：
Policy Decision Platform
64. 从 Authorization Engine 到 Agent Policy Engine
传统 Authorization：
Can user access resource?
Agent Policy：
Can this user,
through this agent,
using this capability,
perform this action,
against this resource,
with this data,
under this context,
with this risk,
at this moment?
这就是两者最本质的区别。
65. 最终总结
Policy Engine 并不是简单的：
if user.isAdmin()
它是企业 AI Agent 的：
Decision Control Plane
它把：
Identity
Authorization
RBAC
ABAC
ReBAC
Capability
Risk
Data Classification
Tenant Isolation
Human Approval
Audit
统一起来。
最重要的架构原则可以总结成：
LLM decides intent.
|
v
Policy Engine decides permission.
|
v
Tool Gateway enforces decision.
|
v
Sandbox limits execution.
|
v
DLP controls information flow.
|
v
Audit records everything.
因此，真正成熟的 Agent 平台，不应该是：
LLM
+
Tools
而应该是：
+----------------+
| User |
+-------+--------+
|
v
+---------------+
| Agent |
+-------+-------+
|
v
+-------------------+
| Policy Engine |
+-------------------+
|
+-----------+-----------+
| | |
v v v
Identity Risk DLP
| | |
+-----------+-----------+
|
v
Tool Gateway
|
v
Tools
|
v
Real World
最终可以用一句话概括：
Policy Engine 的价值，不是告诉 AI 应该做什么，而是在 AI 决定做什么之后，确定它究竟有没有资格做。
而在 Agent 时代，这个“资格”已经不再只是传统的 User → Permission，而是 User → Agent → Capability → Tool → Action → Resource → Data → Context → Risk 的多维授权模型。
如果你接下来要继续深入 Agent Security，最值得展开的是 ① OPA/Rego 实战实现、② Agent Authorization + Capability Security、③ Policy Engine + Tool Gateway 企业级架构，你更想先看哪一个？
