跳转到主要内容
代理访问策略

用你可控的策略路由 AI 代理

按路由决定你的应用如何对待人类、AI 辅助用户和自主代理。Proof of Actor 提供证据，策略负责最终决定。

获取抢先访问了解其工作原理
Toshendra Sharma

作者 Toshendra Sharma创始人兼 CEO，AgentCredia · Updated November 13, 2026

仅靠一套策略适用于所有人，已经不够了

大多数应用最初都是围绕一种用户设计的: 一个点击界面的个人，登录到某个账户中。访问控制也沿用了这个假设。会话有效，请求就通过。看起来像自动化，就出现 CAPTCHA 或拦截。

这种模型正在失效。今天，同一个应用要同时服务人类、与 AI 助手协作的人，以及代表他人行事的自主代理。有些代理是客户自己的集成。有些是抓取文档的 AI 助手。有些是爬虫。还有一些试图滥用你的产品。单一的非黑即白规则已经无法同时适配这些情况。

AI 代理路由与访问策略，用一组有意识的决定取代单一规则: 哪些 actor 在哪些路由上获得哪种体验，以及在什么条件下获得。 Proof of Actor 为你的应用提供做出这些决定所需的证据，而决定本身仍由你掌握。关于这种方法背后的设计原则，请阅读 为人类和 AI 代理设计应用策略，并查看 SaaS 应用用例，了解策略如何映射到真实的产品工作流。

一个好的代理策略应该是什么样

有用的策略必须足够具体。它会明确路由或工作流、actor 类别、所需证据强度，以及对应响应。例如:

  • 只读目录路由: 允许已验证代理，并返回结构化响应; 对已声明代理使用标准限流。
  • 账户变更操作: 所有人继续使用现有的重新认证; 当 actor 是 Unknown 且操作影响较大时增加复核。
  • 支持提交: 接受已披露的 AI 辅助内容，并为路由加标签。
  • 注册: 保留现有检查; 不要仅凭推断出的 actor 结果作出决定。

这些策略都在回应 actor，同时既不把每个代理都当成滥用，也不盲目信任每个代理。这种平衡正是具备代理感知的访问控制的核心。关于这一点，为人类和 AI 代理设计应用策略 这篇博客按路由给出了更多示例。

五种响应

Proof of Actor 的 Route 能力围绕五种策略响应构建，供你的策略选择。

允许

像正常情况一样让请求继续。大多数流量，包括公共或低风险路由上的大多数代理流量，都应该直接允许。

适配

根据 actor 调整体验。向已验证代理提供结构化 API 响应，或提供页面的 Markdown 版本，而不是人类界面。关于这一模式，请参阅 向 AI 代理提供结构化内容。

质询

要求更强的证明: 重新登录、额外凭证、账户所有者确认。在误判代价较高的路由上使用质询。

复核

不是直接完成，而是让操作进入队列，或标记给人工检查。在阻止会伤害合法用户、但无人审核又风险过高的场景下，复核非常有用。

限流

针对 actor 和路由应用合适的速率或容量限制，避免自动化调用方压垮为人类设计的工作流。

为什么 robots.txt 不是访问策略

许多团队会先从 robots.txt 开始，它对爬虫来说是一个合理的初始信号。但它不是代理的访问策略。爬虫运营方会为不同的 user agent 记录不同行为: Anthropic 说明其 bot 会遵守 robots.txt 指令(Anthropic 爬虫文档), 而 OpenAI 指出对于 ChatGPT-User, 当用户向 ChatGPT 提问时其行为由用户发起，因此 robots.txt 规则可能不适用(OpenAI 爬虫文档). robots.txt 也无法说明 API、MCP 工具或已登录工作流。

访问策略必须在请求被处理的位置执行，读取诸如通过 RFC 9421 验证的签名这类证据，并按路由选择响应。对于 MCP server, MCP authorization 规范 定义了客户端如何通过 HTTP 获取 access token; actor 策略是在此基础上增加上下文，而不是取代它。

Proof of Actor 如何为你的策略提供输入

每次你的集成评估请求时，都会生成一个 actor 结果，策略可以读取其中四个部分:

  • Class: Human, Human + AI, Agent 或 Unknown。
  • Basis: verified, declared, inferred 或 unknown，因此策略可以把已验证签名与自声明的客户端名称区别对待。
  • Evidence summary: 对结果依据的可读说明，便于日志记录和复核。
  • Context: 是哪个集成、哪个路由产生了该结果。

由于 basis 是明确的，你的策略可以更加精确。"允许代理"可以变成"在读取路由上允许已验证代理，对已声明代理限流，对其他情况使用 Unknown 兜底"。从请求到决策的完整流程详见 工作原理。

兜底是策略的一部分

如果证据缺失，策略的效果就取决于它如何表现。Proof of Actor 会把这些情况明确展示出来，而不是隐藏它们。

  • Unknown: 证据不足以得出判断。你的策略需要为每条路由定义 Unknown 的含义。它绝不会被转换为 Human，也不会默认被视为恶意。
  • 超时: 结果未能及时返回。你的集成会应用该路由预先选择的兜底。
  • 缺失信号: 某个采集器未运行，或者某个 header 不存在。结果会反映这一点，策略也会据此处理。

