AI-агенты: делегирование, уровни доступа и лимиты крипто-трат – разбор

Ключевые выводы

• Делегирование AI-агенту — это процесс предоставления автономному программному агенту ограниченных полномочий для действий от имени человека, организации, приложения или блокчейн-аккаунта.
• Делегирование отличается от передачи агенту пароля, приватного ключа или безграничного доступа администратора. Грамотно реализованное делегирование дает только необходимый минимум полномочий для конкретной задачи.
• Права доступа определяют, какие действия агент может выполнять, например: чтение файлов, отправку платежей, свап токенов или создание событий в календаре.
• Scopes (области) определяют границы этих прав, включая, с какими аккаунтами, приложениями, активами, получателями, сетями и данными агент может взаимодействовать.
• Лимиты трат ограничивают финансовую ценность, которой агент может распоряжаться: по каждой транзакции, в сутки, за сессию, по конкретному токену или с учетом накопления.
• Делегированная авторизация реализуется offchain с помощью OAuth-токенов доступа и движков политик API или onchain через смарт-аккаунты, session-ключи, модули допусков (allowance modules) и контракты разрешений.

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

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

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

Зачем AI-агентам нужна делегированная авторизация

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

Если требовать ручного подтверждения каждой оплаты на $20, то автоматизация теряет смысл. А если агенту выдать полный доступ к банковскому счету компании — это создаёт высокий риск. Делегирование — компромисс между этими крайностями.

Компания может разрешить агенту оплачивать только одобренных поставщиков ПО, используя отдельный счет, с лимитом $100 за транзакцию и $1,000 в месяц. Всё, что выходит за эти рамки, требует одобрения сотрудника. Такой подход основан на принципе минимальных прав (least privilege): любой пользователь или процесс должны получать только необходимые ресурсы и полномочия для своих задач. Делегирование для AI — не про расширение могущества агентов, а про то, чтобы сделать их автономию максимально безопасной.

Ключевые участники системы делегирования AI

Принципал

Агент

Ресурс или аккаунт

Слой авторизации

Исполнитель

Аутентификация против авторизации

Аутентификация и авторизация — понятия связанные, но разные. Аутентификация отвечает на вопрос: кто делает запрос? Авторизация: что этому идентифицированному субъекту разрешено делать?

Агент может подтвердить свою личность через API credentials, криптографическую подпись, passkey или адрес кошелька. Однако это не даёт ему право пользоваться всеми функциями. Безопасная система сначала аутентифицирует агента, а затем сопоставляет запрошенное действие с делегированными разрешениями.

Например, агент доказывает владение session-ключом. Кошелёк проверяет — разрешён ли этому ключу переводить USDC, одобрен ли получатель, не превышен ли дневной лимит, и не истекла ли разрешённая сессия. Только после всех проверок выполняется действие.

Offchain-делегирование AI-агентов

Большинство AI-агентов сегодня взаимодействуют преимущественно с web2-сервисами, а не блокчейн-аккаунтами. Offchain-делегирование обычно строится на токенах доступа OAuth, API-ключах с ограниченными ролями, ролевой модели управления доступом (RBAC), облачных ID-системах, сервисах управления секретами и шлюзах политик.

Агент, подключающийся к email- или календарному сервису, может получить OAuth-токен для чтения данных без раскрытия пароля пользователя. Корпоративный агент может действовать через сервисный аккаунт с правами только на одну базу данных без доступа к админ-панели. MCP-авторизация строится по этой модели, где защищённые MCP-серверы считаются OAuth-ресурсами, а AI-агенты — приложениями, действующими от имени владельца данных.

Onchain-делегирование AI-агентов

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

Владелец ключа обычно получает полный контроль над всем аккаунтом. Лимит, прописанный только в промпте агента — не безопасность, ведь агент или злоумышленник легко его проигнорируют. Ончейн-делегирование внедряет ограничения непосредственно в смарт-контракт или логику кошелька.

Allowance-модули и права на траты

Некоторые кошельки уже поддерживают контроль трат с упором на AI-агентов. Документация Safe описывает AI-трежери-сценарий, где модуль allowance устанавливает для агента лимит на конкретный токен — разово или с регулярным обновлением (например, ежедневный лимит USDC). Safe предлагает различные варианты защиты с подтверждением человеком, совместной авторизацией агентов и лимитами трат для AI.

Coinbase Spend Permissions позволяют назначенному агенту тратить токены с определённого смарт-аккаунта в рамках ограничений по токену, сумме и периоду. В документации такие разрешения рекомендуются для агентских платежей и алгоритмической торговли.

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

Делегирование против передачи приватного ключа

Передача приватного ключа агенту передаёт власть. Делегирование — только определённые полномочия.

Выделенный кошелек с низким балансом безопаснее, чем раздача главного ключа, но правильно настроенный смарт-аккаунт даёт ещё большую защиту — он может применять ограничения даже при значительном балансе.

Делегирование против токен-аппрувалов

ERC-20 approval дает пользователю право переводить токены в рамках allowance. Это базовая форма делегирования, но часто она слишком ограничена для сложных агентов. Approval не всегда ограничивает получателя, используемый протокол, слippage, направление сделки, временные рамки, общий экспозицию или назначение транзакции.

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

