ИДЕНТИФИКАЦИЯ AI-АГЕНТОВ

Идентификация AI-агентов для API

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

Получить ранний доступ Изучить, как это работает

Автор Toshendra SharmaОснователь и CEO, AgentCredia · Updated November 13, 2026

Ваш API знает ключ. Он не знает актора.

Каждый API request приходит с некоторым доказательством того, кто за него платит: API key, OAuth token, session. Это доказательство хорошо отвечает на один вопрос. Оно говорит, какая учетная запись несет ответственность за вызов. Но оно не говорит, что именно делает этот вызов прямо сейчас.

Один и тот же API key может использоваться разработчиком, который тестирует в терминале, backend job, который запускается по расписанию, человеком, работающим через AI assistant, и автономным агентом, которому передали ключ и поручили завершить задачу. Это очень разные акторы. У них разный ритм, разные режимы отказа и разные профили риска. Если обращаться со всеми одинаково, вы либо слишком жестко ограничите законную автоматизацию, на которую полагаются ваши клиенты, либо недостаточно защитите те части вашего API, которые ни в коем случае не должны управляться unattended agent.

Идентификация AI-агентов для API закрывает этот разрыв. Вместо того чтобы выводить все только по ключу, вы получаете классификацию актора за каждым запросом вместе со свидетельствами, которые ее подтверждают. Именно это и создано для поставки Proof of Actor, а вариант использования для APIs показывает, как команды API применяют это маршрут за маршрутом.

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

Автоматизированный трафик к API не нов. Скрипты, интеграции и crawlers всегда были частью картины. Изменилась природа автоматизации. AI agents могут читать документацию, объединять вызовы в цепочки, творчески повторять попытки и действовать от имени людей, которые не следят за каждым шагом. Многие из них полезны и желанны. Некоторые сделаны плохо. Несколько - враждебны.

Без контекста актора команды API обычно возвращаются к грубым инструментам:

Rate limits по ключу, которые одинаково замедляют хороших и плохих агентов.
Правила по user-agent, которые ломаются, как только клиент меняет заголовок.
Сплошные блокировки, которые заставляют законную автоматизацию скрейпить ваше web app вместо этого.

Контекст актора позволяет реагировать точнее. Подписанный агент от известного вам оператора может получить более высокий лимит на read routes. Неизвестному вызывающему на write route можно запросить более сильные credentials. Человек, использующий AI assistant, может сохранять обычный опыт. Смысл не в том, чтобы останавливать агентов. Смысл в том, чтобы дать каждому типу вызывающего правильный путь. О том, что может и чего не может сообщить подписанный request, читайте что доказывают подписанные запросы AI-агентов.

Как работает идентификация AI-агентов в Proof of Actor

Proof of Actor использует один и тот же flow, ориентированный на evidence first, для каждого запроса. Полный разбор есть в How It Works; здесь короткая версия для команд API.

1. Signals из вашей интеграции

Ваша интеграция передает Proof of Actor сигналы, доступные в этом контексте. Для API это обычно означает контекст запроса, такой как заголовки и детали протокола, любые криптографические request signatures, которые предоставляет клиент, и любые декларации о себе, которые делает клиент. Каждый signal помечается источником, откуда он пришел.

2. Классификация с основанием

Signals проверяются и объединяются в один из четырех публичных классов:

Human: наблюдаемые signals указывают на взаимодействие, управляемое человеком.
Human + AI: использование AI было заявлено или обнаружено интеграцией, которая может это наблюдать.
Agent: автоматизированный трафик или трафик агентного происхождения, подтвержденный проверяемой идентичностью или аккуратно квалифицированным выводом.
Unknown: свидетельств недостаточно для надежного определения.

У каждого результата также есть свое основание: Verified, Declared, Inferred или Unknown. Это та часть, которую команды API ценят больше всего. Запрос, чья HTTP message signature, как определено в RFC 9421, подтверждается опубликованным key, помечается как Verified. Клиент, который просто называет себя агентом, помечается как Declared. Шаблон, который выглядит автоматизированным, помечается как Inferred. Вам не нужно гадать, основан ли результат на криптографии или на heuristic. Основание свидетельств входит в ответ.

3. Результат, на который может опираться ваш код

Результат возвращается в ваше приложение вместе с классом, основанием и читаемым summary свидетельств. Ваш код сам решает, что с этим делать. В режиме наблюдения вы просто записываете его. Когда будете готовы, вы направляете поток на его основе.

Что получает ваша команда: Detect, Understand, Route

Proof of Actor - это один продукт с тремя возможностями.

Detect

Собирайте signals актора, которые может видеть ваш API, и отделяйте проверенные утверждения от поведенческих выводов. Подписанные запросы агентов, заявленные клиенты, сигналы автоматизации и результаты Unknown остаются раздельными, так что ничто незаметно не сливается в один score.

Understand

Смотрите, какие акторы вызывают какие routes, как это меняется со временем и какие свидетельства стоят за каждой классификацией. Доля Unknown остается видимой, и это точно показывает, где заканчивается ваше покрытие и где помог бы более сильный signal.

Route

Пишите политики по route и по уровню риска: allow, adapt, challenge, review или rate-limit. Оставляйте структурированный и щедрый путь для проверенных агентов на read-only endpoints. Запрашивайте более сильные credentials для операций с высоким влиянием. Задавайте явный fallback для Unknown и для timeouts, чтобы ваш API вел себя предсказуемо при любых обстоятельствах. Вы сами решаете, как каждая политика должна fail - open или closed - исходя из цены ошибки на этом route.

