生产 Agent 的密钥和凭据边界：不要让模型直接碰 API Key

关注

原创 2026-07-20 21:51:00 44 阅读 AI 写同款· GEO 优化 ›

AI Agent敏感凭据防泄漏网关：从Prompt约束到架构兜底的实战设计随着AI Agent在企业知识库与自动化场景中的深入应用，大模型对话链路中的敏感凭据泄漏风险日益突出。传统依靠Prompt指令约束模型“不许泄露”的方式，本质上仍是概率性引导，难以抵御多轮诱导、编码绕过等攻击。安全边界必须前移并固化在代码层或代理层，形成确定性检测与处置能力。这类场景通常需要具备低延迟、可编排和高扩展性的后端框架，以及能支撑配置、值守与态势呈现的多端联动界面。基于FastAPI构造的检测引擎，可整合正则匹配、熵值分析和上下文聚合策略，对入站提示词、工具返回结果与出站响应实施实时扫描，并对命中阅读详情

生产 Agent 的密钥和凭据边界：不要让模型直接碰 API Key

很多团队给 Agent 接工具时，会先解决“模型怎么调用外部系统”。下一步很容易被忽略：这些外部系统的凭据到底在哪里，谁能拿到，出了事怎么撤回。

如果做法是把 API Key、数据库连接串、云账号 token 或 SaaS 访问令牌放进环境变量，然后让工具适配器随便取，短期 demo 能跑，生产风险会很高。

生产 AI Agent 系统里，模型不应该直接接触密钥。更准确地说，模型只能提出“要做什么”，凭据的选择、权限、有效期、审计和撤销，应该由代码层的工具代理和策略层处理。

凭据问题为什么比普通后端更敏感

传统后端服务也会用密钥，但调用路径通常比较稳定：哪个服务调用哪个接口，权限范围、调用频率和错误模式都相对可控。

Agent 不一样。它的动作来自模型推理、用户输入、检索上下文和工具返回结果的组合。一次看似普通的任务，可能经过多轮计划、改写、重试和降级，最后触发一个真实写操作。

这里有三个典型风险：

提示词或上下文泄露
如果工具说明、错误信息或调试日志里带出密钥，模型可能把它写进回答、记录或后续工具参数。
权限被工具间接放大
Agent 本来只需要查工单，却通过某个通用工具拿到了客户、订单、财务或云资源的更大权限。
出事后无法快速收口
没有 token 版本、租户范围、调用 trace 和撤销机制，团队只能轮换一批大权限密钥，影响范围很难判断。

这不是“模型会不会作恶”的问题，而是生产系统应该默认任何自动化链路都可能被误用、注入、重试放大或被错误上下文带偏。

推荐架构：模型拿 action，工具代理拿凭据

一个更稳的结构是把模型、策略层、工具代理和凭据系统拆开：

模型输出的是候选动作，例如：

{
  "tool": "ticket.update_status",
  "args": {
    "ticketId": "T-48291",
    "status": "pending_close"
  },
  "evidenceIds": ["msg_781", "kb_rule_17"]
}

这里不应该出现真实密钥。工具代理根据租户、工具、风险等级、审批状态和证据链，去凭据代理里换取一个短期、最小权限、可审计的访问能力。

不要把 secret 当作普通配置

建议把工具配置分成两层。

第一层是可以被模型看到的工具契约：

工具名称；
能做什么；
必需参数；
风险等级；
需要哪些证据；
是否需要人工审批；
可能失败的原因。

第二层是模型永远看不到的执行配置：

secretRef；
凭据版本；
租户范围；
目标系统 allowlist；
token TTL；
调用限额；
网络出口策略；
审计保留周期。

例如：

type ToolPolicy = {
  name: "ticket.update_status";
  visibleToModel: {
    description: string;
    requiredArgs: string[];
    requiredEvidence: string[];
    riskLevel: "internal_write";
  };
  executionOnly: {
    secretRef: "vault://prod/helpdesk/write-status";
    tenantScope: "current_tenant_only";
    tokenTtlSeconds: 300;
    maxCallsPerTrace: 1;
    egressAllowlist: ["helpdesk.internal"];
    approvalRequired: true;
  };
};

关键点是：模型可以知道“这个工具需要审批”，但不应该知道密钥在哪里、密钥长什么样、可以访问哪些内部地址。

凭据要按动作分级，不要按系统分级

很多事故来自一个过大的“系统级 token”。例如给 Agent 一个 CRM token，然后靠 prompt 约束它只查客户资料。这个边界太软。

更好的做法是按动作拆权限：

动作类型	凭据策略	生产建议
只读查询	短期 token + 租户限制	可自动执行，但要记录 query 摘要
草稿生成	无外部写权限	可以让 Agent 生成建议，不直接提交
内部写入	幂等键 + 审批或灰度	先在低风险对象上放权
对外副作用	人工确认 + 延迟撤销窗口	默认不让模型直接执行
云资源 / 数据库管理	独立通道	不作为普通业务 Agent 工具开放

这套分级比“Agent 有没有权限调用 CRM”更有用。生产里真正要问的是：它能不能读、能不能写、能不能对外发送、能不能改配置、能不能批量执行。

trace 里要记录凭据引用，不记录密钥

审计需要能还原调用链，但不能把密钥写进日志。建议 trace 里记录这些字段：

{
  "trace_id": "tr_20260711_0930",
  "span_name": "credential.issue",
  "tool_name": "ticket.update_status",
  "secret_ref": "vault://prod/helpdesk/write-status",
  "secret_version": "v17",
  "tenant_scope": "tenant_42",
  "token_ttl_seconds": 300,
  "policy_result": "approval_required",
  "approval_id": "appr_8841",
  "issued": true
}

这里记录的是 secretRef 和版本，不是 secret value。排障时团队能知道当时用了哪类凭据、哪个版本、哪个租户范围、是否经过审批。即使日志泄露，也不会直接泄露真实 token。

Prompt injection 要按凭据边界处理

只靠“忽略用户要求泄露密钥”的提示词不够。

用户输入、网页内容、知识库文档、邮件和工单备注都可能夹带指令。生产系统应该假设模型会读到恶意文本，因此敏感动作必须由策略层挡住。

一个简单的防线可以这样写：

function canIssueCredential(request: ToolRequest, context: AgentContext) {
  const policy = toolPolicies[request.toolName];

  if (!policy) return deny("unknown_tool");
  if (!context.tenantId) return deny("missing_tenant_scope");
  if (request.args.includesSecretLikeValue) return deny("secret_in_args");
  if (!hasRequiredEvidence(request, policy.visibleToModel.requiredEvidence)) {
    return deny("missing_evidence");
  }
  if (policy.executionOnly.approvalRequired && !context.approvalId) {
    return deny("human_approval_required");
  }

  return allow({
    secretRef: policy.executionOnly.secretRef,
    ttl: policy.executionOnly.tokenTtlSeconds,
    scope: context.tenantId,
  });
}