В тот момент, когда вы позволяете LLM написать код, а затем запустить его по-настоящему, вы передаете решение модели, которая понятия не имеет, что содержит ваш файл .env. Чат-бот, который только разговаривает, безопасен по своей конструкции. Тот, который запускает собственный Python для проверки...
В тот момент, когда вы позволяете LLM написать код, а затем запустить его по-настоящему, вы передаете решение модели, которая понятия не имеет, что содержит ваш файл .env. Чат-бот, который только разговаривает, безопасен по своей конструкции. Тот, кто запускает свой собственный Python для проверки математических вычислений или построения диаграммы, — это другое животное, и что-то должно решить, где разрешено выполнение этого кода.
Первым инстинктом большинства людей является exec(), и это совершенно неправильный инстинкт: exec() выполняется внутри вашего собственного процесса, используя переменные вашей среды и разрешения вашей файловой системы. Я написал более длинную версию этого пошагового руководства на DevToolLab, охватывающую E2B, Modal и Piston, движок с открытым исходным кодом, который вы можете разместить самостоятельно, а не зависеть от какого-либо поставщика. Каждый приведенный ниже фрагмент был проверен на соответствие версиям SDK, фактически установленным через pip, а не скопированным с маркетинговой страницы.
Проблема exec(), быстро
Перетащите сгенерированную моделью строку прямо в exec(), и она сможет прочитать все, что может прочитать ваш процесс:
model_output = """
импортировать ОС
print(f"Я вижу переменные среды {len(os.environ)} из этого процесса.")
"""
exec (model_output)
На обычном ноутбуке, который печатает что-то вроде, я вижу 61 переменную среды из