AI Agent 不只会回答问题，还可能调用工具、访问数据并触发外部操作。Docker AI Governance 现在把组织内 Agent 触发的策略判定汇总成一份可搜索的审计记录，并将这些记录发送到安全团队已有的 SIEM。这样，团队既能说明 Agent 做了什么，也能证明策略拦截了什么。
审计对象从“应用请求”变成“策略判定”
传统应用日志通常记录 HTTP 状态码、异常堆栈和用户操作，但 AI Agent 的关键风险经常发生在模型输出与工具调用之间。例如：
- Agent 尝试读取受限制的文件或数据源；
- 提示词或模型输出触发组织策略；
- 某次工具调用被允许、拒绝或需要进一步审查；
- 同一个 Agent 在短时间内连续触发多次违规判定。
单独查看应用日志，很难回答“哪条策略为何阻止了哪个 Agent”。统一的策略判定记录补上了这层上下文。根据来源摘要，Docker AI Governance 会记录组织内的策略决策，并把它们流式发送到现有 SIEM，使安全团队可以继续使用熟悉的查询、告警和事件响应流程。
这里的重点不是再建一套安全控制台，而是让 AI 治理事件进入现有证据链。身份日志、云审计日志、终端告警与 Agent 策略事件可以在同一时间线上关联。
SIEM 中应该围绕哪些问题查询
接入完成后，搜索不应只停留在“过去一天有多少拒绝”。更有价值的问题包括：
- 哪些 Agent、用户或工作负载最频繁地触发拒绝？
- 某条策略的触发量是否突然升高？
- 被拒绝的行为是否在更换工具、模型或身份后再次出现？
- 策略更新前后，允许与拒绝的比例是否发生异常变化？
- 高敏感数据相关事件是否同时伴随异常登录或权限变更？
实际字段名称应以 Docker AI Governance 输出到 SIEM 的事件模式为准。落地时建议至少确认时间、组织、Agent、主体、策略、判定结果和关联标识是否可用。不要根据示例字段直接假定产品的真实 schema。
可以这样实践：先验证接收、解析与告警链路
下面是一个可运行的本地接收器，用来模拟 SIEM 的 HTTP Collector。它不是 Docker 官方接口示例，而是一个管道验收工具：先确认 JSON 事件能够被接收、持久化和检索，再按实际 SIEM 与 Docker 配置替换端点和认证方式。
将以下内容保存为 receiver.py，需要 Python 3.10 或更高版本，不依赖第三方包：
from http.server import BaseHTTPRequestHandler, HTTPServer
import json
from datetime import datetime, timezone
OUTPUT_FILE = "ai-policy-events.jsonl"
class EventHandler(BaseHTTPRequestHandler):
def do_POST(self):
length = int(self.headers.get("Content-Length", "0"))
raw = self.rfile.read(length)
try:
event = json.loads(raw)
except json.JSONDecodeError as exc:
self.send_error(400, f"invalid JSON: {exc}")
return
envelope = {
"received_at": datetime.now(timezone.utc).isoformat(),
"event": event,
}
with open(OUTPUT_FILE, "a", encoding="utf-8") as output:
output.write(json.dumps(envelope, ensure_ascii=False) + "\n")
print(json.dumps(envelope, ensure_ascii=False, indent=2))
self.send_response(202)
self.end_headers()
self.wfile.write(b"accepted\n")
def log_message(self, format, *args):
return
if __name__ == "__main__":
server = HTTPServer(("127.0.0.1", 8080), EventHandler)
print("Listening on http://127.0.0.1:8080/events")
server.serve_forever()
启动接收器：
python3 receiver.py
在另一个终端发送一条模拟策略事件。下面的字段仅用于演示查询设计，需要根据实际导出的事件模式调整：
curl --fail-with-body \
-X POST http://127.0.0.1:8080/events \
-H 'Content-Type: application/json' \
-d '{
"event_type": "ai.policy.decision",
"agent_id": "support-agent",
"actor": "user-4821",
"policy": "restricted-data-access",
"decision": "deny",
"resource": "customer-export",
"correlation_id": "run-7f3a"
}'
检查落盘结果，并筛选拒绝事件：
python3 - <<'PY'
import json
with open("ai-policy-events.jsonl", encoding="utf-8") as events:
for line in events:
record = json.loads(line)
event = record["event"]
if event.get("decision") == "deny":
print(event.get("agent_id"), event.get("policy"), event.get("correlation_id"))
PY
生产环境还要验证重试、重复事件、乱序、限流、认证失败和 SIEM 不可用时的行为。接收成功不代表审计链路可靠，尤其要确认事件在故障期间是否会丢失，以及如何识别重复记录。
告警要区分攻击、误用与策略漂移
每次拒绝都触发高优先级告警，会迅速制造噪声。更合理的分层方式是：单次低风险拒绝只进入检索；同一主体连续触发拒绝时提高等级；涉及敏感资源、特权工具或多个身份的事件直接升级。
策略更新也需要进入变更管理。拒绝量突增可能意味着攻击，也可能是策略过宽、Agent 工作流变化或字段映射错误。告警中应保留策略标识、Agent 标识和关联 ID，让响应人员能回到一次具体运行，而不是只看到一条抽象的“AI 风险”。
上线前检查清单
- 确认 Docker AI Governance 与目标 SIEM 支持的传输、认证和事件格式；
- 为事件保留策略、主体、Agent、判定结果和关联上下文，同时避免记录不必要的提示词或敏感正文；
- 用允许、拒绝、格式错误和接收端故障四类场景做端到端测试；
- 为高风险拒绝、短时间重复触发和基线突变分别设置规则；
- 明确定义日志保留期、访问权限、脱敏方式与审计责任人；
- 定期验证策略判定数与 SIEM 接收数，监控静默丢数。
把 Agent 策略判定送进已有 SIEM，价值不只是“日志集中化”。它让 AI 行为进入安全团队已经运行的调查、告警和合规流程。不过，审计日志只能提供证据，不能代替策略设计、最小权限、人工审批和事件响应演练。