Поищите «Безопасность ИИ», и большая часть того, что вы получите, касается уровня модели: быстрое внедрение, джейлбрейки, фильтрация вывода, утечка данных через ответы модели. Все реальные проблемы. Но в заявках на получение степени LLM, которые я действительно рассматривал — сторона п...
Поищите «Безопасность ИИ», и большая часть того, что вы получите, касается уровня модели: быстрое внедрение, джейлбрейки, фильтрация вывода, утечка данных через ответы модели. Все реальные проблемы. Но в приложениях LLM, которые я на самом деле просматривал — побочные проекты, демонстрации хакатонов, множество продуктов на ранней стадии — проблема безопасности, с которой я сталкиваюсь гораздо чаще, не является ни одной из них. Это жестко запрограммированный или открытый для внешнего интерфейса ключ API.
Это не новая проблема. Это та же ошибка, которую веб-разработчики совершают со сторонними ключами API уже более десяти лет. Но это продолжает происходить именно с ключами LLM, и я думаю, что это стоит изучить, потому что термин «шлюз безопасности API» используется достаточно свободно, и люди предполагают, что он охватывает это по умолчанию — но часто это не так, в зависимости от того, что вы на самом деле развертываете.
Непривлекательный, чрезвычайно распространенный режим отказа
Схема выглядит примерно так: разработчик быстро создает, подключает ключ LLM API непосредственно в код на стороне клиента (мобильное приложение, браузерный инструмент, быстрый прототип), чтобы заставить что-то работать, и либо никогда не удосуживается перенести это на серверную сторону, либо не понимает, что ключ, встроенный в поставляемый код внешнего интерфейса, тривиален.