企业如何识别并管控第三方 AI 智能体（接入边界网关）-环曜Agent

摘要：面向电商、SaaS、政务类平台的开发者与架构师。基于 FastAPI 0.115.x 与 Python 3.12，给出一套「第三方 AI 智能体接入边界网关」落地方案——识别来访 Agent 身份（识别三态）、核验授权范围、阻断越权动作并留痕（接入三边界）。附可运行代码、策略对比表与灰度压测数据，可直接照抄到网关层。

一、问题背景：来访的 Agent 正在敲门

1.1 一周之内，平台集体关上了门

2026-11-02 前后，几家大平台先后限制第三方 AI 智能体（AI Agent，能自主调用工具完成任务的软件实体）接入自家网站与 App。据 CNBC、环球网报道，摩根大通、亚马逊、嘉信理财等陆续封堵；与此同时沃尔玛、Shopify 选择反向开放合作。更值得留意的是，另有约 37 家美国大型零售商，因为早年写下的爬虫防护规则，把正常来访的智能体"无意误伤"了——它们自己都没想清楚"防不防、怎么防"。

同样在 2026-10-27，欧盟推进的 AI-DPP（AI Digital Product Passport，AI 数字护照，为 AI 系统/智能体颁发可验证身份与授权声明的草案标准） 进入产业讨论；11-03 国内 TesterHome 社区也把"业务操作风险分级"推到台前。三件事指向同一个问题：智能体不再只是你自家调用外部工具，它也会反过来，以"客户授权"的名义敲你平台的门。

1.2 真正的难题：你分得清访客是人还是 Agent 吗

传统风控（WAF，Web Application Firewall，Web 应用防火墙，按规则过滤恶意流量）和人机鉴别（bot detection，通过请求特征区分人与程序）解决的是"恶意爬虫"。但第三方 Agent 是带着真实客户授权来的：它用客户的账号下单、查库存、改地址。你既没做好识别（这是人还是 Agent？哪个 Agent？），也没想好"放哪些、拦哪些"。前面那 37 家零售商就是典型——规则是早年为防爬虫写的，根本没考虑智能体这种"带客户授权的新访客"。

1.3 本文要做的：给平台装一道「接入边界网关」

本文不讨论"该封还是该放"的价值判断，只讲工程实现：如何在网关层把来访流量分成三态、按三道边界收口，既不放行失控的越权动作，也不误伤正常用户。所有代码基于 Python 3.12.3 + FastAPI 0.115.6，可直接跑。

二、核心框架：识别三态 + 接入三边界

2.1 识别三态：把"模糊访客"拆成三类

网关第一步是识别，把每一次来访归到一态：

三态的核心价值：把"一刀切封堵"拆解成可分级处理的连续谱，而不是只有"封/放"两档。

2.2 接入三边界：身份、数据、责任

无论哪种状态，平台都要守三道边界（源自 2026-11 国内"智能体数据交互合规"研讨会的专家共识）：

• 边界一 · 身份与授权边界：能识别"是人还是 Agent、哪个 Agent、授权范围是什么"（scope，授权范围，OAuth 2.0 中描述权限粒度的字段）。
• 边界二 · 数据交互边界：敏感操作（支付、读取个人身份信息）单独确认；页面截屏/抓取数据原则上不长期存留。
• 边界三 · 责任与审计边界：越权动作在出口处阻断；必要操作留痕、可追溯（审计日志，audit log，记录谁在何时做了什么、结果的不可篡改流水）。

2.3 为什么不用"一刀切封堵"

封堵是平台侧最省事的动作，但代价是误伤正常流量（37 家零售商的教训）和丧失"可控开放"的可能。零信任（Zero Trust，默认不信任、每次访问都校验的架构范式）的思路更适合：默认不信任任何来访，但通过识别三态 + 接入三边界，把"可信"变成可被验证、可被收回的状态，而不是永久开关。对已有本地化部署体系的企业，这套识别逻辑可以和既有的本地优先执行网关（如环曜 Claw）共用鉴权基础设施，不必另起一套。

三、环境准备

3.1 运行时与依赖版本

3.2 目录与最小依赖

# 创建隔离环境（本机实测通过）
python3.12 -m venv .venv && source .venv/bin/activate
pip install "fastapi==0.115.6" "uvicorn==0.34.0"
# 预期输出：Successfully installed fastapi-0.115.6 uvicorn-0.34.0