对于每条路由，你都可以选择 fail open 或 fail closed。fail open 表示请求像没有 Proof of Actor 一样继续; fail closed 表示应用你现有的更强检查。低风险路由通常采用 fail open。敏感操作通常采用 fail closed。你是按风险等级逐项设置，而不是全局统一设置。

将身份、凭证和授权分开处理

代理访问策略位于三层不同的机制之上，保持它们分离可以避免最严重的错误。

  1. 身份证据 说明是谁在发起调用，以及证据是什么。Proof of Actor 提供这一层。
  2. 凭证 说明由哪个账户负责。你的会话、token 或 API key 提供这一层。
  3. 授权 说明该调用方是否可以执行此操作。你的权限模型提供这一层。

已验证的代理身份并不意味着该代理已获授权，也不意味着某个人已将权限委托给它，或其动作一定安全。请使用 actor 结果来路由并补充上下文。请使用你的授权模型来授予权限。Detection & Limitations 这页会准确说明每种证据分别能够证明什么。

以不破坏现有系统的方式上线

引入代理访问策略最安全的方式，是分阶段进行。

  1. 观察。 在 observation mode 下安装 Proof of Actor。对用户来说没有任何变化; 结果会被记录。
  2. 理解。 查看哪些 actor 使用了哪些路由、每条路由上的 unknown 比例，以及任何与你已有认知不一致的结果。
  3. 预览。 以 preview 方式运行策略，记录如果执行它会做什么，但不真正 enforce。
  4. 有选择地执行。 只在证据明确支持的一条路由上启用策略。观察结果。
  5. 扩展。 随着信心增强，再扩展到更多路由。

关于这一流程，安全地推出具备 actor 感知的策略 有逐步说明，而 在不阻断代理的情况下保护敏感操作 讨论了高风险路由。

你的团队能获得什么

使用 Proof of Actor，你的团队只需一次集成，就能获得三项能力。Detect 会收集 actor 信号，并把已验证断言与推断分离。Understand 会展示 actor 分析、趋势以及每个结果背后的证据，同时保留 Unknown 的可见性。Route 允许你编写本页描述的策略，并在你选择的位置应用它们。在 private beta 期间，路由策略会与每个 founding team 协作设计，并在你自己的应用代码中运行，因此你始终保有完全控制权。

需要避免的常见策略错误

首次设计代理访问的团队，往往会重复一些固定错误。避免这些错误可以节省数周返工时间。

  • 默认阻止所有代理。 合法代理随后会绕过你，通常会转而抓取你为人类用户搭建的界面，而这比结构化路径更难保护。
  • 相信一个已声明的名称。 只报上自己名字的客户端只是提出了一个主张，并没有提供证明。请按未验证调用方的标准对待它。
  • 所有地方都使用同一个兜底。 公共定价页上的 Unknown 和修改密码时的 Unknown 是两种不同情况。每条路由都需要自己的答案。
  • 根据推断对人做决定。 Actor 结果是路由所需的上下文，不是对个人的裁决。涉及后果的决定应保留给你自己的控制措施和复核流程。
  • 跳过观察阶段。 第一天就 enforce，意味着你会通过客户投诉来发现误报。先观察，再在证据清楚的地方执行。

在每次执行前，让安全、产品和支持负责人做一次简短的策略评审，通常就能及早发现这些问题。

从 founding developer program 开始

Proof of Actor 目前处于 private beta。入选的 founding development team 可在约定使用限制内，免费使用最多 12 months，并在设计第一批策略时获得我们工程团队的直接支持。

如果你正在决定应用应该如何对待 AI 代理，欢迎 申请早期访问。告诉我们哪些路由最重要，以及你希望做出哪些决定，我们会帮助你构建合适的策略。你也可以查看这套能力如何应用于 APIs 和 MCP servers。

来源

面向开发者

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human、Human + AI、Agent 或 Unknown。
basis
证据有多强：Verified、Declared、Inferred 或 Unknown。
evidence
结果背后的信号，让您的团队看清原因。

从观察模式开始: 将结果记录在日志旁边，在您选择 policy 之前不做任何更改。 阅读 Node.js 集成指南

常见问题

什么是 AI 代理访问策略?

这是你的应用根据发起请求的 actor 类型执行的一条规则，例如在只读路由上允许已验证代理，或在高影响操作上要求更强的凭证。Proof of Actor 提供 actor 结果; 你的策略决定响应。

Proof of Actor 会自动执行策略吗?

不会。每次集成都从观察模式开始，只有在你的团队确认该策略适合对应工作流后，才会按路由启用。

当 actor 是 Unknown 或检查超时会怎样?

你需要为每条路由定义明确的兜底，例如允许公共读取，并对账户变更保留现有检查。Unknown 和超时绝不会默认变成 Human。

我应该阻止所有 AI 代理吗?

通常不应该。许多代理都是合法参与者。策略可以为它们提供结构化路径，在关键环节加以限制，并把更强的检查保留给敏感操作。

策略可以对人做决定吗?

Proof of Actor 的结果不应作为涉及个人的重要决定的唯一依据，例如雇佣、授信或获取基本服务的访问。请将其与自己的控制措施一起用于路由和上下文判断。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？ 联系创始人