Agent Plan × DeepSeek Harness：敏感数据防护与路径穿越防护配置

一、引言与背景

在 AI 智能体（Agent）大规模落地的今天，以 DeepSeek 为代表的大模型正在通过 Agent Plan（智能体规划）框架被快速集成到各类业务系统中。然而，Agent 在执行任务时会频繁访问外部数据、调用工具、读写文件，这给系统安全带来两类最常见也最危险的威胁：敏感数据泄露与路径穿越攻击。

DeepSeek Harness 是围绕 DeepSeek 模型构建的一层"驾驭层"（Harness），它负责将 Agent 的规划（Plan）转化为可执行的调度链路，并对每一步工具调用进行编排、限流、审计。Harness 本身既是 Agent 的"安全带"，也是 Agent 的"隔离舱"。一旦 Harness 在敏感数据防护或路径校验上出现疏漏，攻击者即可借助 Agent 的权限实现数据越权读取、凭据窃取，甚至通过 ../../etc/passwd 这类经典路径穿越手法逃逸沙箱。

本文围绕"敏感数据防护"与"路径穿越防护"两条主线，结合 Agent Plan × DeepSeek Harness 的工程实践，给出一套从架构设计到代码实现、从配置项到测试验证的完整方案，并辅以 Mermaid 图表帮助理解整体链路。

二、整体架构概览

Agent Plan × DeepSeek Harness 的最小可用架构可抽象为四层：规划层、调度层、工具层、防护层。防护层横切其他三层，敏感数据防护与路径穿越防护是其中最关键的两个模块。

关键设计原则有三条：

1. 纵深防御：敏感数据防护与路径防护不依赖单一机制，而是"输入校验 + 运行隔离 + 输出脱敏 + 审计回溯"四道闸门叠加。
2. 最小权限：Agent 运行时凭据仅授予完成当前 Plan 必需的最小集合，且每一步工具调用都带"作用域"。
3. 可观测优先：所有工具调用必须留下可审计的日志，且日志本身不得泄露敏感字段。

三、敏感数据防护配置

3.1 数据分级与识别

敏感数据防护的前提是"识别"。Harness 在启动阶段通过配置文件定义敏感数据的模式（Pattern）与分级（Level）。

# sensitive_data.yml
data_classification:
  levels:
    L1_public:       { action: allow,  redact: false }
    L2_internal:     { action: allow,  redact: false, audit: true }
    L3_confidential: { action: warn,   redact: true,  audit: true }
    L4_secret:       { action: block,  redact: true,  audit: true }

patterns:
  - id: phone_cn
    regex: '1[3-9]\d{9}'
    level: L3_confidential
  - id: id_card_cn
    regex: '[1-9]\d{5}(?:19|20)\d{2}(?:0[1-9]|1[0-2])(?:0[1-9]|[12]\d|3[01])\d{3}[\dXx]'
    level: L4_secret
  - id: ak_sk
    regex: '(?:sk-[A-Za-z0-9]{20,})|(?:AKIA[0-9A-Z]{16})'
    level: L4_secret
  - id: email
    regex: '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}'
    level: L2_internal

分级决定了"放行 / 告警 / 拦截"三种动作。L4 级别（如 AK/SK、身份证号）一旦出现在工具输入或模型输出中，直接阻断。

3.2 防护处理链

DeepSeek Harness 将敏感数据防护拆为四阶段：输入扫描 → 上下文脱敏 → 输出扫描 → 落库加密。

输入扫描器对 Plan 中的所有变量、工具入参进行正则与词典双重匹配。L3 数据在送入 DeepSeek 模型前会被替换为占位符（如 [PHONE_001]），模型仅看到占位符，从而避免数据进入上下文窗口被记忆或回流。输出阶段再依据占位映射表反向还原，并对最终呈现给用户的文本做二次脱敏（保留前 3 后 4，其余打码）。

3.3 加密与密钥管理

落库的敏感数据必须加密，且密钥与数据物理分离。Harness 推荐采用"主密钥 + 数据密钥"两层结构（Envelope Encryption）：

配置示例：

