Релиз AWS TOLAP переносит контроль доступа к объектам внутрь инструментов ИИ-агентов

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

AWS Labs опубликовала TOLAP, или Tool-Object Level Access Protocol, как открытый слой безопасности для инструментов ИИ-агентов. Проект должен решать, какие данные могут покинуть инструмент после его вызова агентом: какие строки видны, какие поля скрываются или маскируются, какие конечные точки разрешены, сколько результатов допускается вернуть и соответствует ли запрошенное действие цели делегированных полномочий. Первый публичный релиз показывает, что безопасность агентов постепенно отходит от простого вопроса «может ли эта личность вызвать API?» к более сложному: «что именно способен раскрыть или изменить данный конкретный вызов?».

Для команд, которые строят агентов поверх баз данных, внутренних API, баз знаний, объектных хранилищ и MCP-серверов, это различие принципиально. Обычная проверка разрешений может подтвердить право на подключение, но при этом оставить инструменту возможность вернуть гораздо больше данных, чем требовалось пользователю или рабочему процессу. Предложение TOLAP — поместить политическую оболочку вокруг функции, которая фактически читает или изменяет данные, и применить правила до того, как результат попадёт в контекст агента.

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

Что именно выпустила AWS

AWS Open Source описывает TOLAP как слой контроля в точке источника данных. Репозиторий распространяется по лицензии Apache 2.0 и включает схему политик, библиотеки принудительного применения для .NET, Python и TypeScript, эталонный сервер политик, примеры, документацию и интеграции с популярными фреймворками агентов и инструментов.

Центральная модель является декларативной. Политика может указывать разрешённые объекты и действия, скрывать отдельные поля, маскировать значения, фильтровать строки, ограничивать префиксы хранилищ или методы API, задавать предел результата и добавлять сведения для аудита. В примерах используется набор данных в медицинском стиле: агент может получать записи пациентов, но не номера Social Security; адреса электронной почты могут возвращаться в виде хешей, а строки — ограничиваться определёнными регионами.

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

AWS сообщает, что SDK используют общую версионируемую схему политик и единый набор тестовых фикстур, поэтому реализации на разных языках должны вести себя одинаково. В репозитории также есть интеграции с MCP SDK, Strands, LangChain, LangChain.js, Vercel AI SDK, Mastra, OpenAI Agents, Pydantic AI, Semantic Kernel и Bedrock Agents. Эти интеграции не превращают TOLAP в MCP-сервер. Проект оборачивает функцию, используемую слоем инструментов; само приложение по-прежнему отвечает за получение данных.

Для промышленного применения в репозитории предусмотрен сервер политик на PostgreSQL, неизменяемые версии политик, операции публикации и отката, журнал аудита, администрирование с аутентификацией Cognito и ротация ключей подписи с периодом перекрытия. Это эталонная инфраструктура, а не доказательство того, что каждой организации следует разворачивать весь стек.

Почему обычной авторизации инструмента недостаточно

В большинстве архитектур агентов уже существует несколько уровней разрешений. Пользователь проходит аутентификацию в приложении. Приложение выдаёт агенту сервисную личность или делегированный токен. Шлюз проверяет токен. Инструмент обращается к базе данных или API. Каждый уровень полезен, но ни один автоматически не отвечает на вопрос об уровне отдельных объектов.

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

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

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

Архитектурный довод TOLAP состоит в том, что инструмент — последнее надёжное место, где можно не допустить попадания данных в контекст агента. Инструкции в промпте не являются границей безопасности. Модель может неверно понять правило, выполнить вредоносную инструкцию, встроенную в извлечённый документ, или объединить по отдельности разрешённые результаты в раскрытие, которого разработчик не ожидал. Если чувствительное поле никогда не пересекало оболочку, модель не сможет восстановить его из собственного контекста.

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

Релиз добавляет больше, чем фильтрацию строк и полей

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

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

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

Порядок здесь имеет значение. Фильтрация по цели выбирает применимую политику. Проверка действия определяет, что именно должен сделать инструмент. Затем контроль уровня объектов ограничивает данные, которые можно вернуть или изменить. Каждый этап описывается как работающий по принципу отказа при сбое и как независимо тестируемый.

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

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

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

