Что означает авторизация агента
Авторизация агента - это решение о том, что AI-агенту разрешено делать: к каким route он может обращаться, какие данные он может читать, какие действия он может выполнять и в каком объеме. Это отличается от идентичности агента, которая касается установления того, какой именно агент, или чей это агент у оператора, отправляет запрос.
Эти два понятия легко смешать, потому что они часто приходят вместе. Подписанный запрос говорит, кто его отправил. Но он не говорит, должен ли этот отправитель иметь право изменять account, оформлять order или экспортировать данные. Идентичность - это evidence; authorization - это policy. В нашей статье о том, что доказывают подписанные AI agent requests и чего они не доказывают, подробно разбирается разница.
Почему это различие важно
Приложения уже разделяют аутентификацию и авторизацию для human users: вход в систему подтверждает, кто вы, а roles и permissions определяют, что вы можете делать. Для agent нужна та же развязка, но с дополнительной осторожностью:
- Идентичность может быть сильной, даже если разрешение отсутствует. Crawler с полностью действительной HTTP message signature не имеет по умолчанию права вызывать write endpoint.
- Разрешение может существовать без сильной идентичности. Agent, использующий API key клиента, authorized этим key, даже если ничто не указывает, какое именно agent software его держит.
- Человек, стоящий за agent, имеет значение. Когда agent действует от чьего-то имени, вопрос становится в том, дал ли этот человек ему authority (см. delegated authority).
Если объединить это в одну проверку, возникают два сбоя: либо вы блокируете законную автоматизацию, потому что у нее нет human login, либо доверяете хорошо идентифицированному agent действия, которые он не должен был выполнять.
Как обычно выражается авторизация
Большинство applications authorizes agents с помощью уже имеющихся механизмов:
- Credentials и scopes. API keys или OAuth 2.0 tokens со scopes, ограниченными тем, что нужно интеграции. MCP servers используют ту же модель: MCP authorization specification рассматривает защищенный server как OAuth 2.1 resource server.
- Policy на уровне route. Только для чтения routes открыты известным agent; для write routes требуется credential, привязанный к account.
- Уровни риска. Действия с низким влиянием разрешены широко, а действия с высоким влиянием требуют более сильных credentials, подтверждения или review.
- Rate limits и quotas на оператора, на credential или на route.
Evidence об идентичности agent используется в этих решениях как один из inputs. Практический подход см. в статье как проектировать политики на уровне приложения для людей и AI agents. Это позволяет относиться к верифицированному operator иначе, чем к анонимному client, но само разрешение по-прежнему задается вашей policy.
Распространенные заблуждения
- "Verified agent означает allowed." Verification относит request к определенному субъекту. Ваша policy по-прежнему решает, что именно этому субъекту разрешено делать.
- "Agents следует блокировать, пока они не доказали, что это human." Многие agents являются законными участниками. Лучше спросить, что должен быть вправе делать каждый тип actor, route за route.
- "Authorization можно вывести из behavior." Behavior может повысить или понизить confidence в том, какой type of actor присутствует. Но само по себе оно не должно давать permission.
Как Proof of Actor это рассматривает
Proof of Actor отвечает на вопрос evidence: какой type of actor присутствует, на каком основании (verified, declared, inferred or unknown), и что известно, а что нет. Он намеренно не принимает решение о permission. Результат Agent, даже verified, никогда не означает authorization. В Route ваше application сочетает результат actor с собственными credentials, scopes и risk tiers, чтобы allow, adapt, challenge, review или limit каждое interaction, начиная в observation mode, чтобы вы могли проверить outcomes до того, как что-то enforced.
Узнайте больше о том, как decisions встраиваются в ваше app, посмотрите use cases для APIs и MCP servers или подайте заявку на ранний доступ.
Источники
- RFC 6749: The OAuth 2.0 Authorization Framework: scoped tokens для clients
- MCP specification 2026-07-28: Authorization: OAuth-based authorization для MCP servers
- RFC 9421: HTTP Message Signatures: что устанавливает подписанный request