Перейти к основному содержимому
КАК ЭТО РАБОТАЕТ

Как работает Proof of Actor.

Путь с приоритетом данных от входящего взаимодействия к решению приложения.

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

От взаимодействия к решению

  1. 01Запрос или событие приложенияПросмотр страницы, вызов API, вызов инструмента MCP или действие внутри приложения.
  2. 02Сигналы из поддерживаемой интеграцииТолько то, что эта integration может наблюдать в этом context.
  3. 03Нормализация и классификация evidenceСигналы проверяются, помечаются по основанию и объединяются.
  4. 04Результат по актору с основанием и неопределенностьюHuman, Human + AI, Agent или Unknown, а также на чем это основано.
  5. 05Dashboard и аналитикаTrends, routes и evidence для review вашей team.
  6. 06Собственное решение вашего applicationТолько наблюдать или применить выбранную вами policy.
ДЛЯ РАЗРАБОТЧИКОВ

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
Насколько сильны evidence: verified, declared, inferred или unknown.
evidence
Signals, стоящие за result, чтобы ваша team видела, почему.

Начните в observation mode: записывайте results рядом с вашими logs и ничего не меняйте, пока не выберете policy. Прочитать guide по интеграции Node.js

Режим observation включен по умолчанию

Установка Proof of Actor не блокирует и не изменяет ни один запрос. Результаты записываются, чтобы ваша команда могла сравнивать их с фактическими результатами работы приложения, проверять ложные срабатывания и решать, уместна ли какая-либо политика.

Типы доказательств

Доступные доказательства зависят от integration и context. Проверки для каждого workflow согласуются с командой во время onboarding, а внутренние details signal остаются приватными, чтобы их было сложнее имитировать.

  • Подписи запросов

    Криптографические подписи от автоматизированных клиентов, которые публикуют свои ключи.

  • Декларации

    Клиент, который называет себя агентом, или раскрытие использования помощи ИИ внутри вашего приложения.

  • Сигналы взаимодействия

    Сигналы от одобренного браузерного сборщика на страницах, где он работает.

  • Контекст запроса

    Заголовки и детали протокола, доступные серверной интеграции.

Идентичность agent не является авторизацией

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

Это не показывает, кто дал указание agent, делегировал ли человек ему разрешение, какая юридическая сущность стоит за ним, и безопасно ли действие. Это отдельные вопросы, на которые ваше приложение отвечает с помощью собственной authentication, authorization и policy.

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

Как вписываются routing decisions

Ваше application вызывает Proof of Actor, получает результат и применяет свои собственные правила. Вы выбираете для каждого route и каждого risk tier, будет ли integration fail open (request проходит так, как если бы Proof of Actor не было) или fail closed (применяется ваша существующая более строгая проверка).

  • Тайм-аут API

    Если результат не доступен вовремя, ваша интеграция использует вариант перехода, который вы выбрали для этого маршрута. Тайм-аут никогда не становится результатом Human.

  • Отсутствует telemetry

    Если браузерный сборщик не запускался или сигнал отсутствует, результат это отражает. Отсутствующие доказательства ограничивают то, что можно утверждать; это не считается подозрительным.

  • Неизвестные классификации

    Unknown - это нормальный outcome. Ваша policy определяет, что Unknown означает для каждого route, например: allow public pages, сохранять existing checks для account changes.

  • Устаревшие доказательства

    У evidence есть время и scope. Результат из более ранней части session не следует использовать повторно для более позднего, более чувствительного действия без свежей проверки.

Beta integration workflow

  1. 01Подать заявкуРасскажите о приложении и о взаимодействии, которое вы хотите понять.
  2. 02ОбластьСогласуйте интеграцию, маршруты, лимиты использования и обработку данных.
  3. 03Интегрировать в режиме наблюденияБез изменений в том, как ваше app отвечает.
  4. 04ПроверитьСравните результаты с известной вам эталонной реальностью: покрытие, долю Unknown, ложноположительные срабатывания, задержку.
  5. 05РешатьВключайте policy только там, где evidence это подтверждает.

Что мы измеряем с founding teams

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

Начните в observation mode.

Подайте заявку на участие в founding developer program.

Подать заявку на ранний доступПосмотреть Detection & Limits

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