Типовые сценарии использования делегирования AI-агентов

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

Автоматизированная торговля – торговый агент размещает ордера, перебалансирует портфель или реализует стратегию в рамках выбранных рынков, разрешённых токенов, максимального размера позиций, кредитного плеча, slippage и дневных убытков.

Управление трежери – AI-агент может мониторить балансы, переводить оборотные средства, платить вендорам или размещать стейблкоины. Самый безопасный вариант — выделенный операционный allowance, а не полный контроль над трежери.

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

Операции DAO – DAO может делегировать агенту распределение грантов, выплаты контрибьюторам, сбор доходов протокола или выполнение утверждённых решений управления. Агент работает через Safe или другой смарт-аккаунт с allowance для токенов и oversight держателей ключей.

Основные риски для безопасности

• Prompt Injection – Внешний документ, сайт, сообщение или API-ответ могут содержать специальный текст для манипуляции агентом. Пример: вредоносный инвойс приказывает агенту проигнорировать задачу и перевести деньги другому получателю. Жёсткие авторизационные контроли предотвращают ущерб даже при выполнении вредоносной команды (перевод не пройдёт, если адрес вне allowlist).
• Чрезмерные права – Разработчики могут запрашивать чрезмерно широкий доступ для удобства, что опасно в случае компрометации агента или токена.
• Кража учётных данных – Атакующий, укравший OAuth-токен, API-ключ, session-ключ или ключ кошелька агента, может отправлять легитимные запросы. Используйте короткоживущие токены, защищённое хранение, revocation и лимиты транзакций для минимизации ущерба. Текущие рекомендации MCP предполагают короткие жизненные циклы токенов.
• Атаки Confused-Deputy – Доверенный агент может быть введён в заблуждение, чтобы использовать свои полномочия в пользу злоумышленника. При этом сам агент не скомпрометирован, просто не осознал неавторизованный контекст. Ограничьте получателей, проверяйте источник, используйте отдельные креденшелы для задач и подтверждайте критичные операции.
• Косвенные траты – Агент может формально не нарушать лимит, но создавать бóльшие финансовые риски косвенно (например, подписывая вредоносный контракт или открывая рискованную позицию). Политики делегирования должны охватывать approvals, финансовые обязательства и будущие риски, а не только текущие переводы.
• Эскалация привилегий – Агент может попытаться установить модуль, сменить владельца, обновить политику или создать новый credential с расширенными правами. Администрирование и управление разрешениями обычно должны быть исключены из стандартных параметров агента.
• Небезопасное ределегирование – Суб-агенты могут получать размытые или избыточные права, усложняя аудит и отзыв полномочий.
• Устаревшие права – Агент может сохранить доступ после завершения проекта, ухода сотрудника или прекращения партнёрства. Используйте автоистечение и периодический аудит разрешений.
• Сложности совместимости между сетями – Права на одной цепочке не переносятся автоматически на другую. Бриджи, обёрнутые активы и межчейновые сообщения могут добавлять новые риски и контракты, не указанные в изначальном делегировании.
• Оракл и ценовой риск – Лимит, выраженный в валюте, зависит от внешних источников цен. Если агенту разрешено тратить эквивалент $1,000, а источник цен устарел или подвержен манипуляциям — итоговый перевод может существенно превысить лимит. Лимиты в токенах и в фиатных деньгах могут вести себя по-разному.

Существуют ли стандартизированные права AI-агента?

Offchain-системы в основном используют ограниченный доступ по типу OAuth; в MCP OAuth применяется для связки агент-инструмент. Для Ethereum существуют инициативы ERC-4337 (account abstraction), EIP-7702, ERC-7710, ERC-7715, поддерживающие программируемую валидацию, делегирование возможностей, запросы прав от кошельков, ограниченное выполнение транзакций. Кошельки и инфраструктурные провайдеры также реализуют свои allowance-модули, permission-системы, caveat-политики и аккаунты агентов.

Будущее видится не как создание одного формата разрешений для всего, а как экспансия множества взаимосвязанных стандартов, позволяющих агентам, кошелькам, приложениям и серверам авторизации обмениваться машиночитаемыми (machine-readable) мандатами.

Что такое делегирование AI-агента в одном предложении?

Заключение

AI-агенты становятся полезными тогда, когда способны совершать действия — а это возможно только при наличии полномочий. Самый безопасный вариант — не выдавать агентам полный доступ и не надеяться на их благоразумие, а сразу внедрять чёткие границы в системы их использования. Permissions определяют, что может делать агент; scopes — где и на каких условиях; лимиты трат — максимальную стоимость риска; истечение срока, отзыв, аудит и ручное подтверждение — дополнительные рубежи контроля.

Эти принципы актуальны как для классического ПО, так и для блокчейн-инфраструктуры: OAuth-токены ограничивают доступ к web2-сервисам, а смарт-аккаунты, session-ключи, контракты делегирования и allowance-модули контролируют исполнения onchain. По мере развития агентских платежей, автотрейдинга, AI-трежери и B2B-машинной экономики делегирование станет базовой инфраструктурой. Пользователи должны иметь инструменты для передачи агентам достаточных, но не катастрофических полномочий.

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

Зарегистрируйтесь на Phemex сейчас