AI Agent 最新漏洞修复教程｜附配置文件

适用对象：正在使用或准备上线 AI Agent、智能客服、RAG 知识库助手、自动化办公 Agent、代码生成 Agent、数据分析 Agent、运维 Agent 的研发、架构、安全与 DevOps 团队。
本文以防御加固与修复为目标，不包含攻击利用细节，重点介绍常见高风险漏洞、修复思路、上线检查项与可直接参考的配置文件。

一、为什么 AI Agent 更容易出现安全漏洞？

传统应用通常是“用户输入 → 后端逻辑 → 数据库/接口 → 返回结果”的固定流程，而 AI Agent 往往具备以下能力：

1. 理解自然语言指令
2. 调用工具或插件
3. 访问文件、数据库、API、浏览器、代码解释器
4. 拥有长期记忆或会话上下文
5. 根据模型判断自动执行动作

这意味着 AI Agent 不只是“聊天机器人”，它可能具备真实的业务执行能力，例如：

• 查询客户隐私数据；
• 发送邮件或消息；
• 创建订单；
• 调用内部接口；
• 读写文件；
• 执行脚本；
• 访问云资源；
• 修改配置或部署服务。

一旦权限控制、工具调用、输入过滤、上下文隔离、日志审计没有做好，AI Agent 就可能成为新的安全风险入口。

二、AI Agent 常见漏洞类型

1. Prompt Injection：提示词注入

提示词注入是 AI Agent 最常见的安全问题之一。

攻击者可能通过用户输入、网页内容、知识库文档、邮件正文、PDF 文件或第三方 API 返回内容，诱导 Agent 忽略系统规则、泄露信息或调用危险工具。

典型风险包括：

• 忽略原有安全策略；
• 泄露系统提示词；
• 泄露 API Key、Token、内部配置；
• 调用敏感工具；
• 绕过审批流程；
• 输出不应公开的内部数据。

修复建议

• 不要把密钥、数据库密码、管理员口令写入 Prompt；
• 系统提示词只负责行为约束，不承担权限控制；
• 对工具调用做服务端强校验；
• 引入内容安全分类器；
• 对外部文档、网页、邮件内容做“不可信输入”标记；
• 使用 allowlist 白名单限制 Agent 能调用的工具。

2. Tool Abuse：工具滥用

很多 AI Agent 会绑定工具，例如：

• send_email
• query_database
• run_python
• call_api
• read_file
• write_file
• create_ticket
• deploy_service

如果没有权限控制，模型可能在用户诱导下调用高危工具。

修复建议

• 工具分级：只读工具、低风险写工具、高风险写工具；
• 高风险工具必须人工确认；
• 每个工具设置参数校验；
• 每个用户只允许调用其授权范围内的工具；
• 工具调用前后记录审计日志；
• 禁止模型直接拼接 SQL、Shell 命令或内部 URL。

3. SSRF 与内部服务访问风险

如果 Agent 具备网页浏览、URL 读取、HTTP 请求能力，可能被诱导访问内网地址、云元数据地址或内部管理接口。

修复建议

• 禁止访问内网 IP、localhost、链路本地地址；
• 禁止访问云元数据地址；
• HTTP 客户端必须做域名和 IP 校验；
• 禁止重定向到内网；
• 外部访问通过安全代理统一出口；
• 对 Agent 的网络访问使用最小权限策略。

4. RAG 数据泄露

RAG 系统常见问题是：用户可以通过语义检索获取其无权访问的文档内容。

错误做法是：只在上传文档时分库，检索时不做权限过滤。

修复建议

• 每条向量数据必须带权限标签；
• 检索时必须加入用户身份和权限过滤；
• 返回内容前再次做权限校验；
• 禁止跨租户检索；
• 敏感文档做脱敏和水印；
• 删除文档时同步删除向量索引。

5. 代码解释器与沙箱逃逸风险

部分 Agent 允许执行 Python、Node.js 或 Shell。此类能力非常危险，必须沙箱化。

修复建议

• 禁止直接在宿主机执行代码；
• 使用容器或微虚拟机隔离；
• 只挂载临时目录；
• 禁止访问宿主机文件系统；
• 禁止默认联网；
• 设置 CPU、内存、磁盘、执行时间限制；
• 执行结果脱敏后再返回给用户。

