AI Agent 安全架构：身份、权限与边界控制完全指南

前言：AI Agent 安全已不是选修课

2026 年，AI Agent 系统的安全风险已经从理论讨论变成了生产事故。

Claude Code 删库事件（2026 年 4 月）让整个行业意识到：当 AI Agent 拥有工具调用能力时，传统的边界防护模型已经不够用了。攻击者不再需要直接入侵你的系统——他们只需要让一个拥有工具权限的 Agent 执行错误的操作。

CISA 等机构联合发布的 Agentic AI 安全部署指南，指出了当前最大的问题：大多数企业在部署 AI Agent 时，先考虑功能实现，再考虑安全加固。这是传统软件开发的思维，但在 Agent 系统里，这个顺序是致命的——因为 Agent 的行为边界远比传统软件模糊，一个配置错误可能导致 Agent 访问不该访问的资源。

本文给出 AI Agent 安全架构的四个核心维度：身份与认证（Authentication）→ 权限与访问控制（Authorization）→ 数据边界（Data Boundaries）→ 审计与追溯（Audit & Traceability）。每个维度给出具体的架构模式和工程实践。

第一层：身份与认证——Agent 也是身份

Agent 身份的特殊性

传统软件系统的身份模型是「人 → 服务 → 数据」。身份的主体是人或服务，身份在部署时确定，之后相对静态。

AI Agent 系统的身份模型要复杂得多：

Agent 的行为由 LLM 驱动，行为是动态的——同一个 Agent 代码，模型参数不同，行为可能不同
Agent 可以被提示词诱导改变行为——这不是 bug，是 LLM 的本质特性
Agent 的身份和工具权限需要解耦——一个 Agent 可能有多个角色，每个角色有不同的权限级别

这意味着 AI Agent 系统的身份管理需要比传统软件更精细的模型。

Agent 身份的类型

类型一：部署身份（Deployment Identity）

Agent 进程在启动时被分配的运行时身份，用于 Agent 与平台、其他 Agent、第三方服务之间的通信认证。

1
# Agent 部署时的身份配置示例
2
agent_identity:
3
  id: "agent-coder-prod-03"
4
  type: "coding_agent"
5
  deployment_context:
6
    environment: "production"
7
    team: "platform-engineering"
8
    version: "2.4.1"
9
  runtime_credentials:
10
    # 用于向 MCP Server 等服务认证
11
    mcp_auth_token: "${AGENT_MCP_TOKEN}"
12
    # 用于 Agent 间通信
13
    agent_secret: "${AGENT_SECRET}"

部署身份的核心价值是建立最小权限的认证基础——Agent 只能访问它被授权访问的资源，即使提示词被注入，运行时身份层面的权限控制仍然有效。

类型二：会话身份（Session Identity）

用户与 Agent 交互时，Agent 代表用户行事时所具有的身份。在企业场景里，这是「代理用户身份」。

1
用户 A 与 Agent 对话
2
Agent 以「用户 A 的身份」执行操作
3
→ Agent 的操作权限 = 用户 A 的权限（最小权限原则）
4
→ 任何超越用户 A 权限的操作被拒绝

会话身份的关键设计点是动态权限降级：用户的权限级别可能很高，但 Agent 在执行特定操作时需要更严格的权限验证（比如财务操作需要二次确认）。

类型三：工具身份（Tool Identity）

当 Agent 调用外部工具或 API 时，工具也需要身份。典型场景是 MCP Server——Agent 通过 MCP 协议调用工具，MCP Server 需要验证「这个 Agent 有没有权限调用这个工具」。

认证架构模式

模式一：JWT + Agent Identity Certificate

1
Agent 启动 → 向 Identity Provider 请求 JWT
2
    ↓
3
Agent 调用工具 → 携带 JWT
4
    ↓
5
MCP Server 验证 JWT → 检查 Agent 身份和权限声明
6
    ↓
7
授权决策（基于策略）

1
# Agent 端的认证实现
2
import jwt
3
from datetime import datetime, timedelta
4

5
def create_agent_token(agent_id: str, permissions: list[str]) -> str:
6
    payload = {
7
        "agent_id": agent_id,
8
        "permissions": permissions,
9
        "iat": datetime.utcnow(),
10
        "exp": datetime.utcnow() + timedelta(hours=1),
11
        "jti": f"{agent_id}-{datetime.utcnow().timestamp()}"  # 唯一标识，防重放
12
    }
13
    # 使用 Agent 私钥签名
14
    return jwt.encode(payload, AGENT_PRIVATE_KEY, algorithm="RS256")
15

16
# MCP Server 端的验证实现
17
def verify_agent_token(token: str) -> dict:
18
    try:
