Перейти к основному содержимому
API

Понимайте, кто вызывает ваш API.

Добавляйте контекст актора к каждому запросу API: какой клиент вызывает, насколько сильны доказательства и что ваш API должен с этим делать, по каждому маршруту.

Получить ранний доступИзучить, как это работает
example-app.test · результат актера

POST /api/v1/orders

Агентbasis: inferred

Доказательства

Трафик по ключу API без браузерного контекста и с автоматизированным шаблоном запросов

Ваша policy: Запросить более сильный credential перед созданием заказа

API key - это не идентичность, а идентичность - это не разрешение.

Большая часть traffic API приходит с credential, который говорит, какой account оплачивает, а не какой client вызывает его или кто отдал инструкцию. Некоторые clients подписывают свои requests, многие только declare имя, а многие не сообщают ничего.

Proof of Actor разделяет три вопроса, на которые должен отвечать каждый API, чтобы для каждого были правильные доказательства и правильный контроль.

три отдельных вопроса
  • Кто вызывает?Идентичность актора: подпись, декларация или вывод
  • Какая учетные данные?Ваш API key, OAuth token или session
  • Что он может делать?Ваши authorization и policy

Proof of Actor отвечает на первый. Ваш стек сохраняет два других.

Что команды API делают с контекстом актора

  • Распознавать подписанных клиентов

    Проверяйте подписи запросов по опубликованным ключам и смотрите, какому оператору принадлежит запрос.

  • Относитесь к декларациям как к декларациям

    Фиксируйте самостоятельно заявленные client names и отделяйте их от verified identity.

  • Политики по маршруту

    Свободно разрешайте низко-рисковые чтения и запрашивайте больше для записей и высоко-рисковых endpoint.

  • Видеть каждого вызывающего

    Понимайте, какие clients используют какие endpoints, включая unknown ones.

  • Держите учетные данные отдельно

    Ключи API и OAuth по-прежнему определяют доступ. Контекст актора добавляет, кто именно вызывает.

  • План для Unknown

    Определите, что происходит, когда вызывающая сторона не предоставляет usable evidence, для каждого route.

01 · Обнаружение

Evidence из каждого request.

Интеграции для сервера, edge и HTTP API считывают сигнатуры запросов, заявленные данные клиента и контекст запроса, а затем помечают каждую запись по ее основанию.

  • HTTP message signatures, проверенные по опубликованным ключам.
  • Заявленные имена клиентов, записанные как декларации.
  • Получайте контекст запроса с вашего сервера, gateway или edge.
сигналы · последний запрос по источнику
  • Подпись запросаvalid · sample-crawler.exampleverified
  • Заявление клиента"research-assistant/2.1"declared
  • Взаимодействие в браузереpointer + keyboard eventsinferred
  • Нет supported signalsroute not instrumentedunknown

02 · Понимание

Знайте, кто использует какой endpoint.

Смотрите состав actor на каждом маршруте, какие операторы обращаются к вам чаще всего и где концентрируются неизвестные вызывающие.

  • Вызывающие по route и оператору.
  • Доказательства, стоящие за каждой классификацией.
  • Доля Unknown по endpoint.
traffic by route · 7 days
  • /dashboardНеизвестно 7%
  • /api/v1/catalogНеизвестно 15%
  • /support/ticketsНеизвестно 8%
  • /signupНеизвестно 21%
ЧеловекЧеловек + ИИАгентНеизвестно

03 · Маршрутизация

Контроли, соответствующие масштабу воздействия.

Создавайте политики на уровне маршрутов: структурированные ответы для Verified agents, стандартные лимиты для Declared clients, более строгие учетные данные для действий с высоким влиянием.

  • Политики по маршруту, классу и основанию.
  • Переходите на более сильные учетные данные, когда это важно.
  • Наблюдать, предварительно просмотреть, затем enforce.