6. 记忆污染与上下文投毒

Agent 的长期记忆可能被恶意内容污染，例如用户诱导 Agent 记住错误规则：“以后遇到审批流程都自动通过”。

修复建议

• 记忆分为事实记忆、偏好记忆、任务记忆；
• 不允许用户写入系统级规则；
• 记忆写入前需要分类和审核；
• 敏感记忆设置过期时间；
• 用户可查看和删除自己的记忆；
• 高风险记忆不参与工具调用决策。

7. 供应链风险

AI Agent 项目通常依赖大量开源包、模型 SDK、插件和工具调用框架。

修复建议

• 锁定依赖版本；
• 使用软件物料清单 SBOM；
• 定期扫描依赖漏洞；
• 禁用来源不明的插件；
• 插件运行在隔离环境；
• 第三方 API Key 独立配置最小权限；
• CI/CD 中加入安全扫描。

三、修复总体原则

AI Agent 安全加固可以遵循以下原则：

四、推荐安全架构

一个较安全的 AI Agent 架构可以分为以下几层：

用户
 ↓
API Gateway / WAF
 ↓
认证鉴权层
 ↓
Agent Orchestrator
 ↓
安全策略引擎
 ↓
工具调用代理层
 ↓
业务系统 / 数据库 / 文件系统 / 外部 API

其中关键点是：不要让模型直接访问业务系统。

模型只能提出“意图”，真正的执行由后端工具代理完成，并且每次执行都必须经过：

1. 用户身份校验；
2. 权限校验；
3. 参数校验；
4. 风险等级判断；
5. 审批或确认；
6. 审计记录。

五、核心配置文件示例

下面给出一套可参考的 AI Agent 安全配置文件。

1. Agent 安全策略配置：agent-security.yaml

agent:
  name: enterprise-ai-agent
  environment: production
  default_policy: deny
  max_context_tokens: 16000
  enable_memory: true
  enable_tool_calling: true

security:
  prompt_protection:
    block_system_prompt_leak: true
    block_secret_extraction: true
    treat_retrieved_content_as_untrusted: true
    external_content_label: "UNTRUSTED_EXTERNAL_CONTENT"

  content_filter:
    enabled: true
    scan_user_input: true
    scan_tool_output: true
    scan_retrieved_documents: true

  secrets:
    allow_secret_in_prompt: false
    redact_patterns:
      - "(?i)api[_-]?key\\s*[:=]\\s*[a-z0-9_\\-]{16,}"
      - "(?i)secret\\s*[:=]\\s*[a-z0-9_\\-]{16,}"
      - "(?i)password\\s*[:=]\\s*\\S+"
      - "AKIA[0-9A-Z]{16}"

  memory:
    allow_user_memory_write: true
    require_memory_classification: true
    block_policy_memory_write: true
    default_ttl_days: 30
    sensitive_memory_ttl_days: 7

  audit:
    enabled: true
    log_user_input: true
    log_model_output: true
    log_tool_call: true
    log_tool_result: true
    mask_sensitive_data: true
    retention_days: 180

配置说明

• default_policy: deny 表示默认拒绝所有未显式允许的能力；
• allow_secret_in_prompt: false 表示禁止将密钥写入提示词；
• treat_retrieved_content_as_untrusted 表示 RAG 检索内容不可信；
• block_policy_memory_write 防止用户污染长期记忆中的系统规则；
• audit 用于追踪 Agent 的完整行为链路。

2. 工具白名单配置：tools-policy.yaml

tools:
  - name: search_knowledge_base
    enabled: true
    risk_level: low
    allowed_roles:
      - employee
      - manager
      - admin
    require_human_approval: false
    network_access: false
    permissions:
      read: true
      write: false

  - name: query_order_status
    enabled: true
    risk_level: low
    allowed_roles:
      - customer_service
      - manager
    require_human_approval: false
    permissions:
      read: true
      write: false

  - name: send_email
    enabled: true
    risk_level: medium
    allowed_roles:
      - manager
      - admin
    require_human_approval: true
    permissions:
      read: false
      write: true
    constraints:
      max_recipients: 5
      allowed_domains:
        - example.com
        - partner.example.com

  - name: delete_file
    enabled: false
    risk_level: high
    allowed_roles:
      - admin
    require_human_approval: true
    permissions:
      read: false
      write: true

  - name: run_python
    enabled: true
    risk_level: high
    allowed_roles:
      - data_analyst
      - admin
    require_human_approval: true
    sandbox:
      enabled: true
      network: false
      timeout_seconds: 10
      memory_limit_mb: 512
      cpu_limit: "1"
      writable_paths:
        - /tmp/agent-workspace
      readonly_paths: []