19
        payload = jwt.decode(token, IDENTITY_PROVIDER_PUBLIC_KEY, algorithms=["RS256"])
20

21
        # 检查 Token 是否在黑名单（已撤销的 Token）
22
        if is_token_revoked(payload["jti"]):
23
            raise PermissionError("Token has been revoked")
24

25
        return payload
26
    except jwt.ExpiredSignatureError:
27
        raise PermissionError("Token has expired")
28
    except jwt.InvalidTokenError:
29
        raise PermissionError("Invalid token")

模式二：mTLS（双向 TLS）

在高安全要求场景（如金融、医疗），JWT 可能被伪造或泄露。mTLS 提供更强壮的认证——每个 Agent 持有唯一的客户端证书，证书与 Agent 身份的绑定在 CA 层面保证。

1
MCP Server 持有 CA 证书
2
Agent 持有 Agent 证书（由 CA 签发，包含 Agent ID 和权限范围）
3
Agent 连接 MCP Server → 双方交换证书 → 双向验证

mTLS 的优势是身份不可伪造（除非私钥泄露），缺点是证书管理复杂，适合有成熟 PKI 基础设施的企业。

第二层：权限与访问控制——最小权限的精细化实现

权限模型的选择：RBAC vs ABAC vs RAGAS

RBAC（Role-Based Access Control）

将权限分配给角色，角色分配给 Agent：

1
Agent 角色：Coder_Agent
2
角色权限：read_codebase, write_file, execute_tests

RBAC 的优点是简单直观，缺点是粒度粗。当同一个 Agent 在不同场景需要不同权限时，RBAC 需要维护多个角色。

ABAC（Attribute-Based Access Control）

基于属性的权限控制，权限决策考虑多种属性：

1
Agent 属性：{ environment: "production", team: "platform", clearance: "level2" }
2
资源属性：{ type: "database", sensitivity: "high", owner: "finance" }
3
环境属性：{ time: "business_hours", location: "office_network" }
4

5
权限决策：若 Agent.clearance >= resource.sensitivity → 允许访问

ABAC 的优点是灵活性高，可以表达复杂的权限逻辑，缺点是策略定义和维护复杂。

RAGAS（Risk-Driven Access control for AI Agents）

2026 年新提出的权限模型，专门针对 AI Agent 场景。核心思路是根据操作风险等级动态调整权限：

1
低风险操作（读取公开信息）：直接放行
2
中风险操作（修改文件、调用外部 API）：提示词层面确认
3
高风险操作（删除数据、执行系统命令）：强制二次认证
4
极危险操作（跨租户访问、绕过审计日志）：直接拒绝

RAGAS 的优势是安全与用户体验的平衡——低风险操作不打扰用户，高风险操作强制验证。但实现复杂度最高。

工具权限的分层控制

工具调用是 AI Agent 安全最脆弱的环节。当 Agent 可以「做任何事」时，提示词注入攻击可以让 Agent 执行恶意操作。

层级一：工具白名单

只允许 Agent 调用白名单内的工具：

1
# MCP Server 端工具注册
2
class ToolRegistry:
3
    def __init__(self):
4
        self.tools = {}
5

6
    def register(self, tool: Tool, allowed_roles: list[str]):
7
        self.tools[tool.name] = {
8
            "implementation": tool,
9
            "allowed_roles": allowed_roles,
10
            "risk_level": tool.risk_level
11
        }
12

13
    def check_permission(self, agent_role: str, tool_name: str) -> bool:
14
        if tool_name not in self.tools:
15
            return False  # 工具不存在，直接拒绝
16
        return agent_role in self.tools[tool_name]["allowed_roles"]
17

18
# 工具定义时的权限声明
19
class FileWriteTool(Tool):
20
    name = "file_write"
21
    risk_level = "medium"
22

23
    @tool_permission(allowed_roles=["coder", "devops"])
24
    def execute(self, path: str, content: str):
25
        ...

层级二：参数级别控制

不仅是「能不能调用这个工具」，还要控制「能操作什么资源」：

1
# 文件操作工具的参数级别权限控制
2
class FileWriteTool(Tool):
3
    def execute(self, path: str, content: str, agent_context: AgentContext):
4
        # 检查 Agent 是否有权限写这个路径
5
        allowed_paths = get_agent_allowed_paths(agent_context.agent_id)
6

7
        # 路径必须是 allowed_paths 列表的子路径
8
        if not any(path.startswith(allowed) for allowed in allowed_paths):
9
            raise PermissionError(f"Agent not allowed to write to {path}")
10

11
        # 额外的危险路径检查