policy · example-app.test
  • /api/v1/catalogenforceАгентРазрешить · структурированный API
  • /support/ticketsenforceЧеловек + ИИРазрешить · пометить как Human + AI
  • /account/*previewНеизвестноСохраняйте существующие проверки
  • /api/v1/orderspreviewАгентТребовать более сильные учетные данные

Примеры решений

От запроса к результату и затем к вашему решению.

  • Подтвержденный агент читает ваш каталог

    Запрос

    GET /api/v1/catalog

    Результат

    Агентbasis: verified

    Ваше решение

    Разрешите с agent rate limit и структурированным ответом.

  • Автоматизированный клиент оформляет заказ

    Запрос

    POST /api/v1/orders

    Результат

    Агентbasis: inferred

    Ваше решение

    Запросите более сильный credential приложения перед созданием заказа.

  • Клиент без доказательств

    Запрос

    GET /api/v1/catalog

    Результат

    Неизвестноbasis: unknown

    Ваше решение

    Маршрут только для чтения: разрешить с лимитом скорости по умолчанию.

Внедряйте без риска

Команды начинают в observation mode и переходят route за route.

  1. 01

    Наблюдайте каждый route

    Добавьте middleware или HTTP API перед вашим API. Signatures, declarations и Unknown callers записываются по каждому route.

  2. 02

    Предпросмотр route policies

    Проверьте, что agent rate limits или step-up credentials сделали бы на реальном трафике до их применения.

  3. 03

    Применять по влиянию

    Оставьте reads открытыми, ужесточите writes и оставьте API keys и OAuth под контролем доступа.

Работает с вашим стеком

  • Команды первых участников

    Промежуточное ПО веб-сервера (Node.js)

    Server-side

    Сигналы на уровне запроса для серверных приложений и APIs.

  • Команды первых участников

    Next.js

    На стороне сервера и edge

    Middleware для page и API routes.

  • Команды первых участников

    Скрипт браузера

    Только браузерные сигналы

    Сигналы взаимодействия из browser sessions, вместе с server-side integration.

  • Команды первых участников

    Cloudflare и edge runtimes

    Edge

    Сигналы на edge до того, как запросы достигнут вашего origin.

  • Команды первых участников

    Универсальный HTTP API

    Любой стек

    Отправьте контекст запроса в API и получите результат с его основанием.

  • Команды первых участников

    Сервер MCP

    MCP

    Контекст актора для вызовов инструментов MCP.

  • Roadmap

    WordPress

    Плагин

    Плагин для сайтов WordPress.

  • Roadmap

    Нативный мобильный

    iOS и Android

    Native iOS и Android SDK.

Интеграции внедряются вручную вместе с каждой founding team во время onboarding. Используете другой стек? Сообщите об этом при подаче заявки.

Подробнее

Прочитать Detection & Limitations

Часто задаваемые вопросы

Нужно ли клиентам подписывать свои requests?

Нет. Signed requests дают самое сильное evidence, но Proof of Actor также фиксирует declarations и inferences, каждое с пометкой своего basis, и сообщает Unknown, когда данных недостаточно.

Означает ли valid signature, что client разрешено действовать?

Нет. Он показывает, что request был подписан key, связанным с опубликованным identifier. Что может делать этот operator, решают ваша authorization и policy.

Заменяет ли это API keys или OAuth?

Нет. Credentials по-прежнему управляют доступом. Proof of Actor добавляет, кто или что вызывает, чтобы вы могли применять более точные policies поверх этого.

Можем ли мы задать разные правила для каждого endpoint?

Да. Политики пишутся для каждого route, поэтому конечные точки только для чтения и записи с высоким влиянием можно обрабатывать по-разному.

Сколько это стоит?

Отобранные founding developer teams могут получить до 12 месяцев бесплатно в пределах согласованных лимитов использования.

Знайте, кто вызывает ваш API.

Присоединяйтесь к founding developer program Proof of Actor.

Получить ранний доступЦентр разработчиков

Предпочитаете сначала поговорить? Свяжитесь с основателями