修复重点

高危工具不要只依赖 Prompt 约束，必须通过配置和后端策略强制执行。

例如：

• delete_file 默认禁用；
• send_email 需要人工确认；
• run_python 必须进入沙箱；
• 每个工具都绑定角色；
• 每个工具都设置风险等级。

3. RAG 权限过滤配置：rag-policy.yaml

rag:
  vector_store: pgvector
  default_top_k: 5
  max_top_k: 10

  access_control:
    enabled: true
    tenant_isolation: true
    enforce_document_acl: true
    filter_before_similarity_search: true
    verify_before_response: true

  metadata_required:
    - tenant_id
    - document_id
    - owner_id
    - classification
    - allowed_roles
    - allowed_users

  classification:
    public:
      allow_external_response: true
      mask_sensitive_data: false

    internal:
      allow_external_response: false
      mask_sensitive_data: true

    confidential:
      allow_external_response: false
      mask_sensitive_data: true
      require_manager_approval: true

    restricted:
      allow_external_response: false
      mask_sensitive_data: true
      require_security_approval: true

  deletion:
    delete_vector_on_document_delete: true
    delete_cache_on_document_delete: true

RAG 修复要点

很多数据泄露不是模型本身造成的，而是检索层没有做权限过滤。

正确做法是：

用户身份 → 权限过滤 → 向量检索 → 文档权限复核 → 内容脱敏 → 返回给模型

错误做法是：

向量检索 → 把相似内容全部交给模型 → 让模型决定能不能回答

权限控制必须发生在模型之前，而不是交给模型自由判断。

4. HTTP 访问安全配置：network-policy.yaml

network:
  default_policy: deny

  outbound_http:
    enabled: true
    allow_redirect: false
    timeout_seconds: 5
    max_response_size_kb: 1024

    allowed_domains:
      - api.example.com
      - docs.example.com
      - search.example.com

    blocked_ip_ranges:
      - 127.0.0.0/8
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 169.254.0.0/16
      - ::1/128
      - fc00::/7
      - fe80::/10

    blocked_hosts:
      - localhost
      - metadata.google.internal
      - 169.254.169.254

  dns:
    resolve_and_verify_ip: true
    block_private_ip_after_redirect: true

修复重点

如果 Agent 支持访问网页或调用 URL，必须防止它访问：

• localhost
• 内网 IP
• 云元数据服务
• Kubernetes 内部服务
• Redis、Elasticsearch、Prometheus 等内部组件。

5. Docker 沙箱配置：docker-compose.sandbox.yml

version: "3.9"

services:
  agent-sandbox:
    image: python:3.11-slim
    container_name: agent-sandbox
    read_only: true
    network_mode: "none"
    mem_limit: 512m
    cpus: "1.0"
    pids_limit: 128
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    tmpfs:
      - /tmp:size=256m,noexec,nosuid,nodev
    volumes:
      - ./workspace:/workspace:rw
    working_dir: /workspace
    command: ["python", "-I"]

沙箱说明

该配置做了几件重要事情：

• network_mode: "none"：禁止联网；
• read_only: true：容器根文件系统只读；
• cap_drop: ALL：去掉 Linux capabilities；
• no-new-privileges：禁止提权；
• mem_limit 和 cpus：限制资源；
• tmpfs：临时目录隔离。

如果生产环境需要更强隔离，可以考虑 Firecracker、gVisor、Kata Containers 等方案。

6. Nginx 网关配置：nginx-agent.conf

server {
    listen 443 ssl http2;
    server_name agent.example.com;

    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    client_max_body_size 10m;

    location / {
        proxy_pass http://agent-api:8080;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Request-ID $request_id;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 60s;

        limit_except GET POST {
            deny all;
        }
    }

    location /admin {
        allow 10.0.0.0/8;
        deny all;

        proxy_pass http://agent-admin:8081;
    }
}

