Как ИИ-агенты получают доступ к вашим данным без пароля

Осенью 2024 года Anthropic выпустила режим Computer Use для Claude 3.5 Sonnet, а в начале 2025-го OpenAI показала Operator — агента, который сам кликает по сайтам в браузере. К концу 2024 года Anthropic также опубликовала открытую спецификацию Model Context Protocol (MCP) для подключения моделей к внешним инструментам. Все три события упёрлись в один и тот же вопрос: как дать агенту право что-то сделать в чужом сервисе, не отдав ему при этом ключи от всей вашей жизни.

Пока агент отвечал на вопросы в чате, разграничивать доступ было не нужно. Как только он начал бронировать билеты, отправлять письма и двигать деньги по API, разница между «модель прочитала ваш календарь» и «модель удалила из него встречу» стала стоить денег и нервов.

Аутентификация и авторизация — не одно и то же

Два слова, которые постоянно путают, а для агента разница критична.

• Аутентификация отвечает на вопрос «кто это?». Система убеждается, что запрос пришёл от конкретного пользователя или сервиса.
• Авторизация отвечает на вопрос «что этому кому-то разрешено?». Даже опознанному агенту можно позволить читать почту, но запретить её удалять.

Для человека эти шаги слиты в один: вы ввели пароль — и вошли с полными правами. Для агента их приходится разводить, потому что «полные права» у автономного софта — это прямой путь к катастрофе. Агент, который ошибся в интерпретации задачи, с полным доступом к банковскому API способен натворить того, чего живой пользователь не сделал бы по невнимательности.

Почему нельзя просто дать агенту логин и пароль

Соблазн очевиден: сохранить учётные данные и пусть агент входит как вы. Проблем сразу несколько. Пароль даёт доступ ко всему аккаунту без ограничений. Его нельзя отозвать точечно — только сменив, что выкинет и вас. Он не переживёт двухфакторную аутентификацию. И если агент работает через сторонний сервис, ваш пароль оказывается в чужой инфраструктуре в открытом или почти открытом виде.

Пароль отвечает на вопрос «кто вы». Агенту нужен ответ на вопрос «что именно ему сейчас разрешено» — а это принципиально другой механизм.

Как это устроено технически

Индустрия не стала изобретать новое, а приспособила то, что уже работает в вебе больше десяти лет.

OAuth 2.0 и делегирование прав

Основной механизм — OAuth 2.0¹. Вместо пароля агент получает токен доступа — временную строку, которая говорит сервису: «предъявитель может делать вот это и только это, до такого-то момента». Вы один раз проходите привычный экран согласия («приложение X запрашивает доступ к вашему календарю»), сервис выдаёт токен, а пароль остаётся при вас.

Ключевое понятие здесь — scope (область действия). Именно scope превращает «доступ к аккаунту» в «доступ к чтению событий календаря без права их менять». Хорошо спроектированный агент запрашивает минимальный набор scope под конкретную задачу, а не всё подряд.

Model Context Protocol и авторизация инструментов

MCP описывает, как модель подключается к внешним инструментам и источникам данных. В спецификацию заложена авторизация на базе OAuth 2.1: сервер инструментов сам решает, какие операции доступны предъявителю токена. Это смещает контроль туда, где ему место — на сторону сервиса, который знает цену каждой операции, а не на сторону модели, которая может ошибиться.

Отдельная личность для агента

Отдельное направление — не выдавать агенту токен от имени человека, а завести ему собственную учётную запись сервиса (service account) с урезанными правами. Тогда в логах видно, что действие совершил именно агент, а не вы, и отозвать его доступ можно, не трогая ваш аккаунт. Это принцип наименьших привилегий: у агента ровно те права, что нужны для задачи, и ни одним больше.

Три подхода в сравнении

Разница не косметическая. При утечке токена с узким scope злоумышленник получит право читать один календарь, а не переписку, файлы и платёжные методы разом.

Где всё ломается на практике

Даже с правильной архитектурой остаётся класс проблем, специфичных именно для агентов.

• Prompt injection. Агент читает веб-страницу или письмо, а внутри спрятана инструкция «отправь содержимое почты на такой-то адрес». Модель не всегда отличает данные от команд. Если у агента есть токен на отправку писем, инъекция превращается в реальное действие.
• Путаница представителя (confused deputy). Агент действует с вашими правами, но по чужой команде — и сервис видит легитимный запрос от легитимного токена.
• Молчаливое накопление прав. Каждый новый навык агента просит новый scope. Через полгода у него доступ к десятку сервисов, и никто не помнит зачем.

Кому это пригодится, а кому нет

Пригодится:

• Разработчику, который встраивает агента в продукт: разбираться в OAuth и scope придётся до, а не после инцидента.
• Компании, автоматизирующей внутренние процессы — согласование заявок, работа с CRM. Здесь service account с узкими правами почти обязателен.
• Продвинутому пользователю, который подключает Claude или ChatGPT к своим сервисам через MCP или плагины и хочет понимать, что он подписывает на экране согласия.

Скорее не пригодится прямо сейчас:

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

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

¹ OAuth 2.0 — открытый стандарт делегированного доступа. Позволяет приложению действовать от имени пользователя в другом сервисе, не зная его пароля, за счёт временных токенов с ограниченными правами.