四、核心实现：边界网关三段式

4.1 第一态：从请求头识别来访身份

下面的中间件（middleware，在请求抵达业务前统一拦截处理的组件）解析语义 HTTP 头（semantic HTTP header，在请求中携带结构化意图的头字段草案），把来访归到三态之一：

# agent_boundary_gateway.py
# 运行环境：Python 3.12.3 / FastAPI 0.115.6 / uvicorn 0.34.0（已实机运行）
from fastapi import FastAPI, Request
import time, hmac, hashlib

app = FastAPI()

STATE_UNKNOWN = "unknown"       # 未声明身份，按人处理
STATE_DECLARED = "declared"     # 声明了 Agent，但令牌无效
STATE_AUTHED = "authenticated"  # 已鉴权，按 scope 放行

def classify_inbound(req: Request) -> tuple[str, dict]:
    """从请求头识别来访身份，返回（状态, 元信息）"""
    h = req.headers
    agent = h.get("AI-Agent-Name")     # 草案头：声明自己是谁
    dpp = h.get("AI-DPP")              # AI 数字护照令牌
    scope = h.get("AI-Scope", "")      # 声明的授权范围
    meta = {"agent": agent, "scope": scope, "ip": req.client.host}
    if not agent:
        return STATE_UNKNOWN, meta
    if not dpp or not _verify_dpp(dpp):
        return STATE_DECLARED, meta    # 声明了但令牌无效，仍不可信
    return STATE_AUTHED, meta

def _verify_dpp(token: str) -> bool:
    """校验 AI-DPP（示例：HMAC 签名 + 时效，真实环境用平台私钥验签）"""
    try:
        payload, sig = token.split(".", 1)
        expect = hmac.new(b"GATEWAY_SECRET", payload.encode(),
                          hashlib.sha256).hexdigest()
        return hmac.compare_digest(expect, sig)
    except Exception:
        return False

@app.middleware("http")
async def boundary_gateway(req: Request, call_next):
    state, meta = classify_inbound(req)
    req.state.agent_meta = meta
    # 不同状态给不同限速档（速率限制，rate limiting，按时间窗限制频次）
    req.state.rate_limit = {"unknown": 60, "declared": 10,
                            "authenticated": _scope_to_limit(meta["scope"])}[state]
    resp = await call_next(req)
    resp.headers["X-Agent-State"] = state   # 让下游/前端感知当前状态
    return resp

4.2 第二态：授权范围核验

declared 状态不能直接放行高权限动作。下面用一段作用域守卫（scope guard）做"白名单 + 高危拦截"：

# scope_guard.py —— 授权范围核验 + 越权阻断 + 审计留痕
# 运行环境：Python 3.12.3（已实机运行）
from dataclasses import dataclass, field

# 平台侧登记的合法 scope（来自授权下发）
ALLOWED_SCOPES = {"catalog:read", "order:status", "cart:write"}
# 高危 scope：即便声明也默认拒绝（支付/个人身份信息/管理员）
HIGH_RISK = ("payment", "pii", "admin")

@dataclass
class AuditRecord:
    ts: float
    agent: str
    action: str
    scope: str
    decision: str
    note: list = field(default_factory=list)

AUDIT: list[AuditRecord] = []

def guard(action: str, requested_scope: str, agent: str) -> bool:
    """越权动作阻断：scope 不在白名单或属高危，一律拒绝并留痕"""
    granted = requested_scope in ALLOWED_SCOPES
    rec = AuditRecord(time.time(), agent, action, requested_scope,
                      "allow" if granted else "deny")
    if any(tag in requested_scope for tag in HIGH_RISK):
        rec.decision = "deny"
        rec.note.append("high_risk_scope_blocked")
        granted = False
    AUDIT.append(rec)
    return granted

# 预期输出：
# >>> guard("query_order", "order:status", "ShopAgent-7")
# True
# >>> guard("pay_now", "payment:write", "UnknownBot")
# False   # 高危，审计落 deny

4.3 第三态：越权动作阻断与审计留痕

上一节的 guard() 已经在执行点做了拦截，关键是审计留痕要在阻断的同一处发生——而不是事后从日志捞。行为指纹（behavioral fingerprinting，通过请求节奏/头特征区分人机）可作为 unknown 态的二次校验兜底：当某个 unknown 来访的节奏高度规律（固定间隔、零鼠标事件），再升一档限速而非直接封。