Свидетельства идентичности, credentials и авторизация - это три разные вещи

Самая частая ошибка в agent-aware API design - свести три отдельных вопроса к одному. Proof of Actor держит их раздельно, и ваш дизайн должен делать то же самое.

Identity evidence: какой тип актора вызывает, и что это доказывает? Это и дает идентификация AI-агентов. Проверенная подпись связывает запрос с key и его опубликованным operator identifier. Рабочая группа IETF Web Bot Auth working group получила мандат на стандартизацию этого вида криптографической аутентификации для автоматизированных clients, и ее scope охватывает аутентификацию агента, а не конечного пользователя.
Credentials: какая учетная запись несет ответственность за этот вызов? Это ваш API key, token или session, выданные и управляемые вами.
Authorization: разрешено ли этому вызывающему делать именно это конкретное действие? Это ваша модель разрешений.

Проверенный агент не становится автоматически authorized agent. Действительная подпись не доказывает, что человек делегировал полномочия агенту, и она не делает запрашиваемое действие безопасным. Proof of Actor дает вам надежный контекст для первого вопроса и оставляет второй и третий ровно там, где им место: в вашем приложении. Подробнее читайте про agent authorization и о том, что evidence может и не может установить, на Detection & Limitations.

Unknown - это функция, а не сбой

Подписание запросов необязательно, а неподписанный client может описать себя как угодно. Система, которая заставляет каждый request стать Human или Agent, иногда будет уверенно ошибаться, и вы не будете знать когда.

Proof of Actor сообщает Unknown, когда свидетельств недостаточно для определения. Unknown никогда не превращается в Human и по умолчанию никогда не считается вредоносным. Ваша политика определяет, что означает Unknown для каждого route: разрешить на публичных read, оставить существующие проверки для изменений учетной записи, отправлять на review там, где ставки высоки. Именно благодаря тому, что Unknown остается видимым, остальные классификации заслуживают доверия. Руководство по обработке неизвестного трафика показывает, как спроектировать это правильно.

Где идентификация AI-агентов вписывается в ваш stack

Proof of Actor работает рядом с вашим существующим gateway, authentication и rate limiting. Он ничего из этого не заменяет. Типичные варианты размещения включают:

Server-side middleware перед обработчиками маршрутов, чтобы каждый request оценивался до запуска business logic.
На edge, чтобы signals оценивались до того, как requests достигнут origin.
Общую HTTP integration, чтобы любой stack мог отправлять контекст запроса и получать результат с его основанием.

Интеграции внедряются совместно с каждой командой founding team во время onboarding, поэтому путь подстраивается под вашу архитектуру, а не наоборот. В developer hub показаны доступные сегодня пути интеграции. Если вы создаете tools для агентов, MCP Servers use case описывает конкретные patterns для tool calls.

Начните в режиме наблюдения

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

Именно так вы внедряете идентификацию AI-агентов, не удивляя клиентов и не ломая интеграции, от которых они зависят. Руководство по безопасному поэтапному внедрению actor-aware policies проводит через этот процесс шаг за шагом.

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

Proof of Actor находится в private beta с небольшой группой founding development teams. Выбранные команды могут получить до 12 месяцев бесплатного доступа в рамках лимитов использования, согласованных во время onboarding, а также прямую поддержку интеграции от наших инженеров и реальное влияние на то, что мы создадим дальше.

Если вы управляете API и хотите знать, кто на самом деле к нему обращается, подайте заявку на ранний доступ. Расскажите нам о вашем API, о маршрутах, которые для вас важнее всего, и о решениях, которые вы принимали бы иначе при наличии контекста актора. Мы покажем, как Proof of Actor подходит вам.

Источники

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

ДЛЯ РАЗРАБОТЧИКОВ

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

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

Чем идентификация AI-агентов отличается от аутентификации по API key?

API key говорит, какая учетная запись отправила запрос. Идентификация AI-агента говорит, какой тип актора стоит за запросом и какие свидетельства подтверждают этот вывод. Вам нужны оба подхода, и они отвечают на разные вопросы.

Может ли Proof of Actor определить каждого AI-агента, который вызывает мой API?

Proof of Actor классифицирует каждый видимый ему запрос как Human, Human + AI, Agent или Unknown и указывает основание для каждого результата. Когда свидетельств недостаточно, результатом будет Unknown, а не догадка.

Означает ли идентификация агента, что ему разрешено действовать?

Нет. Идентификация и авторизация - это разные вещи. Proof of Actor дает вашему приложению контекст о вызывающем, а ваши собственные правила авторизации решают, что этот вызывающий может делать.

Будет ли Proof of Actor блокировать запросы к моему API?

Не если только вы сами этого не решите. Любая интеграция начинается в режиме наблюдения, а принудительное применение происходит только через политики, которые ваша команда пишет и включает.

Как получить доступ?

Proof of Actor находится в private beta. Подайте заявку на ранний доступ, и выбранные команды founding developer program могут получить до 12 месяцев бесплатно в рамках согласованных лимитов использования.

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

Private beta для небольшой группы founding developers.

Получить ранний доступ Просмотреть цены

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