ПОЛИТИКИ ДОСТУПА ДЛЯ АГЕНТОВ

Маршрутизируйте AI-агентов с помощью контролируемых вами политик

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

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

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

Одной политики для всех уже недостаточно

Большинство приложений проектировались вокруг одного типа пользователя: человека, который кликает по интерфейсу и вошел в учетную запись. Контроль доступа строился на этом предположении. Если сессия действительна, запрос проходит. Если он выглядит автоматизированным, появляется CAPTCHA или блокировка.

Эта модель ломается. Сегодня одно и то же приложение обслуживает людей, людей, работающих с AI-ассистентами, и автономных агентов, действующих от чьего-то имени. Некоторые агенты - это собственные интеграции клиентов. Некоторые - AI-ассистенты, запрашивающие документацию. Некоторые - краулеры. А некоторые пытаются злоупотребить вашим продуктом. Одно правило да или нет не может одинаково хорошо обслужить их всех.

Маршрутизация AI-агентов и политики доступа заменяют это одно правило набором осознанных решений: какие акторы получают какой опыт, на каких маршрутах и при каких условиях. Proof of Actor дает вашему приложению доказательства для принятия этих решений и оставляет сами решения в ваших руках. О принципах проектирования этого подхода читайте как проектировать политики приложения для людей и AI-агентов, а в кейсе для SaaS-приложений показано, как политики соотносятся с реальными продуктовыми сценариями.

Как выглядит хорошая политика для агентов

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

Маршруты каталога только для чтения: разрешать проверенных агентов и отдавать структурированный ответ; разрешать declared-агентов с обычным rate limit.
Действия, меняющие учетную запись: сохранять вашу существующую повторную аутентификацию для всех; добавлять проверку, когда актор Unknown и действие имеет высокий эффект.
Отправка обращений в поддержку: принимать раскрытый контент, созданный с помощью AI, и помечать его для маршрутизации.
Регистрация: сохранять существующие проверки; никогда не принимать решение только на основании inferred-результата по актору.

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

Пять вариантов ответа

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

Разрешать

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

Адаптировать

Изменить опыт под актора. Отдать проверенному агенту структурированный ответ API или версию страницы в Markdown вместо интерфейса, рассчитанного на человека. Этот паттерн рассматривается в руководстве как отдавать AI-агентам структурированный контент.

Оспаривать

Попросить что-то более сильное: свежий вход в систему, дополнительный credential, подтверждение от владельца учетной записи. Используйте оспаривание на маршрутах, где цена неверного решения высока.

Отправлять на проверку

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

Ограничивать

Применить лимит по rate или объему, настроенный под актора и маршрут, чтобы автоматизированные вызывающие стороны не могли перегрузить рабочий процесс, рассчитанный на людей.

Почему robots.txt - это не политика доступа

Многие команды начинают с robots.txt, и для краулеров это разумный первый сигнал. Но это не политика доступа для агентов. Операторы краулеров документируют различное поведение для разных user-agent: Anthropic указывает, что его боты соблюдают директивы robots.txt (документация краулера Anthropic), а OpenAI отмечает, что для ChatGPT-User, который действует, когда пользователь задает ChatGPT вопрос, правила robots.txt могут не применяться, потому что действие инициировано пользователем (документация краулера OpenAI). Кроме того, robots.txt ничего не говорит об API, инструментах MCP или рабочих процессах с входом в систему.

Политика доступа должна выполняться там, где обрабатывается запрос, читать доказательства, такие как подпись, проверенная по RFC 9421, и выбирать ответ для каждого маршрута. Для MCP server спецификация авторизации MCP определяет, как клиенты получают access tokens over HTTP; политики акторов добавляют поверх этого контекст, а не заменяют его.

Как Proof of Actor подает данные в ваши политики

Каждый запрос, который оценивает ваша интеграция, дает результат по актору из четырех частей, которые может читать ваша политика:

Класс: Human, Human + AI, Agent или Unknown.
Основа: verified, declared, inferred или unknown, чтобы ваша политика могла по-разному относиться к проверенной подписи и к самодекларированному имени клиента.
Сводка по доказательствам: понятное описание того, на чем основан результат, полезное для журналирования и проверки.
Контекст: какая интеграция и какой маршрут породили результат.

Поскольку основа явно указана, ваши политики могут быть точными. "Разрешать agents" превращается в "разрешать verified-agents на маршрутах чтения, ограничивать declared-agents по rate-limit, применять fallback для Unknown ко всему остальному". Полный поток от запроса до решения описан на странице Как это работает.

Fallback - часть политики

Политика хороша лишь настолько, насколько хорошо она ведет себя, когда доказательств нет. Proof of Actor делает такие случаи явными, а не скрывает их.