12
        DANGEROUS_PATHS = ["/etc/", "/var/", "/root/", ".ssh/"]
13
        if any(path.startswith(dangerous) for dangerous in DANGEROUS_PATHS):
14
            raise PermissionError(f"Cannot write to system path: {path}")

层级三：操作审计（所有操作都记录）

无论权限检查通过还是拒绝，所有操作都要有日志：

1
class AuditedToolWrapper(Tool):
2
    def __init__(self, tool: Tool):
3
        self.tool = tool
4

5
    def execute(self, *args, agent_context: AgentContext, **kwargs):
6
        # 记录操作尝试（无论成功与否）
7
        audit_log.write({
8
            "timestamp": datetime.utcnow().isoformat(),
9
            "agent_id": agent_context.agent_id,
10
            "agent_role": agent_context.role,
11
            "tool": self.tool.name,
12
            "args": sanitize_args(args),  # 脱敏后记录
13
            "decision": "pending",
14
            "risk_level": self.tool.risk_level
15
        })
16

17
        try:
18
            result = self.tool.execute(*args, **kwargs)
19
            audit_log.update_last(
20
                decision="allowed",
21
                result="success"
22
            )
23
            return result
24
        except PermissionError as e:
25
            audit_log.update_last(
26
                decision="denied",
27
                reason=str(e)
28
            )
29
            raise
30
        except Exception as e:
31
            audit_log.update_last(
32
                decision="error",
33
                reason=str(e)
34
            )
35
            raise

MCP 安全：模型上下文协议的安全实践

MCP（Model Context Protocol）是 2026 年 AI Agent 生态中最流行的工具调用协议，但它的安全模型在默认配置下存在隐患。

MCP 的默认安全假设

MCP 协议假设 Agent 和 MCP Server 在同一信任边界内。这个假设在以下场景失效：

Agent 部署在用户设备上，MCP Server 部署在企业内网
Agent 从不可信来源获取提示词（用户输入或文件内容）
MCP Server 连接了多个不同信任级别的工具

MCP 安全加固实践

实践一：MCP Server 网络隔离

1
# MCP Server 网络配置
2
mcp_server:
3
  network:
4
    # 只接受来自特定网络的连接
5
    bind_address: "10.0.1.0/24"  # 企业内网段
6
    # 不暴露在公共网络
7
    public_exposed: false
8
    # 强制 TLS
9
    require_tls: true
10
    tls:
11
      cert: "/etc/mcp/tls.crt"
12
      key: "/etc/mcp/tls.key"

实践二：MCP 请求来源验证

1
class MCPRequestValidator:
2
    def validate(self, request: MCPRequest, context: RequestContext) -> bool:
3
        # 验证请求来源
4
        if not self.verify_source_trust(context.source_identity):
5
            return False
6

7
        # 验证请求范围（防止权限提升攻击）
8
        if not self.verify_scope(request.scope, context.granted_scope):
9
            return False
10

11
        # 验证操作频率（防止滥用）
12
        if self.rate_limiter.is_exceeded(context.agent_id):
13
            return False
14

15
        return True

实践三：工具调用的沙箱隔离

1
import subprocess
2
import resource
3

4
class SandboxedToolExecution:
5
    def execute(self, tool: Tool, args: dict, constraints: ExecutionConstraints):
6
        # 设置资源限制
7
        resource.setrlimit(resource.RLIMIT_CPU, (constraints.max_cpu_seconds,)*2)
8
        resource.setrlimit(resource.RLIMIT_AS, (constraints.max_memory_mb * 1024 * 1024,)*2)
9

10
        # 禁止网络访问（针对系统命令执行类工具）
11
        # 在容器级别实现网络隔离
12
        with isolated_network():
13
            result = tool.execute(**args)
14

15
        return result

第三层：数据边界——Agent 能看到什么数据

数据分类与 Agent 可见性

不是所有企业数据都应该对 Agent 可见。数据边界控制的目标是确保 Agent 只能访问它需要的最小数据集。

1
数据分类：
2
├── 公开数据（Public）：所有 Agent 可读
3
├── 内部数据（Internal）：特定团队的 Agent 可读
4
├── 敏感数据（Confidential）：需要特定权限才能访问的敏感信息
5
└── 绝密数据（Restricted）：即使 Agent 也不能直接访问，需要人工审批

敏感数据识别

1
class DataClassifier:
2
    # 常见的敏感数据模式
3
    SENSITIVE_PATTERNS = {
4
        "pii": [
5
            r"\b\d{3}-\d{2}-\d{4}\b",      # SSN
6
            r"\b\d{16}\b",                  # Credit Card
7
            r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}",  # Email
8
        ],