Что это меняет для команд MCP и инструментов агентов

Практический эффект будет особенно заметен у команд, которые добавляют инструменты быстрее, чем проектируют для них авторизацию.

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

Та же проблема встречается за пределами MCP. Инструмент OpenAI Agents, ретривер LangChain, группа действий Bedrock Agent, конечная точка function calling или собственная оболочка Python могут стать случайной границей раскрытия. Подход TOLAP намеренно находится ниже фреймворка модели: политика помещается вокруг функции, которая обращается к источнику, а тот же механизм контроля сохраняется при смене слоя оркестрации.

У такого разделения есть операционное преимущество. Команды могут проверять поведение безопасности, не проверяя способность модели следовать инструкциям. Тест политики способен подтвердить, что запрещённый столбец отсутствует, фильтр строк применён, ограничение результата соблюдено, а запрещённое действие завершается ошибкой. Это обычные программные и security-тесты. Затем модель можно оценивать по полезности уже на сокращённом наборе данных.

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

Границы, которые по-прежнему принадлежат приложению

TOLAP не отменяет необходимость традиционных средств защиты.

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

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

Важен и сам источник. Безопасность на уровне строк в базе данных, авторизация API, политики хранилища и прикладные бизнес-правила должны и дальше самостоятельно удерживать свои границы. TOLAP может сократить объём данных, получаемых агентом, но не должен быть единственной защитой критической базы или необратимой операции.

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

Важна наблюдаемость. Полезное событие аудита — это не просто запись «инструмент вызван». Оно должно связывать человека или сервис, делегировавший полномочия, идентичность агента, цель, инструмент, действующую версию политики, область данных, размер результата, принятое решение и факт подтверждения. Без такого контекста специалисты по реагированию на инциденты будут знать, что запрос выполнялся, но не поймут, почему он был разрешён.

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

Разумный план оценки

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

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

Затем разделите авторизацию возможностей и авторизацию данных. Формулировка «агент может использовать поиск клиентов» описывает возможность. Формулировка «агент может видеть клиентов, закреплённых за этим сотрудником, без даты рождения и с замаскированной электронной почтой» описывает политику данных. Обе формулировки нужно перевести в проверяемые тесты.

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

Тестируйте не только одиночные вызовы, но и композицию. Модель может получить чувствительную информацию через несколько на вид безобидных запросов или передать полномочия от одного агента другому. Фиксируйте и анализируйте последовательности, изменения делегирования и повторяющиеся выгрузки. Если деловая цель имеет значение, заранее определите, когда последовательность требует проверки человеком, вместо попытки выразить каждое толкование в промпте.

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

Почему за этим релизом стоит следить

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

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

Проект следует оценивать как инфраструктуру, а не как готовый знак безопасности. Изучите модель угроз. Убедитесь, что обёрнут каждый путь к источнику. Проверьте схему политик и поведение при сбоях. Запустите примеры на данных, близких к реальным. Оцените лицензию, зависимости, поддерживаемые среды выполнения и операционную модель с учётом требований организации. Необязательный LLM-судья должен рассматриваться как вспомогательное средство проверки, которому тоже нужна отдельная валидация.

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

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

Источники

• Introducing TOLAP: object-level access control for AI agent tools — AWS Open Source Blog, источник фактов, 22 сентября 2026 года.
• TOLAP — Tool-Object Level Access Protocol — AWS Labs, источник фактов, 22 сентября 2026 года.
• Документация по архитектуре TOLAP — AWS Labs, контекстный источник.
• Microsoft Entra security for AI overview — Microsoft Learn, контекстный источник.
• Accelerating the Adoption of Software and AI Agent Identity and Authorization — NIST NCCoE, контекстный источник, 5 февраля 2026 года.
• Authorization Architectures for Tool-Using AI Agents — arXiv, контекстный источник, 17 сентября 2026 года.
• Discussion of scoped permissions and agent authorization — Reddit, дискуссионный источник.