Приложения, которые ваши команды создают в Retool, взаимодействуют напрямую с вашими важнейшими системами: базами данных клиентов, платежными платформами, HR-системами, производственной инфраструктурой и многим другим. В этих системах уже действуют строгие правила разграничения прав доступа, потому что ваши команды безопасности и работы с данными потратили годы на их отладку. Однако именно в этих правилах часто возникают сбои: по данным IBM’s 2026 Cost of a Data Breach Report (opens in a new tab), более чем в каждой пятой организации за последний год произошел инцидент безопасности, связанный с ИИ-моделями или приложениями, причем в 92% из них отсутствовали надлежащие средства контроля доступа для ИИ.
Но ИИ изменил скорость создания приложений. Внутренний инструмент, на разработку которого раньше уходил целый спринт, теперь делается за полдня, создателями приложений выступают не только инженеры, и количество приложений, имеющих доступ к производственным данным, растет быстрее, чем любая команда безопасности успевает их проверять. Каждое такое приложение — это еще одна точка, где должны соблюдаться ваши правила управления.
Что происходит, когда контроль приложений, созданных с помощью ИИ, нарушается?
Когда приложение нарушает эти правила доступа, обычно это происходит по одной из трех причин:
- Человеческая ошибка, например пропущенная проверка ролей или запрос, возвращающий слишком много данных.
- Доступ, переживший своего владельца, когда кто-то меняет роль или уходит, а его приложения и учетные данные продолжают работать.
- Преднамеренная попытка получить доступ к данным, украсть учетные данные или манипулировать ИИ-агентом.
Каковы бы ни были причины, ущерб обычно проявляется одним из четырех способов:
- Приложение видит больше, чем должны видеть его пользователи. Оно подключается через общую учетную запись с более широкими правами, чем у работающего с ним человека.
- Данные выходят из-под контроля правил. Как только они скопированы, закэшированы или экспортированы, разрешения исходной системы больше их не защищают.
- Изменения остаются без контроля. Безопасность обычно сосредоточена на том, кто может читать данные, но самые дорогостоящие инциденты обычно связаны с тем, кто может их изменять или удалять.
- Проблемы остаются незамеченными. Без записи о том, кто и что запускал против каких данных, проблемы обнаруживаются поздно или не обнаруживаются вовсе.
Вопрос
Как с этим справляется большинство разработчиков ИИ-приложений
Как это делает Retool
Почему это безопаснее
Где задаются правила?
Каждое приложение имеет собственный вход в систему и проверки прав
Групповой доступ настраивается в Retool один раз, а членство синхронизируется с вашим провайдером личных данных. Для PostgreSQL функция Data Access Enforcement (в публичной бета-версии) применяет правила для таблиц, столбцов и строк к каждому запросу
Для PostgreSQL проверка, пропущенная в одном приложении, не создает уязвимость
Где хранятся учетные данные?
Внутри каждого приложения или рядом с ним
Никогда в коде приложения. При локальном развертывании — в вашей собственной инфраструктуре или уже используемом менеджере секретов
Учетные данные не могут утечь через приложения, которые создают люди
Что останавливает вредоносные изменения?
Сканирования, выявляющие распространенные проблемы
Проверки в процессе написания кода ИИ и повторно при публикации, а также согласование функций, изменяющих данные
Известные небезопасные паттерны блокируются до того, как приложение выйдет в продакшн
Видно ли то, что произошло?
Журналы входов и действий администратора, а не запросы, затрагивающие ваши данные
Аудит-логи на уровне запросов, которые можно экспортировать или передавать в ваши инструменты безопасности
Вы можете восстановить картину того, кто и какой запрос выполнил, к какому ресурсу и когда
Все эти сбои имеют одну общую первопричину. Когда контроль заложен внутри каждого приложения, каждое новое приложение несет в себе дополнительные риски. Каждый разработчик, каждый запрос и каждый ИИ-агент должны действовать безошибочно каждый раз. Это не масштабируется с ростом числа создаваемых приложений.
Retool применяет другой подход, перекладывая большую часть этой ответственности на саму платформу, а не на каждое отдельное приложение. Ваши правила задаются один раз и применяются везде, где это необходимо. Учетные данные не попадают в создаваемые людьми приложения. Рискованные изменения проверяются до попадания в продакшн, а в случае необходимости у вас всегда есть запись о том, что произошло.
Как Retool поддерживает управление приложениями, созданными с помощью ИИ
Давайте рассмотрим каждый сбой по очереди, разобравшись, что берет на себя Retool и где по-прежнему остается роль вашей команды.
1. Когда приложение на базе ИИ имеет больше прав доступа, чем должны иметь его пользователи
Когда приложение подключается к базе данных или хранилищу, оно обычно делает это с помощью одной общей учетной записи. Все, что видит эта учетная запись, видит и каждый пользователь приложения. Единственное, что сужает доступ обратно — это те проверки, которые разработчик не забыл прописать в приложении. Во многих других инструментах каждое новое приложение также требует собственной настройки входа и логики прав доступа, и по мере создания новых приложений все больше таких проверок упускается из виду.
Retool привязывает доступ к конкретному человеку, а не к приложению. Пользователи входят в систему через ваш провайдер личных данных, а членство в группах синхронизируется автоматически. Доступ каждой группы к приложениям и источникам данных настраивается в Retool один раз и может различаться для производственной среды и среды промежуточного тестирования (staged). Для поддерживающих это источников данных каждый пользователь подключается под собственной учетной записью, поэтому приложение видит только то, что этот пользователь увидел бы в исходной системе.
Для баз данных PostgreSQL функция Data Access Enforcement (теперь в публичной бета-версии) позволяет задать правила для таблиц, столбцов и строк один раз на уровне ресурса, после чего они применяются к каждому запросу от любого приложения и агента. Если разработчик или ИИ забудет включить проверку, уязвимость не возникнет. Некоторые задачи, такие как запланированный ночной воркфлоу, не имеют вошедшего в систему пользователя, от лица которого можно действовать, поэтому им по-прежнему требуется общее подключение. Для таких случаев предоставьте подключению только те права доступа, которые необходимы для выполнения задачи.
2. Когда данные копируются в обход ваших правил доступа
Ваши базы данных и бизнес-системы уже знают, кому разрешено что-либо видеть. Эти правила защищают данные только до тех пор, пока они остаются на месте. Как только приложение копирует данные в собственную базу данных, кэширует их или передает через другой сервис, исходные разрешения на них больше не распространяются. Многие другие инструменты работают именно так по умолчанию. Приложения хранят данные в базе данных, размещенной вендором, а учетные данные для ваших систем находятся на серверах вендора. Каждая копия становится еще одним местом, требующим защиты данных, причем обычно с более слабыми правилами, чем в месте их происхождения.
Приложения Retool по умолчанию запрашивают ваши системы напрямую, поэтому каждый запрос возвращается к источнику, и каждый раз применяются правила источника. Учетные данные, используемые для подключения к этим системам, никогда не попадают в код приложения, а опубликованные приложения никогда не отправляют отображаемые ими данные через ИИ-модель.
Автономные развертывания (self-hosted) идут еще дальше. Вся платформа работает в вашей собственной инфраструктуре, поэтому ваши данные и учетные данные не проходят ни через чьи чужие серверы, даже через серверы Retool. Учетные данные также могут храниться в уже используемом вами менеджере секретов, например AWS Secrets Manager, GCP Secret Manager или HashiCorp Vault. С помощью ограниченных секретов (scoped secrets) вы можете ограничить каждый секрет конкретными ресурсами или воркфлоу, чтобы учетные данные были доступны только там, где это действительно необходимо.
3. Когда изменения в производственных данных остаются без контроля
Большинство средств контроля доступа связаны с тем, кто может читать данные, но самые дорогостоящие инциденты обычно касаются изменения или удаления данных. Ошибка, некорректный запрос или ИИ-агент, сделавший что-то не так, могут перезаписать записи за считанные секунды. Многие другие инструменты решают эту проблему путем сканирования приложений после их создания и выделения обнаруженных проблем. Сканирование позволяет выявить распространенные ошибки, но оно не мешает выпуску приложения и не может гарантировать его безопасность.
Retool добавляет контрольные точки везде, где происходят изменения, начиная с момента до написания какого-либо кода. В режиме планирования ИИ создает подробный план предполагаемых изменений, включая любые изменения в вашей модели данных, чтобы вы могли просмотреть его и внести правки до того, как начнется создание. Как только написание кода начинается, Retool проверяет его в процессе и отклоняет небезопасные паттерны до их сохранения — например, запросы, созданные с риском внедрения, или код, пытающийся получить доступ к учетным данным либо обойти уровень данных Retool.
Те же проверки выполняются повторно при публикации, поэтому небезопасный код не попадет в рабочее приложение. По умолчанию любая функция, изменяющая данные, запрашивает подтверждение перед запуском, а каждая функция должна быть одобрена до публикации приложения. Каждое изменение, сделанное человеком или ИИ, сохраняется как версия, которую можно просмотреть и откатить. Изолированные среды ограждают тестовые изменения от производственных данных, а контроль версий (Source Control) позволяет командам проверять изменения перед выпуском. Чего Retool не может решить, так это то, является ли изменение правильным для вашего бизнеса. Правила валидности значений по-прежнему остаются в вашей базе данных и логике приложения, а ограничения базы данных служат хорошим вторым уровнем защиты.
4. Когда проблемы с доступом остаются незамеченными из-за отсутствия логирования
Ни один набор средств контроля не может учесть абсолютно все, и когда что-то все же идет не так, значение имеет лишь то, как быстро вы об этом узнаете и сможете ли восстановить картину произошедшего. Многие другие инструменты сохраняют лишь часть информации. Некоторые ведут логи всего пару недель, другие предлагают их только на самом дорогом тарифном плане, а третьи отслеживают входы в систему и действия администраторов, но не запросы, которые непосредственно затрагивают ваши данные.
Retool регистрирует активность вплоть до отдельного запроса. Аудит-логи показывают, кто, какой запрос, к какому ресурсу и когда выполнил во всех приложениях, созданных на платформе. При включенном принудительном контроле доступа к данным (Data Access Enforcement) для ресурсов PostgreSQL изменения правил доступа также залогированы, наряду с любыми запросами, которые эти правила заблокировали или ограничили. Логи могут передаваться в инструменты мониторинга и безопасности, которые уже использует ваша команда, а клиенты с саморазвертыванием могут самостоятельно настраивать сроки хранения.
Действия ИИ видны точно так же, поэтому администраторы могут отслеживать использование и затраты в разрезе пользователей и моделей, а не рассматривать работу на базе ИИ как слепую зону. Чего Retool не может решить, так это то, что именно считается подозрительным в вашей среде. Retool ведет учет и отправляет данные туда, куда вам нужно. Ваша команда решает, на что настраивать оповещения и кто будет реагировать.
Ваши команды будут продолжать создавать все больше приложений и делать это быстрее, а ИИ будет только ускорять процесс. Какую бы платформу вы ни выбрали, стоит задать четыре вопроса, прежде чем доверить ей рабочие данные. Они также послужат полезным ориентиром, если вы сравниваете Retool с конструкторами «промпт-в-приложение» или ИИ-агентами для написания кода прямо в браузере.
- Должно ли правило настраиваться в каждом приложении или только один раз? Если безопасность зависит от правильности настройки в каждом отдельном приложении, каждое новое приложение создает риск появления уязвимости.
- Где хранятся учетные данные? Выясните, находятся ли они в коде приложения, на серверах вендора или в месте, которое контролируете вы.
- Что останавливает вредоносное изменение до его выпуска? Выявление проблем после создания приложения — это не то же самое, что их блокировка до выхода в продакшен.
- Если что-то пойдет не так, сможете ли вы увидеть, что именно произошло? Уточните, фиксируют ли логи запросы, затрагивающие ваши данные (а не только входы в систему), и как долго они хранятся.
- Можно ли это отменить? Узнайте, можете ли вы откатить приложение до более ранней версии, хранится ли эта история в контролируемом вами месте (например, в собственном репозитории Git) и как восстанавливаются данные из резервной копии.
Некоторые решения всегда будут оставаться за вашей командой: например, как настраивается каждое подключение, что люди делают с данными, к которым у них есть доступ, и что считается корректным изменением для вашего бизнеса. Задача Retool — сделать так, чтобы эти решения было проще принять один раз и легче применять повсеместно. Чтобы узнать больше о любом из этих аспектов, посетите наш Центр доверия (Trust Center) или свяжитесь с нашей командой.
