AI Agent 正在从“回答问题”走向“代表用户执行任务”：读取邮件、查询数据库、调用 API，甚至推动业务流程继续运行。能力越强，权限边界就越重要。企业面对的已经不只是模型是否安全，还包括 Agent 能访问什么、能调用哪些工具、如何证明输入来源可信，以及哪些关键动作必须经过人工确认。
在 AI 基础设施规模化落地过程中，安全、治理和运维已经成为技术领导者最关注的挑战之一。与此同时，传统安全体系往往围绕固定身份、固定权限和相对稳定的请求设计，而 Agent 的权限和行为会随着任务上下文动态变化。
Agent 带来的新风险面
Agent 是企业系统中权限很高的“内部操作者”。它不只读取信息，还会根据模型推理结果采取行动，因此风险链条比普通聊天机器人更长。
典型风险包括：
- 多系统访问风险：一个 Agent 可能同时访问邮件、CRM、数据库和外部 API，单点配置错误会放大影响范围。
- 间接提示注入：攻击者把恶意指令写入邮件、网页、工单或文档。Agent 处理这些数据时，可能把数据中的内容误当成任务指令。
- 工具投毒：工具描述、返回结果或依赖组件被篡改，诱导 Agent 调用不该调用的能力。
- 动态权限失控：Agent 为完成任务临时申请权限，但如果权限没有及时收回，就可能形成长期过度授权。
- 来源不可验证：模型无法天然区分可信业务数据、用户输入和攻击者控制的内容。
因此，单纯“把系统锁得更紧”并不能解决问题。权限过少，Agent 无法完成工作；权限过多，组织又会承担不可接受的误操作和数据泄露风险。真正需要管理的是 Agent 的行动范围、行动依据和行动时机。
治理不是阻力，而是控制平面
更可行的方向，是把治理能力嵌入 AI 应用和基础设施，而不是在上线后依赖零散的外围检查。可以围绕三个层面建立统一控制。
安全默认配置
在开发阶段就加入输入来源标记、工具白名单、输出校验和敏感操作拦截。例如，来自外部网页或邮件的文本应被视为“不可信数据”，不能直接升级为系统指令；数据库查询工具应限制只读范围和返回字段；写入、删除、付款等动作应拥有更高的审批等级。
Agent 身份与权限治理
每个 Agent 都应拥有可审计的独立身份，而不是复用用户的长期高权限令牌。权限可以根据任务授予，并设置资源范围、有效时间、调用次数和用途限制。所有工具调用都应记录调用者、输入来源、参数、结果和最终动作。
人在回路中
对删除数据、发送外部邮件、修改生产配置、支付费用等高影响动作，可以要求 Agent 暂停并请求人工批准。人工审批不必覆盖每个步骤，而应集中在不可逆、影响范围大或涉及敏感数据的节点。
一个可改造的最小策略示例
下面是一份简化的 YAML 策略示例。它不是某个具体平台的内置格式，假设你的 Agent 网关能够读取类似的权限策略，并在调用工具前执行检查。实际接入时，需要把工具名称、资源路径和审批接口替换成组织内部的实现。
agent: support-agent
identity:
type: workload
name: support-agent-prod
allowed_tools:
- name: search_customer
permissions: [read]
resources:
- "crm/customers/*"
max_calls_per_task: 20
- name: create_draft_reply
permissions: [write]
resources:
- "support/drafts/*"
approval: none
- name: send_email
permissions: [external_write]
resources:
- "mail/outbound/*"
approval: human
require_reason: true
input_trust:
external_email: untrusted
internal_crm: trusted
user_instruction: user_controlled
rules:
- name: block_untrusted_instructions
when:
data_source: untrusted
requests_tool: [send_email, delete_record]
action: require_human_approval
- name: expire_task_permissions
when:
task_status: completed
action: revoke_all_task_grants
logging:
record:
- agent_identity
- data_sources
- tool_name
- tool_arguments
- approval_decision
- final_result
这份策略表达了几个关键原则：搜索客户信息可以是只读操作；生成邮件草稿可以自动完成；真正发送邮件必须经过人工批准；来自外部邮件的内容不能直接驱动高风险工具；任务结束后，临时权限必须回收。
如果需要在应用层补充一道检查，可以采用类似的伪代码逻辑：
def authorize_tool_call(agent, tool, data_sources, task):
if tool in {"delete_record", "send_email", "change_production_config"}:
return "human_approval_required"
if "untrusted" in data_sources and tool in {"send_email", "delete_record"}:
return "human_approval_required"
if task.is_expired or not task.has_scope(tool.resource):
return "deny"
return "allow"
这里的关键不是把所有调用都拒绝，而是把风险与动作绑定：只读查询、草稿生成和不可逆写操作使用不同的控制等级。
从防止入侵转向验证来源
Agent 安全不能只看网络边界和模型本身，还要验证数据和指令的来源。防御团队需要知道：
- 这段文本来自用户、内部系统，还是外部内容？
- Agent 为什么选择这个工具？
- 工具参数是否由可信数据生成？
- 结果是否经过格式、权限和业务规则校验？
- 谁批准了最终动作？
因此，审计日志不能只记录“模型生成了什么文本”，还应记录完整的决策上下文和工具调用链。对于敏感工作负载，建议将来源标签沿着工作流传递，直到最终动作完成。这样才能在发生异常时定位是身份配置、数据污染、提示注入还是业务规则缺失。
落地时的检查清单
可以从一条具体 Agent 工作流开始，逐项确认：
- 为每个 Agent 分配独立身份，避免共享长期管理员令牌。
- 使用工具白名单，并为每个工具限制资源范围和调用次数。
- 将外部邮件、网页和用户上传文档默认标记为不可信输入。
- 为发送、删除、付款和生产变更设置人工审批。
- 让临时权限绑定任务生命周期，任务结束后自动撤销。
- 记录数据来源、工具参数、审批结果和最终动作。
- 定期检查 Agent 是否拥有未被使用的权限，以及工具返回内容是否可能注入指令。
- 将安全策略纳入开发、测试和发布流程，而不是只在生产环境补救。
Agent 治理的目标不是让自动化失去作用，而是让组织清楚地知道 Agent 可以做什么、为什么这样做，以及什么时候必须停下来询问人类。把安全策略、身份管理、来源验证和人工审批放进统一控制平面，企业才能在保护敏感工作负载的同时，持续扩大 Agent 的实际使用范围。