跳转到主要内容
APIS

了解是谁在调用你的 API。

为每个 API 请求添加 Actor 上下文: 是哪个客户端在调用、证据有多强，以及你的 API 应该如何处理, 按路由分别决定。

获取抢先访问了解其工作原理
example-app.test · actor result

POST /api/v1/orders

智能体basis: inferred

证据

没有浏览器上下文且具有自动化请求模式的 API key 流量

您的策略: 在创建订单前要求更强的凭证

API key 不是身份，身份也不是权限。

大多数 API 流量带着一种凭据到达，它说明的是哪个账户在付费，而不是哪个 client 在调用，或是谁指示它的。有些 client 会对请求签名，很多只声明一个名称，还有很多什么都不说。

Proof of Actor 将每个 API 必须回答的三个问题分开，因此每个问题都能获得正确的证据和正确的控制。

三个独立的问题
  • 谁在调用？Actor 身份: 签名、声明或推断
  • 哪个凭证？您的 API 密钥、OAuth 令牌或会话
  • 它可能会做什么？您的授权和策略

Proof of Actor 回答第一个问题。你的技术栈保留另外两个。

API 团队如何使用 actor 上下文

  • 识别已签名的客户端

    使用已发布的密钥检查请求签名, 并查看请求属于哪个操作者。

  • 将声明视为声明

    记录自我声明的客户端名称，并将其与已验证身份分开。

  • 按路由制定策略

    低影响读取可自由允许，对写入和高影响 endpoint 则要求更多。

  • 查看每个调用方

    了解哪些客户端使用了哪些端点，包括未知端点。

  • 分开保管凭据

    API key 和 OAuth 仍然决定访问权限。actor 上下文会补充是谁在调用。

  • 为未知类制定方案

    按每条 route 定义当调用方未提供可用证据时会发生什么。

01 · 检测

来自每个请求的证据。

服务器、边缘和 HTTP API 集成会读取请求签名、声明的客户端详情和请求上下文，并为每一项标注其依据。

  • HTTP 消息签名已根据发布的密钥进行验证。
  • 作为声明记录的已声明客户端名称。
  • 从你的服务器、网关或边缘获取请求上下文。
signals · last request per source
  • 请求签名valid · sample-crawler.exampleverified
  • 客户端声明"research-assistant/2.1"declared
  • 浏览器交互pointer + keyboard eventsinferred
  • 没有受支持的信号route not instrumentedunknown

02 · 理解

了解谁在使用哪个 endpoint。

查看每条路由上的行为主体构成，查看哪些操作方最常调用你，以及未知调用方集中在哪些地方。

  • 按路由和操作者查看调用方。
  • 每个分类背后的证据。
  • 每个端点的 Unknown 率。
按 route 划分的流量 · 7 days
  • /dashboard未知 7%
  • /api/v1/catalog未知 15%
  • /support/tickets未知 8%
  • /signup未知 21%
人类人类 + AI智能体未知

03 · 路由

与影响相匹配的控制措施。

编写路由级策略：为 Verified agent 提供结构化响应，为 Declared 客户端提供标准限制，为高影响操作提供更强凭证。

  • 按路由、类别和依据制定策略。
  • 在需要时升级到更强凭证。
  • 先观察，再预览，然后执行。
policy · example-app.test
  • /api/v1/catalogenforce智能体允许 · 结构化 API
  • /support/ticketsenforce人类 + AI允许 · 标记为 Human + AI
  • /account/*preview未知保留现有检查
  • /api/v1/orderspreview智能体要求更强的凭据

示例决策

从 request 到结果，再到你的决策。

  • 经验证的 Agent 读取你的目录

    请求

    GET /api/v1/catalog

    结果

    智能体basis: verified

    你的决策

    以 agent rate limit 和结构化响应允许。

  • 一个自动化客户端正在下单

    请求

    POST /api/v1/orders

    结果

    智能体basis: inferred

    你的决策

    在创建订单前要求 app 的更强凭证。

  • 没有证据的客户端

    请求

    GET /api/v1/catalog

    结果

    未知basis: unknown

    你的决策

    只读路由：使用默认限流允许。

无风险推出

团队从观察模式开始，并按 route 逐步推进。

  1. 01

    观察每条 route

    在您的 API 前面添加中间件或 HTTP API。每条 route 都会记录签名、声明和 Unknown 调用者。

  2. 02

    预览 route policy

    在真实 traffic 上检查 agent rate limit 或逐级升级凭证会产生什么效果，然后再应用。

  3. 03

    按影响执行

    保持读取开放，收紧写入，并让 API keys 和 OAuth 负责访问控制。

与你的技术栈协同工作

  • 创始团队

    Web server 中间件 (Node.js)

    服务端

    面向服务器渲染应用和 APIs 的请求级信号。

  • 创始团队

    Next.js

    服务器端和边缘

    用于页面和 API 路由的中间件。

  • 创始团队

    浏览器脚本

    仅浏览器信号

    来自浏览器会话的交互信号，并配合服务端集成。

  • 创始团队

    Cloudflare 和边缘运行时

    Edge

    在请求到达你的源站之前，在边缘获取信号。

  • 创始团队

    通用 HTTP API

    任何技术栈

    将请求上下文发送到 API，并接收带有依据的结果。

  • 创始团队

    MCP服务器

    MCP

    用于 MCP 工具调用的 Actor 上下文。

  • 路线图

    WordPress

    插件

    适用于 WordPress 网站的插件。

  • 路线图

    原生移动端

    iOS 和 Android

    原生 iOS 和 Android SDK。

在 onboarding 期间，我们会与每个创始团队进行一对一交付集成。使用不同的技术栈？申请时请告诉我们。

了解更多

阅读检测与局限性

常见问题

客户端需要对其请求签名吗？

不会。已签名请求提供最强的 evidence，但 Proof of Actor 也会记录 declarations 和 inferences，并为每一项标注其 basis；当证据不足时会报告 Unknown。

有效签名是否意味着客户端被允许行动？

不会。它只显示该请求是用一个与公开标识符绑定的 key 签名的。该 operator 可以做什么，由你的授权和策略决定。

它会取代 API keys 或 OAuth 吗？

不会。凭据仍然控制访问。Proof of Actor 只是补充是谁或什么在调用，因此你可以在其上应用更好的策略。

我们可以按 endpoint 设置不同规则吗?

是。策略按路由编写，因此只读端点和高影响写入可以区别对待。

费用是多少？

入选的创始开发者团队可在约定的使用限额内获得最多 12 个月免费。

了解谁在调用您的 API。

加入 Proof of Actor founding developer program。

获取抢先访问开发者中心

想先聊聊？ 联系创始人