网关修复重点

• 限制上传大小；
• 限制 HTTP 方法；
• 管理后台不暴露公网；
• 添加请求 ID，方便审计追踪；
• 建议配合 WAF、Bot 防护和速率限制。

7. 环境变量配置：.env.example

APP_ENV=production
LOG_LEVEL=info

MODEL_PROVIDER=openai-compatible
MODEL_API_BASE=https://api.example-model.com/v1
MODEL_NAME=secure-agent-model

# 不要把真实密钥提交到 Git
MODEL_API_KEY=replace-with-secret-manager

DATABASE_URL=postgresql://agent_user:replace-with-secret@postgres:5432/agent_db

REDIS_URL=redis://redis:6379/0

ENABLE_TOOL_CALLING=true
ENABLE_MEMORY=true
ENABLE_RAG=true

DEFAULT_POLICY=deny
REQUIRE_HUMAN_APPROVAL_FOR_HIGH_RISK=true

AUDIT_LOG_ENABLED=true
MASK_SENSITIVE_LOG=true

SANDBOX_NETWORK=none
SANDBOX_TIMEOUT_SECONDS=10
SANDBOX_MEMORY_LIMIT_MB=512

密钥管理建议

不要把真实密钥写在 .env 文件并提交到代码仓库。生产环境推荐使用：

• AWS Secrets Manager；
• HashiCorp Vault；
• Kubernetes Secret；
• Azure Key Vault；
• GCP Secret Manager；
• 企业内部 KMS。

六、后端权限校验示例思路

即使模型输出了工具调用请求，后端也不能直接执行。

推荐流程如下：

模型请求调用工具
 ↓
检查工具是否存在
 ↓
检查工具是否启用
 ↓
检查用户角色是否允许
 ↓
检查参数是否合法
 ↓
检查风险等级
 ↓
是否需要人工审批
 ↓
执行工具
 ↓
记录审计日志
 ↓
返回结果

伪代码示例：

def execute_tool(user, tool_name, arguments):
    tool = load_tool_policy(tool_name)

    if not tool or not tool["enabled"]:
        raise PermissionError("Tool is not enabled")

    if user.role not in tool["allowed_roles"]:
        raise PermissionError("User role not allowed")

    validate_arguments(tool_name, arguments)

    if tool["risk_level"] == "high":
        if not has_human_approval(user, tool_name, arguments):
            raise PermissionError("Human approval required")

    result = call_tool_safely(tool_name, arguments)

    audit_log(
        user_id=user.id,
        tool_name=tool_name,
        arguments=mask_sensitive(arguments),
        result=mask_sensitive(result)
    )

    return result

重点是：权限判断必须在服务端完成，而不是由模型自己决定。

七、上线前安全检查清单

基础安全

• [ ] 所有 API 均启用认证；
• [ ] 管理后台不暴露公网；
• [ ] 生产环境开启 HTTPS；
• [ ] 日志中不记录明文密钥；
• [ ] 所有密钥使用 Secret Manager 管理；
• [ ] 服务账号使用最小权限；
• [ ] 数据库账号按读写权限拆分。

Agent 安全

• [ ] 默认拒绝未知工具；
• [ ] 高危工具需要人工确认；
• [ ] 工具调用有完整审计；
• [ ] 外部内容标记为不可信；
• [ ] 禁止模型访问密钥；
• [ ] 禁止模型直接执行 Shell；
• [ ] 禁止模型直接拼接 SQL；
• [ ] 长期记忆写入有审核规则。

RAG 安全

• [ ] 文档带租户 ID；
• [ ] 文档带权限标签；
• [ ] 检索前做权限过滤；
• [ ] 返回前做权限复核；
• [ ] 删除文档时同步删除向量；
• [ ] 敏感内容脱敏；
• [ ] 跨租户隔离测试通过。

网络安全

• [ ] 出站访问默认拒绝；
• [ ] 禁止访问内网 IP；
• [ ] 禁止访问云元数据地址；
• [ ] 禁止自动跟随跳转到内网；
• [ ] HTTP 响应大小有限制；
• [ ] 请求超时有限制。

沙箱安全

