AI Agent 不只是生成文本，它还可能读取内部数据、调用 API、修改配置，甚至代表用户执行操作。随着企业开始把 Agent 放进真实业务流程，核心问题也从“模型能不能完成任务”变成了“它在什么边界内可以行动”。
Docker 汇集企业安全负责人讨论这一问题时，结论指向一个实际矛盾：企业需要治理 Agent，但治理不能变成开发者每次调用模型都要填写审批表。有效的方案应当把安全规则变成可自动执行的护栏，让开发速度和风险控制同时具备可操作性。
Agent 的风险来自“行动”，不只是回答
传统聊天机器人主要输出文本，风险通常集中在内容准确性、隐私泄露和提示注入。Agent 则多了一层行动能力：它可以选择工具、传递参数、访问资源，并根据中间结果继续执行。
因此，不能只在系统提示词中写一句“请谨慎操作”。提示词可以表达意图，却不能替代权限系统、参数校验和审计日志。可以把 Agent 的一次执行拆成几个需要控制的边界：
- 身份边界：当前 Agent 代表谁，使用什么凭证。
- 工具边界：它可以调用哪些函数或 API。
- 数据边界：它能读取哪些租户、项目和文件。
- 操作边界：哪些动作可以自动执行，哪些必须人工确认。
- 资源边界：调用次数、运行时间、网络访问和成本上限。
- 追踪边界：每次决策、工具调用和结果是否可审计。
这些边界应该由运行时强制执行，而不是寄希望于模型“理解规则”。
把安全策略放在工具调用之前
一个实用的设计是：模型只负责提出工具调用请求，策略层负责决定请求是否允许。工具函数本身也要再次验证权限，形成分层控制。这样即使模型被提示注入影响，或者生成了错误参数，也不会直接获得超出授权范围的能力。
下面是一个可以直接运行和改造的 Python 最小示例。它用策略函数限制 Agent 的工具、环境和金额，并对高风险操作要求人工批准。示例中的 Agent 决策部分用固定数据模拟，接入实际模型时，可以把 proposed_action 替换成模型返回的结构化工具调用。
运行前只需要 Python 3.10 或更高版本：
from dataclasses import dataclass
from typing import Any
@dataclass
class AgentRequest:
user_id: str
tool: str
args: dict[str, Any]
environment: str = "production"
ALLOWED_TOOLS = {"read_ticket", "create_draft"}
HIGH_RISK_TOOLS = {"send_email", "delete_record", "deploy"}
def authorize(request: AgentRequest) -> tuple[bool, str]:
if request.tool in HIGH_RISK_TOOLS:
return False, "需要人工审批的高风险操作"
if request.tool not in ALLOWED_TOOLS:
return False, f"工具未授权: {request.tool}"
if request.environment == "production" and request.tool == "create_draft":
title = str(request.args.get("title", ""))
if len(title) > 120:
return False, "标题超过 120 个字符"
return True, "允许执行"
def execute(request: AgentRequest) -> None:
allowed, reason = authorize(request)
print({
"user_id": request.user_id,
"tool": request.tool,
"args": request.args,
"allowed": allowed,
"reason": reason,
})
if not allowed:
return
# 实际项目中，这里还应使用独立服务凭证和服务端权限校验。
print(f"executing {request.tool}")
if __name__ == "__main__":
requests = [
AgentRequest("u-123", "read_ticket", {"ticket_id": "INC-42"}),
AgentRequest("u-123", "delete_record", {"record_id": "customer-7"}),
AgentRequest("u-123", "create_draft", {"title": "Weekly report"}),
]
for request in requests:
execute(request)
这段代码并不能替代完整的企业权限系统，但它说明了关键位置：策略检查发生在工具实际执行之前，而且策略结果可以记录下来。生产环境还应加入租户隔离、资源级授权、参数 schema 校验、速率限制、超时、网络出口控制和不可篡改的审计存储。
让治理成为开发者工作流的一部分
治理是否会拖慢开发，取决于规则是否集中、可复用、可测试。每个团队各自实现一套 Agent 安全逻辑，短期看灵活，长期会产生明显差异：同一个工具在不同服务中可能有不同的权限含义，审计字段也难以统一。
可以把常见护栏沉淀为平台能力：
- 以工具注册表统一声明工具名称、参数 schema、数据范围和风险等级。
- 以服务身份而不是模型生成的字符串决定 API 凭证。
- 以策略即代码管理允许的工具、环境和资源范围。
- 在 CI 中使用提示注入、越权访问和恶意参数样例测试 Agent。
- 为每次模型决策和工具调用生成关联 ID，便于定位完整链路。
- 对高影响动作使用人工确认或双人审批，而不是完全自动化。
例如，可以把一条“生产环境禁止删除数据”的规则写成配置，并在所有 Agent 服务中复用。下面的 YAML 只是一个可改造的策略格式示例，不代表某个具体平台的标准：
agent_policy:
name: support-agent
default_action: deny
allowed_tools:
- name: read_ticket
environments: [staging, production]
data_scopes: [tickets:read]
- name: create_draft
environments: [staging, production]
data_scopes: [tickets:read, drafts:write]
approvals:
- tool: send_email
required: true
approvers: [support-manager]
network:
egress: allowlist
hosts:
- api.internal.example
limits:
max_tool_calls: 12
timeout_seconds: 60
default_action: deny 是重要的默认值。新工具没有被明确登记时，应当无法调用，而不是自动继承 Agent 的全部权限。开发者可以通过提交策略文件来申请新能力，安全团队则可以在代码评审和自动化测试中检查风险。
护栏需要覆盖模型之外的系统
Agent 的安全性不是单一模型指标。一个模型可能在文本回答中表现得很谨慎，但仍然会产生危险的工具参数；一次看似合理的调用，经过多轮循环后也可能造成超出预期的副作用。
评估时至少要观察以下信号：
- 被拒绝的工具调用数量和原因。
- Agent 尝试访问未授权资源的频率。
- 单次任务的工具调用次数、耗时和成本。
- 人工审批触发率及审批后的实际结果。
- 提示注入、敏感数据外泄和越权测试的通过率。
- 发生异常时，是否能从日志还原模型输入、策略决策和工具结果。
护栏也需要分级。低风险的只读查询可以自动执行；创建草稿、修改非关键数据可以限制参数和范围；发送外部消息、删除记录、部署生产变更等动作则应默认暂停，要求人工确认或转入专门的变更流程。
落地清单
企业开始部署 Agent 时，可以先从一条最小但完整的链路做起：
- 列出 Agent 的全部工具和数据访问范围。
- 为每个工具标记只读、写入或高影响风险等级。
- 让策略层在工具调用前执行默认拒绝的授权检查。
- 使用短期、最小权限的服务凭证，不把长期密钥交给模型。
- 为参数、网络、调用次数和运行时间设置硬限制。
- 为高影响动作加入人工审批和清晰的失败回退路径。
- 在 CI 和预发布环境中持续运行越权、注入和异常参数测试。
- 保留足够的审计信息，确保每次自动化动作都能追溯。
Agentic AI 的治理重点不是让模型变得“更听话”，而是把模型放回一个可验证的执行系统中。开发者仍然可以快速组合工具和工作流，但权限、数据和高风险动作必须由代码与平台强制约束。用可执行的护栏代替猜测，才是让 Agent 进入企业生产环境的现实起点。