9
        "credentials": [
10
            r"api[_-]?key\s*[=:]\s*['\"]?\w+['\"]?",
11
            r"password\s*[=:]\s*['\"]?\w+['\"]?",
12
            r"-----BEGIN (RSA |EC )?PRIVATE KEY-----",
13
        ],
14
        "healthcare": [
15
            r"patient[_-]?id\s*[=:]\s*\w+",
16
            r"diagnosis[_-]?code\s*[=:]\s*\w+",
17
        ]
18
    }
19

20
    def classify(self, content: str) -> list[str]:
21
        findings = []
22
        for category, patterns in self.SENSITIVE_PATTERNS.items():
23
            for pattern in patterns:
24
                if re.search(pattern, content, re.IGNORECASE):
25
                    findings.append(category)
26
        return findings

RAG 检索的数据边界

当 Agent 使用 RAG（检索增强生成）时，数据边界控制更加复杂——需要确保检索结果不包含 Agent 不应该看到的数据。

方案一：向量数据库级别的访问控制

1
class AccessControlledVectorStore:
2
    def __init__(self, vector_db, access_control: AccessControlList):
3
        self.vector_db = vector_db
4
        self.access_control = access_control
5

6
    def query(self, query_embedding: list, agent_context: AgentContext, top_k: int):
7
        # 获取 Agent 的数据访问权限
8
        allowed_datasets = self.access_control.get_allowed_datasets(
9
            agent_id=agent_context.agent_id,
10
            data_level=agent_context.access_level
11
        )
12

13
        # 过滤检索范围
14
        results = self.vector_db.query(
15
            embedding=query_embedding,
16
            filter={"dataset_id": {"$in": allowed_datasets}},
17
            top_k=top_k
18
        )
19

20
        # 脱敏处理
21
        return self.sanitize(results)
22

23
    def sanitize(self, results: list) -> list:
24
        # 移除检索结果中的敏感字段
25
        for result in results:
26
            if "metadata" in result:
27
                # 移除敏感元数据
28
                result["metadata"] = {
29
                    k: v for k, v in result["metadata"].items()
30
                    if k not in ["user_email", "ssn", "credit_card"]
31
                }
32
        return results

方案二：RAG 结果的后置过滤

1
def rag_retrieve_with_filter(query: str, agent_context: AgentContext) -> list[Document]:
2
    # 正常检索
3
    raw_results = vector_db.query(query, top_k=20)
4

5
    # 后置过滤
6
    filtered_results = []
7
    for doc in raw_results:
8
        # 检查文档的数据级别
9
        doc_level = get_document_data_level(doc)
10
        agent_level = get_agent_access_level(agent_context)
11

12
        if agent_level >= doc_level:
13
            filtered_results.append(doc)
14
        else:
15
            # 记录访问被拒绝（但不透露文档内容）
16
            audit_log.record_access_denied(
17
                agent_id=agent_context.agent_id,
18
                document_id=doc.id,
19
                reason=f"Agent level {agent_level} < document level {doc_level}"
20
            )
21

22
    return filtered_results

第四层：审计与追溯——出了事怎么查

审计日志的设计原则

原则一：日志不可篡改

审计日志是事后调查的唯一依据，必须有防篡改机制：

1
import hashlib
2
import json
3
from datetime import datetime
4

5
class ImmutableAuditLog:
6
    def __init__(self, storage_backend):
7
        self.storage = storage_backend
8
        self.previous_hash = None
9

10
    def write(self, entry: dict):
11
        # 添加时间戳和序列号
12
        entry["timestamp"] = datetime.utcnow().isoformat()
13
        entry["sequence"] = self.storage.get_next_sequence()
14

15
        # 计算哈希链（类似区块链）
16
        entry["hash"] = self._compute_hash(entry, self.previous_hash)
17

18
        self.storage.append(entry)
19
        self.previous_hash = entry["hash"]
20

21
    def _compute_hash(self, entry: dict, previous_hash: str) -> str:
22
        # 包含前一条记录的哈希，形成链式结构
23
        content = json.dumps(entry, sort_keys=True) + (previous_hash or "")
24
        return hashlib.sha256(content.encode()).hexdigest()
25

26
    def verify(self) -> bool:
27
        """验证日志完整性"""
28
        for i, entry in enumerate(self.storage.get_all()):
29
            expected_previous = self.storage.get_entry(i-1)["hash"] if i > 0 else None
30
            if entry.get("previous_hash") != expected_previous:
31
                return False
32
        return True

原则二：记录所有决策点，不只是操作结果

