Защитные механизмы агентов и динамическая конфигурация LDAP

Сегодня я работал над двумя разными задачами. У обеих была одна цель: сделать границы явными и простыми в управлении.

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

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

Я решил это с помощью трех правил:

  • Явно фильтровать по организации в каждом запросе. Не полагайтесь на глобальную область видимости.
  • Использовать те же строки разрешений, что и в веб-приложении. Агент никогда не должен иметь больше полномочий, чем человек, который им пользуется.
  • Использовать UUID для поиска вместо автоинкрементных ID.

Относитесь к каждому инструменту как к недоверенной конечной точке. Размещайте логику там, где вы сможете протестировать её в одном месте.

Вторая задача касалась портала идентификации. Я перенес настройки LDAP из статических файлов в пользовательский интерфейс настроек. Теперь администраторы могут изменять хост, порт и учетные данные без нового развертывания.

Я также добавил контроль тайм-аутов соединения и опций SASL. Это создало техническую сложность при работе с JSON.

Когда вы сохраняете целочисленные ключи в JSON, при декодировании они возвращаются в виде строк. Функции LDAP требуют целочисленные ключи. Мне пришлось написать маппер, чтобы преобразовывать эти ключи обратно в целые числа перед использованием.

Чтобы обеспечить безопасность, я добавил два защитных механизма:

  • Шифровать пароли bind при хранении. Никогда не сохраняйте секреты в кэше в открытом виде.
  • Валидировать поля JSON перед сохранением. Ошибочная конфигурация должна приводить к сбою на этапе сохранения, а не в тот момент, когда пользователь потеряет доступ к системе.

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

Инженерия — это не просто создание функционала. Инженерия — это создание защитных механизмов.

Источник: https://dev.to/nasrulhazim/dev-log-2026-06-24-agent-guardrails-and-runtime-ldap-config-2hi5