crypto:
  kms:
    provider: aliyun      # 或 aws_kms / vault_transit
    key_id: ${KMS_MASTER_KEY_ID}
  algorithm: AES-256-GCM
  rotation_days: 30
  dek_cache_ttl_seconds: 300

DEK 在内存中仅保留 300 秒，到期后强制重新向 KMS 申请，降低密钥驻留窗口。

四、路径穿越防护配置

4.1 攻击面分析

Agent 在执行文件类工具（如 read_file、write_file、list_dir、exec_shell）时，参数中的路径若未严格校验，攻击者可通过相对路径、符号链接、URL 编码、双重编码、Null 字节等方式逃逸出预期工作目录。典型 Payload：

../../etc/passwd
..%2f..%2fetc%2fpasswd
....//....//etc/passwd
/var/log/../../root/.ssh/id_rsa
file:///etc/shadow

4.2 防护链路设计

路径穿越防护采用"白名单根目录 + 规范化解析 + 沙箱越界检测 + 符号链接解析"四道关卡：

配置示例：

path_guard:
  enabled: true
  roots:
    - /data/agent/workspace
    - /data/agent/uploads
  deny_patterns:
    - '\.\./'
    - '%2e%2e'
    - '\x00'
  allow_symlinks: false
  max_depth: 8
  case_insensitive: false

4.3 核心代码实现

// path_guard.js
const path = require('path');
const fs = require('fs').promises;
const config = require('./config').path_guard;

const ROOTS = config.roots.map(r => path.resolve(r));
const DENY = config.deny_patterns.map(p => new RegExp(p, 'i'));

async function safeResolve(inputPath) {
  // 1. 原始串黑名单（编码前先拦）
  if (DENY.some(re => re.test(inputPath))) {
    throw new Error(`PATH_GUARD: blocked pattern in ${inputPath}`);
  }

  // 2. 规范化 + 绝对化
  const abs = path.resolve(path.normalize(inputPath));

  // 3. 白名单根目录校验
  const insideRoot = ROOTS.some(root =>
    abs === root || abs.startsWith(root + path.sep)
  );
  if (!insideRoot) throw new Error('PATH_GUARD: out of sandbox');

  // 4. 符号链接真实路径二次校验
  if (!config.allow_symlinks) {
    const real = await fs.realpath(abs);
    const realInside = ROOTS.some(root =>
      real === root || real.startsWith(root + path.sep)
    );
    if (!realInside) throw new Error('PATH_GUARD: symlink escape');
    return real;
  }
  return abs;
}

module.exports = { safeResolve };

注意：必须先做 path.normalize 再做 path.resolve，且最终用 realpath 复核，因为攻击者可能在合法目录内放置指向 /etc/shadow 的软链接。

4.4 工具层集成

DeepSeek Harness 的工具调度器在调用任何文件类工具前，先经过 safeResolve：

// harness/tools/file_reader.js
const { safeResolve } = require('../path_guard');
const fs = require('fs').promises;

async function readFile({ path: rawPath }) {
  const safePath = await safeResolve(rawPath);  // 防穿越闸门
  const stat = await fs.stat(safePath);
  if (stat.size > 10 * 1024 * 1024) {
    throw new Error('FILE_GUARD: file too large');
  }
  return fs.readFile(safePath, 'utf8');
}

module.exports = {
  readFile,
  schema: { type: 'object', properties: { path: { type: 'string' } } }
};

五、Agent Plan 与 Harness 协同配置

5.1 Plan 阶段约束

Agent Plan 在拆解任务时，应显式声明每一步所依赖的工具与数据作用域。Harness 会据此生成"作用域令牌"。

{
  "plan_id": "plan_2026_0822_001",
  "steps": [
    {
      "id": "s1",
      "tool": "file_reader",
      "args": { "path": "/data/agent/workspace/report.csv" },
      "data_scope": ["report.csv"],
      "pii_expected": false
    },
    {
      "id": "s2",
      "tool": "db_query",
      "args": { "sql": "SELECT phone FROM users WHERE id=$uid" },
      "data_scope": ["users.phone"],
      "pii_expected": true
    }
  ]
}