1
不完整的日志：
2
[10:00] Agent: file_write /project/main.py → SUCCESS
3

4
完整的日志：
5
[10:00] Agent: file_write /project/main.py → SUCCESS
6
  Decision path:
7
    - User request: "Fix the bug in main.py"
8
    - Plan: [read main.py] → [analyze bug] → [write fix]
9
    - Tool call: read /project/main.py
10
    - Context: Found bug at line 42 (null pointer in API call)
11
    - Tool call: write /project/main.py
12
    - Content length: 245 bytes, modified lines: 40-45
13
  Risk check:
14
    - Path in allowed list: ✓
15
    - Contains sensitive data: ✗
16
    - External network access: ✗

可追溯性的实现架构

1
┌─────────────────────────────────────────────────────────────┐
2
│                     Agent System                             │
3
│  ┌──────────┐    ┌──────────────┐    ┌──────────────────┐  │
4
│  │  Planner │ →  │   Executor   │ →  │ Tool Call Layer  │  │
5
│  └──────────┘    └──────────────┘    └──────────────────┘  │
6
└─────────────────────────────────────────────────────────────┘
7
        │                │                     │
8
        ▼                ▼                     ▼
9
┌─────────────────────────────────────────────────────────────┐
10
│               Audit & Trace Collector                         │
11
│  - Decision logs (Planner outputs)                           │
12
│  - Execution logs (Executor state)                           │
13
│  - Tool call logs (arguments + results)                      │
14
└─────────────────────────────────────────────────────────────┘
15
        │
16
        ▼
17
┌─────────────────────────────────────────────────────────────┐
18
│              Immutable Audit Storage                          │
19
│  - Append-only log store                                      │
20
│  - Cryptographic hash chain                                   │
21
│  - Retention policy (compliance based)                        │
22
└─────────────────────────────────────────────────────────────┘
23
        │
24
        ▼
25
┌─────────────────────────────────────────────────────────────┐
26
│              Trace Reconstruction Service                     │
27
│  - Full trace reconstruction from logs                       │
28
│  - Anomaly detection                                          │
29
│  - Compliance reporting                                       │
30
└─────────────────────────────────────────────────────────────┘

受监管行业的落地建议

金融行业

金融行业对 AI Agent 的安全要求最为严格，几个关键点：

数据本地化：所有操作日志、审计记录必须在境内存储
模型可解释性：监管要求能够解释 Agent 的每个决策
双人审批：高风险操作需要两个人工审批节点
年度安全评估：Agent 系统必须通过独立的安全评估才能续期

建议架构：

1
用户请求 → Agent（受限环境）→ 工具调用（MCP，加密传输）
2
    ↓
3
所有操作写入本地审计日志（不可篡改）
4
    ↓
5
合规审查队列（人工 + 自动）
6
    ↓
7
定期生成监管报告

医疗行业

医疗行业的核心是 HIPAA 合规，关键点：

PHI（Protected Health Information）最小化暴露：Agent 只能看到它需要诊断/处理的那部分患者数据
去标识化：所有用于训练或测试的数据必须完全去标识化
访问审计：每次 PHI 访问都必须有完整的审计记录

建议架构：

1
class PHIAccessController:
2
    def check_phi_access(self, agent_context: AgentContext, patient_data: dict, purpose: str) -> bool:
3
        # 检查 Agent 是否有 PHI 访问权限
4
        if not agent_context.can_access_phi:
5
            return False
6

7
        # 检查访问目的（最小必要原则）
8
        if purpose not in ["treatment", "payment", "operations"]:
9
            return False
10

11
        # 检查最小必要原则（Agent 只能看到需要的部分）
12
        required_fields = get_minimum_necessary_fields(purpose, patient_data)
13
        filtered_data = {k: patient_data.get(k) for k in required_fields}
14

15
        # 记录 PHI 访问
16
        self.audit_phi_access(
17
            agent_id=agent_context.agent_id,
18
            patient_id=patient_data["patient_id"],
19
            fields_accessed=required_fields,
20
            purpose=purpose
21
        )
22

23
        return True

安全架构的技术选型小结

维度	推荐方案	适用场景
身份认证	JWT + Agent Identity Certificate	通用场景
身份认证	mTLS	高安全要求（金融、医疗）
权限模型	RBAC + 参数级别控制	权限相对固定的场景
权限模型	RAGAS	需要动态调整权限的复杂场景
工具控制	白名单 + 沙箱隔离	所有场景（必须）
数据边界	向量数据库级别 ACL	RAG 场景
审计日志	哈希链 + 不可变存储	所有场景（必须）

本文首发于 MosuoAI，AI Agent 开发者的深度指南。