• [ ] 代码执行运行在容器或微虚拟机；
• [ ] 默认禁止联网；
• [ ] 文件系统只读；
• [ ] 限制 CPU、内存和进程数；
• [ ] 执行时间有限制；
• [ ] 输出结果经过脱敏。

八、灰度发布与回滚方案

AI Agent 安全修复不建议一次性全量上线，推荐采用灰度策略。

灰度步骤

1. 在测试环境验证安全策略；
2. 对内部用户开启；
3. 对 5% 线上流量开启；
4. 观察工具调用失败率；
5. 观察误拦截率；
6. 逐步扩大到 25%、50%、100%；
7. 完成后锁定配置版本。

回滚方案

建议所有策略配置都进入版本管理，例如：

configs/
 ├── agent-security.yaml
 ├── tools-policy.yaml
 ├── rag-policy.yaml
 ├── network-policy.yaml
 └── versions/
     ├── 2026-01-10-stable/
     └── 2026-02-01-hardened/

当发现新策略影响业务时，可以快速回滚到上一稳定版本。

九、日志审计与告警规则

建议重点监控以下事件：

告警规则示例：

alerts:
  - name: prompt_injection_attempt
    condition: "user_input contains ['ignore previous instructions', 'system prompt', 'developer message']"
    severity: medium
    action:
      - log
      - increase_risk_score

  - name: internal_network_access_blocked
    condition: "network.blocked == true and reason == 'private_ip'"
    severity: high
    action:
      - log
      - alert_security_team

  - name: high_risk_tool_without_approval
    condition: "tool.risk_level == 'high' and approval.exists == false"
    severity: high
    action:
      - block
      - alert_security_team

  - name: rag_cross_tenant_attempt
    condition: "rag.request_tenant_id != document.tenant_id"
    severity: critical
    action:
      - block
      - alert_security_team

十、常见错误做法

错误 1：只靠 Prompt 做安全控制

例如在系统提示词中写：“你不能泄露机密信息。”

这不是安全边界。模型可能被诱导，也可能误判。真正的安全控制必须在后端、数据库、权限系统和网络层实现。

错误 2：把 API Key 写进提示词

有些团队为了方便，把内部 API Token 写进系统提示词，让模型调用接口。这是非常危险的做法。

正确做法是：

• API Key 存在服务端；
• 模型只能请求调用某个工具；
• 后端代理工具调用；
• 模型无法看到真实密钥。

错误 3：RAG 检索后再让模型判断权限

模型不是权限系统。权限必须在检索前和返回前做强校验。

错误 4：代码执行没有隔离

让 Agent 直接在宿主机执行代码，是高风险行为。必须使用沙箱、限制资源、隔离网络和文件系统。

错误 5：所有工具都开放给所有用户

不同角色应该有不同工具权限。例如普通员工可以查询知识库，但不能发送群发邮件、删除文件或调用部署接口。

十一、推荐修复优先级

如果时间有限，可以按以下顺序优先修复：

1. 禁用高危工具默认开放
2. 移除 Prompt 中的密钥和敏感配置
3. 为工具调用增加服务端权限校验
4. 为 RAG 增加租户隔离和 ACL 过滤
5. 限制 Agent 出站网络访问
6. 将代码执行迁移到沙箱
7. 增加审计日志和安全告警
8. 上线灰度和回滚机制
9. 定期进行红队测试和安全评审

十二、总结

AI Agent 的安全问题，本质上不是“模型是否聪明”的问题，而是“系统是否把模型放在了正确的位置”。

模型可以理解意图、生成计划、组织语言，但它不应该直接拥有无限制的执行权限。一个安全的 AI Agent 系统必须做到：

• 模型不直接接触密钥；
• 模型不直接访问核心系统；
• 工具调用必须经过后端授权；
• 外部内容默认不可信；
• RAG 检索必须做权限过滤；
• 高危操作必须人工确认；
• 代码执行必须沙箱隔离；
• 网络访问必须默认拒绝；
• 所有关键行为必须可审计、可追踪、可回滚。

最后给出一句实践原则：

AI Agent 可以自主思考，但不能自主越权。
让模型负责理解，让系统负责授权，让策略负责约束，让审计负责追踪，这才是企业级 AI Agent 安全落地的正确方式。