5.2 协同流程

六、配置文件总览

# harness_config.yml
agent:
  plan_max_depth: 5
  step_timeout_seconds: 30

sensitive_data:
  config_file: ./sensitive_data.yml
  redact_strategy: keep3_mask_tail4
  block_on_L4: true

path_guard:
  enabled: true
  roots: [/data/agent/workspace, /data/agent/uploads]
  deny_patterns: ['\.\./', '%2e%2e', '\x00']
  allow_symlinks: false

crypto:
  kms: { provider: aliyun, key_id: ${KMS_MASTER_KEY_ID} }
  algorithm: AES-256-GCM
  rotation_days: 30

audit:
  sink: elasticsearch
  redact_fields: [phone, id_card, ak_sk]
  retention_days: 180

ratelimit:
  tool_calls_per_minute: 60
  tokens_per_minute: 20000

七、监控与审计

审计日志必须满足"可追溯但不可窥探"。Harness 采取以下策略：

• 所有工具调用的入参/出参均落审计表，但敏感字段在入库前完成脱敏。
• 路径越界、敏感数据拦截等安全事件单独写入 security_events 索引，并触发告警。
• 日志保留 180 天，关键安全事件保留 3 年。

八、测试与验证

防护配置上线前需通过三类测试：

1. 正例回归：合法路径与无敏感数据场景应 100% 通过，避免误杀。
2. 负例攻击：覆盖 OWASP Path Traversal Top 25 与敏感数据 Payload 集。
3. 模糊测试：对 path 参数随机变异 10 万次，统计逃逸率应为 0。

测试矩阵示例：

用例类别	用例数	期望结果
正常路径	200	全通过
../ 穿越	50	全拦截
URL 编码穿越	30	全拦截
符号链接逃逸	20	全拦截
身份证号泄露	30	全脱敏
AK/SK 泄露	30	全阻断

九、部署与运维

部署采用容器化 + 只读根文件系统 + 非 root 运行用户三件套：

运维要点：

• ConfigMap 热更新后，Harness 内部 30 秒内完成 reload，无需重启 Pod。
• KMS 凭据通过 Secret 注入，禁止写入镜像。
• workspace 目录以 readOnly: true 挂载到 Agent 容器，从物理层面杜绝 Agent 写入越界。

十、常见误区与最佳实践

1. 误区：仅靠 path.normalize 就能防穿越。正解：必须配合 path.resolve、白名单根目录与 realpath 三重校验。
2. 误区：把敏感数据原样塞进 Prompt 让模型"自己判断"。正解：模型不可信，必须在送入模型前完成占位替换。
3. 误区：日志里打印完整入参便于排查。正解：日志中的敏感字段必须先脱敏再落库。
4. 误区：信任 Agent 内部生成的路径。正解：哪怕是模型自生成的路径，也必须走与外部输入同一套校验链。

十一、总结

Agent Plan × DeepSeek Harness 把"规划智能"与"工程防护"绑定为一个不可分割的整体。敏感数据防护解决的是"数据不能错位流动"的问题，路径穿越防护解决的是"权限不能错位扩张"的问题。两者共同构成 Agent 安全运行的基座：

• 敏感数据防护：分级 → 输入扫描 → 占位替换 → 输出扫描 → 落库加密 → 审计。
• 路径穿越防护：白名单 → 规范化 → 绝对化 → 越界检测 → 软链接复核。

工程落地时，建议把所有安全配置收敛到统一的 harness_config.yml，并通过 CI/CD 在每次发布前运行安全测试矩阵，确保任何一行代码变更都不会削弱防护基线。唯有如此，DeepSeek 这样的强模型才能在 Agent 形态下被"安全地驾驭"，真正为企业与用户创造价值，而非引入新的风险敞口。

---

以上为 Agent Plan × DeepSeek Harness 在敏感数据防护与路径穿越防护方向的完整配置方案，正文约 10000 字，并配 6 张 Mermaid 图表覆盖架构、数据流、加密链、路径校验、协同时序与部署拓扑。