AI Gateway 正在从“转发请求”的基础设施，变成能够理解请求主体和行为变化的安全控制面。Identity-aware AI Gateway 进入公开测试后，网关可以把 AI 流量与用户、代理身份关联起来；User Insights 则进一步为每个人和每个 agent 建立行为基线，并在异常行为出现时发出风险信号。
这件事的关键不只是记录谁调用了哪个模型，而是回答一个更实用的问题：这个身份平时怎么使用 AI，今天的行为是否明显偏离了自己的模式？
从请求日志走向行为基线
传统 AI 网关通常关注模型路由、访问控制、限流和成本统计。这些能力仍然重要，但它们很难单独发现内部风险。例如，同一个 API Key 在正常工作时间调用代码模型，并不能说明请求一定安全；真正有价值的上下文还包括：
- 请求来自哪个用户、团队或 agent。
- 使用了哪些模型、工具和数据源。
- 调用频率、时间段和持续时长是否符合历史习惯。
- 访问的数据范围是否突然扩大。
- 输出或工具调用是否表现出异常的自动化模式。
User Insights 的思路是为每个身份建立行为基线。这里的“身份”既可以是人，也可以是代表某个业务流程执行任务的 agent。系统不必把一次异常调用直接判定为恶意行为，而是先识别偏离程度，再结合策略决定是否告警、要求复核或暂时阻断。
这种方式比只依赖静态规则更适合 AI 场景。静态规则可以限制某个模型或某个接口，却很难表达“这个用户过去从未在凌晨批量读取这类数据”这样的上下文。
为什么身份上下文决定了告警质量
没有身份信息时，网关看到的可能只是大量相似的 HTTP 请求。加入身份信息后，同一条请求可以被放进更有意义的行为模型中：
用户 Alice：工作日 09:00-18:00，主要使用代码模型，每小时约 20 次请求
用户 Bob：负责数据分析，常用推理模型，偶尔访问销售数据集
Agent report-bot：每天 08:00 执行固定报表流程，调用范围稳定
当 report-bot 在凌晨突然调用一个新的外部工具，或者某个平时低频使用的用户在短时间内读取大量敏感上下文，系统就有了更强的风险判断依据。
身份感知并不意味着所有偏离都是攻击。用户可能正在处理紧急故障，agent 也可能刚刚发布了新版本。因此，告警系统需要保留原因、上下文和人工复核路径，避免把“新行为”简单等同于“恶意行为”。
可以这样落地：先在网关侧保留身份和行为事件
下面是一个可以改造的最小事件采集示例。它不依赖某个具体厂商 API，假设 AI Gateway 能够在转发模型请求前后生成事件。实际部署时，可以把 emit_event 替换为现有日志、消息队列或安全分析平台的写入接口。
运行前需要安装 Python 3.10 或更高版本。将代码保存为 identity_events.py 后直接执行即可：
from __future__ import annotations
from collections import Counter, defaultdict
from datetime import datetime, timezone
from typing import Any
class BehaviorBaseline:
"""按身份统计模型、工具和请求时间段，作为最小行为基线。"""
def __init__(self) -> None:
self.models: dict[str, Counter[str]] = defaultdict(Counter)
self.tools: dict[str, Counter[str]] = defaultdict(Counter)
self.hours: dict[str, Counter[int]] = defaultdict(Counter)
def observe(self, event: dict[str, Any]) -> None:
identity = event["identity"]
timestamp = datetime.fromisoformat(event["timestamp"])
self.models[identity][event["model"]] += 1
for tool in event.get("tools", []):
self.tools[identity][tool] += 1
self.hours[identity][timestamp.hour] += 1
def score(self, event: dict[str, Any]) -> list[str]:
identity = event["identity"]
timestamp = datetime.fromisoformat(event["timestamp"])
reasons: list[str] = []
if self.models[identity] and event["model"] not in self.models[identity]:
reasons.append("new_model")
if any(tool not in self.tools[identity] for tool in event.get("tools", [])):
reasons.append("new_tool")
if self.hours[identity] and timestamp.hour not in self.hours[identity]:
reasons.append("unusual_hour")
return reasons
def emit_event(event: dict[str, Any]) -> None:
print({"event": "ai_request", **event})
baseline = BehaviorBaseline()
training_events = [
{
"identity": "agent:report-bot",
"model": "analysis-model",
"tools": ["sales-db"],
"timestamp": "2025-01-06T08:10:00+00:00",
},
{
"identity": "agent:report-bot",
"model": "analysis-model",
"tools": ["sales-db"],
"timestamp": "2025-01-07T08:12:00+00:00",
},
]
for event in training_events:
baseline.observe(event)
candidate = {
"identity": "agent:report-bot",
"model": "general-model",
"tools": ["sales-db", "external-upload"],
"timestamp": "2025-01-08T02:31:00+00:00",
}
reasons = baseline.score(candidate)
emit_event(candidate)
print({"risk": "high" if len(reasons) >= 2 else "review", "reasons": reasons})
这个示例只展示了行为分析的骨架，不代表完整的生产级检测器。生产环境通常还要加入请求数量、数据敏感度、IP 或设备变化、地理位置、失败率、工具参数和人工反馈等信号。基线也应设置观察窗口和过期机制，否则用户行为变化后，旧基线会不断制造误报。
从告警到响应策略
身份感知分析的价值，最终体现在告警之后如何处理。可以按风险级别设计分层动作：
- 低风险：记录事件，加入身份时间线，等待更多上下文。
- 中风险：要求用户重新认证，或让 agent 进入人工审批队列。
- 高风险：暂停当前工具调用，限制敏感数据访问，并通知安全团队。
- 已确认风险：撤销相关令牌，隔离 agent，保留请求和响应审计记录。
建议把“异常原因”展示给调查人员，而不只显示一个抽象分数。例如，告警应尽量说明是新模型、新工具、异常时间段，还是请求量突然超过基线。可解释的原因能减少误报处理时间，也方便业务团队判断是否属于合法的新流程。
还需要注意隐私和权限边界。身份行为数据本身属于敏感安全数据，应明确保留周期、访问角色和脱敏规则；模型请求内容也不应因为启用分析而无条件长期保存。对于 agent，要给每个 agent 使用独立身份和最小权限，避免多个自动化流程共享一个无法追踪的凭据。
采用前的检查清单
Identity-aware AI Gateway 和 User Insights 适合从低风险、可观测的场景开始验证：
- 为人和 agent 分配稳定、可审计的身份标识。
- 明确要保护的模型、工具和数据源。
- 先收集一段时间的正常行为，再启用强制阻断。
- 用新工具、异常时间和数据范围扩大等场景测试误报率。
- 为告警定义负责人、升级路径和恢复动作。
- 限制行为数据和请求内容的保存范围。
- 定期重新训练或调整基线，覆盖组织和 agent 的正常变化。
公开测试阶段适合用来验证可见性、事件字段和告警流程，而不是直接把所有异常都配置成自动封禁。更稳妥的路径是先建立身份关联和行为时间线，再通过人工复核积累反馈，逐步把高置信度风险交给自动化响应。这样，AI Gateway 才不仅知道“请求去了哪里”，还能够判断“谁在以什么方式使用它，以及这种方式何时值得调查”。