Agentic AI 的风险不只来自模型会不会答错，更来自它能够调用 API、读取数据、修改资源并触发后续流程。Docker 汇集企业安全负责人讨论的核心问题，正是如何治理这些具备行动能力的 AI Agent，同时避免把开发流程拖入漫长的人工审批。
真正可落地的答案不是要求开发者“谨慎使用”，而是把权限、审批、审计和运行时隔离做成可执行的工程护栏。这样，常规操作可以自动通过，高风险动作才需要升级处理。
风险边界应该围绕动作，而不是模型名称
传统应用通常有相对稳定的调用链，而 Agent 会根据上下文动态选择工具、组合步骤。相同的用户请求，可能在不同时间产生不同的工具调用序列。因此，只批准某个模型或某个 Agent 名称，并不能充分约束它最终产生的副作用。
治理时更值得追踪的是四类信息：
- 身份：用户、Agent、工作负载和服务账号分别是谁。
- 动作：Agent 准备调用哪个工具，执行读取、写入、删除还是对外发送。
- 资源：目标是测试数据库、生产集群、代码仓库还是客户数据。
- 上下文：请求来自哪个环境，是否包含敏感数据，是否已经获得人工批准。
例如，读取测试环境日志可以自动放行；修改生产部署必须获得审批；删除数据库、导出凭据或向未知域名发送数据则应直接拒绝。这样的规则比“允许 Agent 使用 Kubernetes”更精确，也更容易审计。
护栏要进入执行路径
只把规则写在安全手册里，Agent 在运行时并不会自动遵守。有效护栏必须位于模型与工具之间，在每次工具调用前做授权判断，并在调用后记录结构化审计事件。
一条典型执行链可以是：
- Agent 生成结构化工具调用，而不是直接执行任意 Shell 文本。
- 策略层检查主体、动作、资源、环境和参数。
- 低风险请求自动执行，高风险请求进入审批队列。
- 工具在隔离环境中使用短期凭据运行。
- 系统记录策略版本、输入摘要、审批人和执行结果。
Prompt 中的“不要执行危险操作”可以作为行为提示，但不能代替授权控制。Prompt 可能被注入、忽略或被间接数据影响；权限系统则应该在模型之外独立生效。
可以这样实践：给工具调用加一个最小策略门
下面是一个仅依赖 Python 标准库的最小示例。它不是 Docker 或某个商业产品的正式 API，而是一个可直接运行、再改造成策略服务的参考实现。运行前可修改 REQUESTS，模拟自己的 Agent 工具调用。
from dataclasses import dataclass
from typing import Literal
Decision = Literal["allow", "require_approval", "deny"]
@dataclass(frozen=True)
class ToolRequest:
actor: str
tool: str
action: str
environment: str
destination: str = ""
def authorize(req: ToolRequest) -> tuple[Decision, str]:
blocked_actions = {"delete_database", "read_credentials"}
approved_tools = {"logs.read", "deploy.update", "http.post"}
if req.tool not in approved_tools:
return "deny", "tool is not registered"
if req.action in blocked_actions:
return "deny", "action is prohibited"
if req.tool == "http.post" and not req.destination.endswith(".example.com"):
return "deny", "external destination is not allowlisted"
if req.environment == "production" and req.action != "read":
return "require_approval", "production write requires a human"
return "allow", "request matches automated policy"
REQUESTS = [
ToolRequest("support-agent", "logs.read", "read", "staging"),
ToolRequest("release-agent", "deploy.update", "write", "production"),
ToolRequest(
"research-agent",
"http.post",
"send",
"development",
"collector.unknown.net",
),
]
for request in REQUESTS:
decision, reason = authorize(request)
print(f"{decision:18} {request.actor:16} {request.tool:14} {reason}")
执行：
python3 guardrail.py
预期结果中，测试环境的日志读取会通过，生产写入需要审批，向未知域名发送数据会被拒绝。真实系统还需要加入身份签名、参数校验、超时、速率限制、审计存储和不可绕过的网络策略。
如果 Agent 需要运行代码，可以进一步把执行器放入容器，并使用只读文件系统、资源限制和无特权用户。下面的命令可作为本地隔离实验，需将 agent-task 替换为自己的镜像名：
docker run --rm \
--read-only \
--user 65532:65532 \
--cap-drop ALL \
--security-opt no-new-privileges \
--memory 256m \
--cpus 0.5 \
--network none \
agent-task:latest
--network none 适合不需要联网的任务。需要访问内部 API 时，不应直接开放全部网络，而应通过受控代理或域名白名单提供最小出口。
不拖慢开发的关键是默认路径清晰
护栏是否有效，不只看它拦住了多少请求，还要看开发者能否预测结果。策略含糊、审批没有负责人、测试环境与生产环境规则完全相同，都会促使团队寻找绕过路径。
落地时可以检查以下项目：
- 工具必须注册，并声明输入模式、所需权限和可能副作用。
- 凭据按任务临时签发，不把长期密钥写入 Prompt、镜像或环境模板。
- 读取、写入、删除和外发采用不同风险等级。
- 常规低风险操作自动放行，审批集中在生产写入和不可逆动作。
- 审计日志记录最终工具调用，而不只记录自然语言对话。
- 策略在 CI 和预发布环境中可以测试，变更也需要版本管理。
- 容器隔离是纵深防御的一层，不能替代身份认证和细粒度授权。
Agentic AI 的治理目标不是消除所有自主性，而是限定自主性能够作用的范围。把规则变成机器可执行、可测试、可审计的控制面，开发者才能快速迭代，安全团队也不必依赖猜测判断一次 Agent 行动是否越界。