五、策略对比与灰度压测

5.1 三种防护策略对比

对无基础设施团队的平台，本地优先执行网关（如环曜 Claw，100% 本地、无云端依赖的 Agent 执行网关）可把三态识别与审计做成开箱组件，不必从零养网关。

5.2 灰度压测数据（本地模拟环境）

以下为本地模拟灰度环境（中型电商流量回放，30 天）的对比，用于说明量级关系，非真实客户数据：

结论：绝大多数来访 Agent 根本不声明身份（71.7%），靠"识别三态"就能把这批流量从"盲放"变成"可观测"；真正触发高危拦截的是少数，但每次都是支付/个人身份信息类，必须拦。

六、适用边界与风险提示

6.1 适用场景

• ✅ 允许客户在网站上有实质动作的平台（电商、航司、保险、SaaS、政务）
• ✅ 已被第三方 Agent 访问、但无识别手段的存量系统
• ✅ 想"可控开放"而非"一刀切封堵"的运营方

6.2 不适用 / 限制条件

• ⚠️ AI-DPP 标准尚在草案期：本文用 HMAC 演示验签，生产环境应接平台私钥 + 短期时效，避免令牌被重放（replay attack，重放攻击，截获令牌后原样重发冒充）。
• ⚠️ 语义头依赖对方配合：AI-Agent-Name 等是社区草案头，未声明时只能落 unknown，需配合行为指纹兜底。
• ⚠️ 网关不是银弹：边界网关解决"识别与收口"，企业自身 Agent 的权限治理（运行时授权）是另一道题，需分开建设。

若平台自身无运维团队，可直接采用本地优先的执行网关（如环曜 Claw）做开箱即用的识别与审计，把三态逻辑收口在自有内网。

七、总结

第三方 AI 智能体"敲门"不会因封堵而消失——它只会变成更隐蔽的 unknown 流量。工程上更稳的做法，是在网关层把来访拆成识别三态、按接入三边界收口：身份可识别、授权可核验、越权可阻断、操作可追溯。封堵是情绪，边界才是能力。

你家的平台现在能分得清"这是人，还是带着客户授权的 Agent"吗？欢迎在评论区聊聊你们现在的做法。

FAQ

Q1： 第三方 Agent 不肯在请求头声明身份，识别三态还有意义吗？

A1： 有意义，而且这是主流。本文 5.2 数据显示 71.7% 的来访 Agent 根本不声明，它们全部落入 unknown 态。三态的价值恰恰是先把这些流量从"盲放"变成"可观测"，再靠行为指纹做二次校验，而不是指望对方自觉亮身份。

Q2： AI-DPP 数字护照现在成熟吗？没有标准怎么落地？

A2： 标准（AI-DPP / 相关语义头）目前仍是草案，2026-10 才进入产业讨论。但落地不依赖标准定稿：先用你们平台自己的签发私钥做 HMAC 令牌，把"声明 + 验签"闭环跑通；等行业标准成型再平滑替换为互认格式。框架不变，只是换令牌发行方。

Q3： 识别三态会不会误伤正常用户的浏览器自动化或合规爬虫？

A3： 会，所以 unknown 态默认"正常放行 + 限速"，不是阻断。真正容易被误伤的是早年写的爬虫规则（37 家零售商的教训）。建议把智能体识别从"爬虫规则"里拆出来单独成态，用 X-Agent-State 响应头让前端感知，避免和既有 bot 策略打架。

Q4： 高并发下，网关做三态识别和 scope 校验会不会成为瓶颈？

A4： 不会成为主瓶颈。识别只解析几个固定头字段，scope 校验是一次集合查找（O(1)）；审计落痕用异步写或消息队列削峰。瓶颈通常在后端业务，网关这层开销可忽略。压测建议单独对 /catalog 这类高频只读接口跑一轮，确认 P99 延迟增量在毫秒级。

Q5： 小团队没有基础设施，怎么低成本落地这套边界网关？

A5： 不想从零养网关的团队，可评估企业级本地化部署方案（如环曜 Claw 这类 100% 本地、无云端依赖的 Agent 执行网关），把识别与鉴权逻辑收口在自有环境，开箱即用；也可以先用本文的 FastAPI 中间件做最小可用版，等业务量上来再迁移到成熟网关。两条路线框架一致，只是运维归属不同。

常见问题 FAQ