Unknown: доказательства не позволили сделать вывод. Ваша политика определяет, что означает Unknown на каждом маршруте. Он никогда не превращается в Human и по умолчанию не считается вредоносным.
Timeout: результат не успел прийти вовремя. Ваша интеграция применяет выбранный вами fallback для этого маршрута.
Отсутствующие сигналы: сборщик не запустился или заголовок отсутствовал. Результат это отражает, и ваша политика учитывает это соответствующим образом.

Для каждого маршрута вы решаете, использовать fail open или fail closed. Fail open означает, что запрос проходит так же, как и без Proof of Actor; fail closed означает, что применяется ваша существующая более строгая проверка. Для низкорисковых маршрутов обычно выбирают fail open. Для чувствительных действий обычно выбирают fail closed. Вы задаете это по уровню риска, а не глобально.

Разделяйте идентичность, учетные данные и авторизацию

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

Доказательство идентичности отвечает на вопрос, какой тип актора вызывает запрос и что это подтверждает. Это дает Proof of Actor.
Учетные данные отвечают на вопрос, какая учетная запись несет ответственность. Это дает ваша сессия, token или API key.
Авторизация отвечает на вопрос, может ли этот вызывающий субъект выполнить это действие. Это дает ваша модель прав.

Проверенная идентичность агента не означает, что агент авторизован, что человек передал ему полномочия или что его действие безопасно. Используйте результаты по актору для маршрутизации и добавления контекста. Используйте вашу модель авторизации для предоставления прав. Страница Detection & Limitations точно объясняет, что может установить каждый вид доказательств.

Внедряйте без поломок

Самый безопасный способ внедрять политики доступа для агентов - делать это поэтапно.

Наблюдать. Установите Proof of Actor в режиме наблюдения. Для пользователей ничего не меняется; результаты сохраняются.
Понимать. Посмотрите, какие акторы используют какие маршруты, каков процент Unknown на каждом из них и есть ли результаты, которые расходятся с тем, что вы уже знаете.
Предпросмотр. Запустите политику в режиме preview, записывая, что она бы сделала, без применения enforcement.
Включать точечно. Активируйте политику на одном маршруте, где доказательства ее явно поддерживают. Наблюдайте за результатами.
Расширять. Распространяйте на большее число маршрутов по мере роста уверенности.

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

Что получает ваша команда

С Proof of Actor ваша команда получает одну интеграцию с тремя возможностями. Detect собирает сигналы по актору и отделяет проверенные утверждения от infererences. Understand показывает аналитику по акторам, тренды и доказательства, лежащие в основе каждого результата, при этом Unknown остается видимым. Route позволяет писать политики, описанные на этой странице, и применять их там, где вы решите. Во время private beta политики маршрутизации проектируются вместе с каждой founding-командой и выполняются в коде вашего приложения, так что вы сохраняете полный контроль.

Типичные ошибки в политике, которых стоит избегать

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

Блокировать каждого агента по умолчанию. Легитимные агенты тогда обходят вас, часто скрейпя интерфейс, созданный для людей, который защитить сложнее, чем структурированный путь.
Доверять объявленному имени. Клиент, который только называет себя, сделал утверждение, но не предоставил доказательство. Относитесь к нему так же, как к непроверенному вызывающему субъекту.
Использовать один fallback везде. Unknown на публичной странице цен и Unknown при смене пароля - это разные ситуации. Для каждого маршрута нужен свой ответ.
Принимать решение о людях на основании inference. Результаты по актору - это контекст для маршрутизации, а не вердикт о человеке. Оставляйте решения с последствиями вашим собственным средствам контроля и проверке.
Пропускать наблюдение. Если включать enforcement в первый же день, false positive вы обнаружите через жалобы клиентов. Сначала наблюдайте, потом включайте enforcement там, где доказательства ясны.

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

Начните с founding developer program

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

Если вы решаете, как ваше приложение должно обрабатывать AI-агентов, подайте заявку на ранний доступ. Расскажите, какие маршруты для вас важнее всего и какие решения вы хотите принимать, и мы поможем вам построить подходящие политики. Также вы можете посмотреть, как это применяется к API и MCP server.

Источники

Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
Overview of OpenAI crawlers, OpenAI.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
MCP authorization, modelcontextprotocol.io.

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

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-агента?

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

Применяет ли Proof of Actor политики автоматически?

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

Что происходит, если актор Unknown или проверка завершилась по тайм-ауту?

Для каждого маршрута вы задаете явный fallback, например разрешать публичное чтение и сохранять существующие проверки для изменений учетной записи. Unknown и тайм-ауты никогда не по умолчанию не превращаются в Human.

Стоит ли блокировать всех AI-агентов?

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

Могут ли политики принимать решения о людях?

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

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

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

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

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