How to Securely Deploy Computer Use Agents | Nemotron Labs

Что происходит, народ? Добро пожаловать обратно на еще одну прямую трансляцию Neotron Labs. У нас сегодня для вас кое-что особенное. Как вы можете прочитать из названия, мы собираемся поговорить о безопасности. Итак, к нам присоединились два эксперта по безопасности из Nvidia, Эрик и Рич. Мы познакомимся с ними немного поближе через секунду. Но первое, что мы сделаем, как обычно, это начнем с демонстрации. Прежде чем мы увидим, что мы увидим сегодня, я хочу убедиться, что все помнят оставлять любые вопросы, которые у вас есть, в чате во время трансляции. Наши эксперты здесь, чтобы отвечать на вопросы и разговаривать с вами о, знаете ли, безопасности в этом новом веке очень автономных агентов. Итак, Эрик, без дальнейших церемоний, пожалуйста, возьмите слово и покажите нам, что мы здесь видим сегодня.

Да. Да, я в восторге, как только мы запустим эту запись, я сообщу об этом людям. Итак, я написал небольшой агент, чтобы помочь с проектами с открытым исходным кодом, который будет сортировать проблемы и запросы на слияние для вас и, по сути, помогать, верно? Так что, если кто-то открывает проблему и говорит: "Эй, есть такая проблема". Возможно, они предлагают какое-то потенциальное исправление. Агент проверит это. Предложит открыть запрос на слияние. Однако справа на экране сверху вы можете видеть, что сейчас, если мы перечислим нашу домашнюю директорию, в ней ничего нет. Итак, агент загружает проблемы и смотрит на открытую проблему, и происходит что-то забавное, когда он начинает парсить проблему, верно? он пытается понять ее, и там есть какой-то код, а внизу справа мы видим, что теперь открылась небольшая оболочка. Так что просто как доказательство концепции я коснусь demo.p в домашней директории, и я бы запустил calc, но я забыл, как это сделать на Mac OS. Я забыл команду, потому что я мошенник и обманщик. И теперь мы видим наверху справа, что успешно разрешено. Итак, это то, что произошло, когда наш полезный агент по написанию кода попытался разобрать проблему. Теперь я перейду к своему браузеру и просто покажу вам, что у меня там происходит. Итак, код здесь, фактический код, может быть простым для людей. Это может быть знакомо любому, кто когда-либо задумывался о написании какого-либо языка программирования. Это довольно простой "привет, мир". Но если мы перейдем к нашим проблемам, о, есть ошибка. Какая это может быть ошибка? Ну, на самом деле это не ошибка. Это то, что мы не импортировали subprocess.popen для открытия этой обратной оболочки на порту 1337. Так что это то, что показывает демо, верно? Он загружает эту проблему, идет, говорит, здесь есть какой-то код, а затем выполняет этот фрагмент кода, который дает нам возможность получить доступ к машине разработчика, на которой он работает. У меня также есть еще один. Я открыл запрос на слияние, который добавляет сервер валидации. Что делает этот сервер валидации? Это кажется полезным. Так что, если мы посмотрим, как мы изменили наш файл здесь, у нас есть этот URL валидации, и он пойдет и прочитает этот маленький файл и отправит его. Так что это ваш приватный ключ SSH. И это тоже работает, но я не записал демо, потому что я очень ленив и подумал, что одного видео достаточно. Так что да, это наше демо. И то, о чем мы действительно хотим поговорить сегодня, это о том, что пошло не так и что следовало бы сделать лучше, верно? Итак, как мы это испортили и как мы могли бы написать действительно безопасный агент?

Абсолютно потрясающе. Эрик. Большое спасибо за демо. Мы собираемся показать слайд, который представляет тех, кто сегодня с нами. К нам присоединились Эрик, научный сотрудник, и Рич, главный архитектор по безопасности в NVIDIA. И я имею в виду, я имею в виду, вы сказали это совершенно правильно. То, что мы только что видели, не вызвало у меня радости, верно? Это не вселило в меня уверенности, что мой агент сделает то, что я хочу. Итак, есть ли способ, которым люди могут начать думать о том, как сделать систему менее очевидно сложной в обращении?

[фыркает] Да, я на самом деле только что увидел, как что-то появилось, комментарий от Максимиллиана MCU на YouTube, что человек в цикле является обязательным для любого агента, и я с этим не спорю. Я с этим не спорю. Однако это тоже может быть рискованным предложением. Так что мы видели, как кофейная чашка удерживает кнопку Enter, маленькие птички-качалки нажимают кнопку Enter, как раз тогда, когда люди используют вещи, которые вас перегружают, вы получаете эту усталость от уведомлений, когда это как будто нет, просто сделай это, просто сделай это, и в конце концов люди идут и перестают на это смотреть. Так что я фундаментально согласен, что человек в цикле имеет решающее значение. Просто когда у вас есть человек в цикле, вам нужно продумывать, как часто вы взаимодействуете с этим человеком, верно?

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

Да, и я имею в виду, знаете, это интересно, потому что эта идея усталости от обзора, верно? Я имею в виду, я думаю, что это то, что люди чувствуют, когда у них есть около 12 агентов облачного кода, и они все усердно работают. Вы доходите до точки, когда проще просто переключить вкладку и провести свою жизнь. Мне было бы интересно, однако, кроме человека в цикле, который, как вы сказали, возлагает все бремя на нас, но, как я сам, я знаю слово "безопасность" и знаю слово "безопасность", но на прошлой неделе Эрик объяснил мне тонкие различия между ними, так что я не эксперт, поэтому, когда я вижу, как этот код прокручивается или этот запрос прокручивается, я не тот человек, который должен убедиться, что он работает безопасно, а не небезопасно. Так какие еще стратегии мы можем использовать, чтобы помочь смягчить некоторые из этих рисков, подобных тому, который вы нам показали? И как вы вообще классифицируете этот риск? Как мы можем дать название тому, что вы нам показали?

Да, я имею в виду, выполнение кода как услуга. Я не знаю. Да, именно. [смех] RCE как услуга — это именно то, что нужно. Я имею в виду, я думаю, первое, самое очевидное, если я посмотрю на то, что я написал, а я написал это не для безопасности, просто чтобы быть ясным, это то, что он выполняет код локально. Он выполняет код как пользователь в качестве подпроцесса агента. Это огромная ошибка. Есть ряд способов обеспечить безопасность этого. Вы можете поместить его в песочницу различных типов. Так что, я имею в виду, самое простое, что можно сделать, это запустить контейнер Docker и отправить свой код в контейнер Docker, и вы можете инструментировать это как угодно. [фыркает] И это довольно хорошо, но вы находитесь в одном эксплойте ядра от того, чтобы это было то же самое. Затем вы можете начать рассматривать более сложные методы виртуализации, где у вас есть что-то вроде настоящего сервера vSphere или чего-то подобного, и вы должны отправить его на отдельную машину для выполнения. Я думаю, что есть некоторые агентские фреймворки и некоторые поставщики, которые фактически делают это для вас. Да, я думаю, что одна из вещей, которую мы сделали на стороне архитектуры, где мы пытаемся взять то, что находит и ломает команда красных, а затем выяснить, как испортить им день. Я думаю, мы остановились на трех больших вещах как на важных вещах, которые вы действительно хотите попытаться сделать в песочнице. И многие коммерческие инструменты, которые предоставляют такую функцию автоматического запуска, теперь начинают выпускать песочницы, которые делают подобные вещи. Но три вещи, на которых мы остановились как на минимальном наборе требований: вам нужно что-то, что будет контролировать исходящий сетевой трафик. Так что, если он пытается установить исходящее соединение, в идеале у вас должен быть набор разрешенных доменов или IP-адресов или портов, и вы можете сказать: "Да, все это безопасно". Если вы хотите перейти и получить доступ к этим, вперед. И поэтому что-то вроде примера Эрика, где он делает исходящий запрос netcat на какой-то неизвестный сервер, неизвестный порт, надеюсь, будет заблокировано или, по крайней мере, будет представлено для проверки человеком в цикле. Вторая большая вещь — это то, что вы хотите, чтобы ваш агент имел представление о рабочем пространстве. Так что, как дерево каталогов, в котором вы работаете, и блокируйте любые записи, которые происходят вне его. И я думаю, что это уже стандарт для большинства этих инструментов сегодня. Вы можете найти некоторые, которые будут менее добросовестными, чем другие, но в целом, знаете ли, если вы можете сделать что-то вроде внедрения подсказки в LLM, который управляет вашим агентом, чтобы написать обратную оболочку в bashrc, не имеет значения, если ваша песочница блокирует сетевой доступ. Что происходит, так это то, что процесс, который запускает вашу следующую сессию пользователя, выполнит этот bashrc, и тогда внезапно вы сгенерировали обратную оболочку. Так что эти внешние записи вне рабочего пространства также могут быть очень опасными. Да. И последнее, что мы обнаружили, это просто не позволять агенту когда-либо изменять свою собственную конфигурацию. Так что многие агенты сегодня имеют хуки, которые являются командами, командными оболочками, которые часто выполняются вне песочницы при срабатывании определенных событий, и они также могут быть очень опасными. И мы видели, как команда красных использовала их для получения устойчивости и бокового перемещения на множестве различных типов агентов. Так что, если вы сделаете эти три вещи просто как отправную точку, заблокируете исходящий сетевой трафик, заблокируете дополнительные записи файлов в рабочем пространстве и затем предотвратите изменения конфигурации, у вас будет довольно хорошая основа для дальнейшей работы, и все это как бы подчеркивает агентов, пишущих код, что опять же является областью, где сейчас находится много коммерческого интереса, но я думаю, что это применимо в целом к более общим агентским вещам, включая то, что мы видим в пространстве с Claude, где одна из продаваемых особенностей заключается в том, что он может переписывать свои собственные навыки, что опять же меняет его собственную конфигурацию и дает ему возможность выполнять новые и потенциально опасные возможности.

Да, я имею в виду, одна из других вещей, которые мы видели, Йохан Рейбургер, которого Рич знает, но аудитория может не знать, это эскалация привилегий между агентами, верно? Так что не только блокирование модификации собственной конфигурации, но и изоляция рабочего пространства становится действительно важной, потому что то, что мы видели, происходит, то, что было продемонстрировано, это то, что вы получаете свой GitHub Copilot для изменения конфигурации вашего кода Claude, а затем ваш код Claude возвращается и изменяет конфигурацию вашего GitHub Copilot, и теперь это не имеет значения, верно? Так что вам нужно иметь это, и я думаю, вам нужно быть очень продуманными о том, где живут эти агенты, верно? Как, да.

И я имею в виду, есть так много, знаете ли, это вселенная вещей, которые вы открываете. Несколько комментариев из чата, которые я просто хочу убедиться, что я ответил. Во-первых, ребята, мы записываем это. Так что это будет доступно после записи на всех платформах, LinkedIn, YouTube и X. Так что вы можете посмотреть это позже или поделиться им с людьми, которым, по вашему мнению, это будет интересно. И второе, Иэн Дип Ден спрашивает: "Можно ли задавать вопросы?" Да, в этом вся суть. Пожалуйста, задавайте вопросы. С нами два невероятно умных человека, которые работали с этим. Одна вещь, которую я действительно хочу затронуть, хотя, знаете ли, Рич и Эрик оба это сказали, но как будто есть какая-то связь между усилиями команды красных и усилиями архитектора безопасности, верно? Так вы бы дали нам краткое описание того, как работает этот процесс, и как мы должны думать о работе, которую вы оба делаете вместе, и почему важно иметь обе стороны этого уравнения, и Эрик, возможно, когда вы говорите о том, что вы делаете, если бы вы могли дать людям небольшой фрагмент обзора того, что такое вообще красное тестирование, на случай, если они раньше не слышали об этом?

Да. Итак, я думаю, я думаю, я начну, и я говорю как участник красной команды, но я не я не я фальшивый участник красной команды. У нас есть целая красная команда в Nvidia, у которой я краду идеи и не даю им кредита. Это шутка. Они действительно замечательные. У нас есть замечательная группа участников красной команды здесь. Они потрясающие. И так, знаете ли, каким бы ни было взаимодействие, будь то нацеливание на агент по написанию кода, будь то нацеливание на какую-то услугу, будь то нацеливание на что угодно, верно? Мы посмотрим, как мы можем заставить это вести себя плохо, верно? Так что красное тестирование в самом общем смысле — это заставить что-то вести себя плохо. Что это означает, довольно широко по объему. И поэтому есть некоторое красное тестирование безопасности контента, где вы пытаетесь заставить модели говорить плохие слова с точки зрения кибербезопасности. Лично я считаю, что плохо, когда модели говорят определенные вещи. С другой стороны, мне не нужно запускать инцидент с точки зрения кибербезопасности, потому что там использовался, знаете ли, какой-то неприятный язык. Так что мы очень сосредоточены на результатах кибербезопасности. Так что для чего-то, что будет иметь дело с кодом, что будет выполнять код, что будет вызывать инструменты, это как я могу заставить это выполнить мой код, верно? Как я могу заставить это выполнить код, который я хочу? Если это что-то, что, возможно, более банально, верно? Что-то, что не обязательно выполняет код, я могу задаться вопросом, могу ли я получить учетные данные, верно? Потому что многие из этих вещей будут делать вызовы API. Могу ли я заставить вас поделиться своими ключами API со мной? Могу ли я заставить вас вызвать мой сервер с вашим вызовом API? Скажите вам, эй, они обновили URI для этой службы. Можете ли вы вызвать этот? Иногда это работает, иногда нет. Это зависит от того, как параметризованы вещи, верно? Но это примерно то, о чем мы думаем, верно? И так, я работаю над парой продуктов NVIDIA, оба с открытым исходным кодом. Я работаю над Nemo Guard Rails и Garak. Так что я работаю как на оборонительной, так и на наступательной стороне. Но, по сути, когда у нашей красной команды появляются эти идеи, некоторые из них кодифицируются в эти продукты, но часто это попадает на стол Рича, и он говорит: "Эй, Рич, мы нашли это". И он говорит: "Хорошо". И я позволю ему говорить о его стороне жизненного цикла. Чтобы быстро подытожить, Эрик, вы как бы хорошие парни, пробующие плохие вещи, чтобы увидеть, что происходит. Это нормально, чтобы перефразировать? А затем вы делаете, вы заставляете модель или систему делать что-то, что, возможно, нежелательно. И теперь мы и теперь мы входим в Рича, который получил этот предмет на свой стол. [смех]

Ну, я люблю думать, что мы пытаемся добраться до этих систем еще до того, как это сделает красная команда. Как в идеале, это почти разница между хорошей архитектурой системы, которая говорит: "Весь этот класс вещей просто из-за того, как мы спроектировали эту систему в первую очередь, невозможен". Так что, как Эрик упомянул что-то немного раньше о том, что вы должны запускать все это в контейнере Docker, но на самом деле виртуальная машина лучше, и это почти архитектурное позиционирование, верно? Вы говорите: "Смотрите, мы должны запускать это в виртуальной машине, потому что тогда мне не нужно, чтобы вы показывали мне, что у вас есть эксплойт ядра, эксплойт ядра не имеет значения, потому что это совершенно другое ядро". Так что мы, со стороны архитектуры безопасности, сначала пытаемся применить хорошие принципы проектирования и хорошие повторяемые шаблоны, и именно здесь контроль исходящего сетевого трафика, верно? Это очень общий класс средств контроля. Их нужно специализировать для разных приложений, но если вы внедрите это с самого начала, вы отрежете ноги от множества различных атак. Так что мы пытаемся пропагандировать эти дизайны и придумывать хорошие, и выпускать их, а затем они идут в продукты. И тогда красная команда, одна из вещей, которые они делают, это показывает нам, где есть пробелы в этих дизайнерских решениях и пробелы в деталях реализации, и они помогают нам увидеть, как мы можем дать хорошие рекомендации с архитектурной точки зрения, но они неполные, или детали не очень хорошие. И поэтому разработчикам трудно закрыть все мелкие уголки. И это возвращается к более и лучшим и более тщательным рекомендациям в будущем. Так что это действительно между нашей внутренней красной командой и, знаете ли, иногда мы получаем внешние раскрытия. Этот обмен между наступательной стороной экосистемы безопасности и архитектурной оборонительной стороной экосистемы безопасности на самом деле очень важен, особенно когда мы входим в этот новый мир агентского ИИ, где в отличие от старых приложений безопасности или облачной безопасности или чего-то подобного, мы все еще очень активно разрабатываем плейбуки для "вот наш очень предвзятый взгляд на то, как вы делаете это правильно". Знаете, если вы собираетесь и строите, скажем, облачный сервис, у вас могут быть архитекторы с, знаете ли, 10-летним опытом в этом, которые придут и точно скажут вам, как настроить списки доступа, как настроить политики, как настроить это, как настроить то. Большая часть этого все еще является рабочим процессом для агентских вещей. И поэтому обратная связь с исследователями наступательной безопасности, которые находят эти пробелы, на самом деле помогает нам отточить наше собственное мышление и понять, как проектировать эти вещи и как давать хорошие плейбуки.

Да. Это действительно похоже на очень, знаете ли, не использовать слишком корпоративное слово, но синергетические усилия, верно? Как вы строите стену, кто-то пытается найти способ пройти через стену. Когда они это делают, они говорят вам, чтобы вы могли заделать стену, верно? Это очень, я думаю, это имеет большой смысл. У нас есть вопрос от Ванессы из X, которая спрашивает, где вы публикуете свои плейбуки агентских систем для общественности? Я не знаю, актуален ли этот вопрос, но где люди могут прочитать ваши мысли об этом или подходы, которые вы приняли? И, возможно, Рич, давайте начнем с вас. Я знаю, что вы недавно прочитали что-то, что может быть интересно людям, или написали, что может быть очень интересно людям.

Да. Итак, у нас нет полностью разработанных, знаете ли, многостраничных PDF-файлов для скачивания и тому подобного, которые мы выпустили на данный момент. На сайте технического блога NVIDIA есть много материалов как от команды красных ИИ, так и от меня и других людей из сферы безопасности, относящихся к этой дискуссии. Я недавно опубликовал что-то о песочницах и о том, что мы считаем своего рода прогрессией "ползи, иди, беги" для этого, но есть много материалов, написанных как командами безопасности в Nvidia, так и командами красных ИИ, которые охватывают агентов и продукты на основе ИИ в целом. Так что это определенно было бы первое, куда я бы направил людей.

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

Да. Да. Да. Итак, я думаю, чтобы напрямую ответить на вопрос пользователя, у нас есть куча чертежей на GitHub. Там, и я не буду утверждать их безопасность. Это не моя работа. Кто-то другой принял это решение, верно? Так что, пожалуйста, не пишите мне гневные письма, если они вам не нравятся. Я этого не делал. Однако то, что я сделал, и вы можете писать мне гневные письма, если вам это не нравится, это то, что в прошлом году на GTC мы провели целый день разработчика, где мы показали людям, как тестировать, настраивать эту систему чат-бота, верно? настроить эту агентскую систему, а затем использовать Garak для поиска потенциальных уязвимостей в системе, а затем использовать Nemo Guard Rails для попытки смягчить уязвимости, которые мы обнаружили. Так что мы прошли через весь этот процесс, и, знаете ли, мы все это настроили на launchables и сделали все это, но я также убедился, что это работает локально. Знаете, контент немного устарел, потому что, знаете ли, мы почти год не были на GTC, или, я думаю, месяц до следующего, верно? Но, знаете ли, мы движемся быстро. Так что он немного устарел за год, но это все еще весело. И я думаю, что одна из вещей, которая действительно остается со мной относительно безопасности агентов и разговоров о безопасности агентов и вовлечения в эти разговоры, это то, что, и Рич, я надеюсь, вы согласитесь с этим. Я думаю, что вы согласны, это то, что основы все еще применимы, и если вы делаете основы действительно, действительно, действительно хорошо, как принцип наименьших привилегий, сегментирование выполнения кода, ограничение доступа, верно? Дайте агентам их собственные ключи API, пожалуйста. Пожалуйста, не делайте так, чтобы было легко вращать эти ключи API, пожалуйста. Да. И дайте им доступ на чтение, а не на запись и выполнение, если это возможно. Супер здорово. Если вы делаете эти вещи действительно хорошо, и вы действительно, действительно хороши с основами, остальное намного проще, чем если вы как бы пропускаете основы и говорите: "О, нет. Как предотвратить внедрение подсказки?" Ну, это самая интересная часть. Вы можете попробовать. Иногда это работает, верно? Мы делаем все возможное, но нет 100% агента, защищенного от внедрения подсказок. Кроме того, который не принимает никакого ввода ниоткуда. Верно. Если мы не можем его подсказать, мы не можем внедрить в него подсказки. Это, знаете ли, это настоящая безопасность. Мы можем просто не запускать машину. Хорошо. У меня есть вопрос из чата от Ареро Перейры, и они спрашивают, это хороший момент, я думаю, для вас, ребята, чтобы помочь нам понять разницу между безопасностью и защитой, верно? Так есть ли когда-нибудь жесткие правила для вывода, когда модель не может вывести что-то, несмотря ни на что, такое как чувствительная тема, такая как расизм или что-то в этом роде? Или можно ли полностью исключить эти вещи? Мы говорили о безопасности. Теперь, по моему мнению, из того, что вы мне рассказали, это больше похоже на безопасность контента, верно? И поэтому, как вы думаете о взаимодействии между этими двумя вещами? Может быть, Эрик, мы начнем с вас в этом вопросе.

Да, я думаю, что безопасность контента немного более расплывчата, верно? Чтобы надеть свою профессорскую шляпу, безопасность контента нормативна. Знаете, то, что приемлемо для модели говорить, зависит от времени и контекста, в котором она находится. Есть вещи, которые модель в 1820 году могла бы сказать, что мы, вероятно, не хотели бы, чтобы модель в 2026 году сказала, верно? Эти вещи меняются со временем, и они будут зависеть от того, где в мире вы находитесь. Есть сленг, который очень распространен в Великобритании, который считается глубоко оскорбительным в США. Так что, я думаю, это одна часть: безопасность контента гораздо более расплывчата, чем безопасность. С безопасностью вы по крайней мере знаете: я превысил границу доступа, которую должен был, или нет. Это более прямое определение. Что касается самого вопроса, я бы сказал, что полностью исключить эти вещи невозможно, потому что вы всегда сможете сконструировать ввод таким образом, чтобы получить последовательность выходных токенов, которые дадут вам нужное слово или фразу. Теперь жесткие правила, я имею в виду, вы можете написать, знаете ли, фильтры, вы можете сказать: сгенерируйте вывод, а затем найдите этот список слов, и если он там, удалите его, но знаете ли, это очень сложная вещь, чтобы идти в ногу с этим, верно? Так что для некоторых вещей, опять же, безопасность против безопасности контента, для безопасности это не так сложно, потому что, как мы видели, знаете ли, вы заходите в TikTok или любую социальную сеть, люди находят способы обойти правила обнаружения, верно? Они используют эмодзи вместо этого, или они пропускают букву из слова, или они используют омоним, верно? Что-то вроде этого. И это сложно, по крайней мере, с чем-то вроде выполнения кода. Так что в Nemo Guard Rails у нас есть Yara, это движок, используемый для запуска сигнатур обычно по файлам, но мы запускаем его по выходным данным модели и ищем такие вещи, как: вы пытаетесь вызвать SSH? Пожалуйста, не делайте этого. Вы пытаетесь вызвать netcat? Пожалуйста, не делайте этого. Знаете, такие вещи. У вас есть исполняемый код Python в шаблоне Ginga? Может быть, не надо. Может быть, не надо этого делать. Так что все эти вещи могут быть очень полезны для борьбы с этим. Просто, знаете ли, мы как бы ограничены, когда пытаемся использовать эти жесткие правила, и я думаю, что полное их обучение нецелесообразно.

Да, я думаю, я просто хочу повторить то, что сказал Эрик. Мы видим почти те же самые методы. Если кто-нибудь помнит состязательные изображения, которые были очень захватывающими, знаете ли, около десяти лет назад, когда они впервые начали появляться? Это было 12 лет назад. Да. Проблема в том, что пространство входных данных, которые могут принимать эти модели, настолько больше, чем обучающие данные, которые вы через них пропустили, что действительно трудно гарантировать, что любая данная модель никогда не просто, знаете ли, без применения внешних средств контроля или фильтров, никогда не произведет какую-то серию токенов. И я думаю, что я знаю, что Nvidia немного отличается от многих компаний тем, что мы проводим очень четкое различие между аспектами безопасности и безопасности. Но с точки зрения безопасности, вещи, которые нас больше всего беспокоят, и опять же, это когда мы говорим о безопасности, а не о безопасности, безопасность важна, но когда мы говорим о безопасности, нас больше беспокоят традиционные проблемы типа infosec. Так что, есть ли у меня выполнение кода? Раскрываю ли я личные данные? И могу ли я как-то сделать это или провести атаку типа отказа в обслуживании против этой системы? И это те вещи, с нашей точки зрения, мы всегда как бы предполагаем, что злоумышленник найдет способ заставить модель сказать все, что они хотят. И тогда вам придется начать думать о том, как укрепить все, что находится ниже по течению. И вот тут мы возвращаемся к таким вещам, как песочница. Так что, знаете ли, раньше в мире нулевого доверия, верно? Мы бы сказали: предполагайте нарушение при проектировании агентской системы, верно? Предполагайте, что вас взломают. Предполагайте, что плохой парень заставит ваш LLM, который находится в основе этой агентской системы, сказать все, что они хотят, а затем вам придется спроектировать остальную часть вашей системы, чтобы учесть эту возможность. Это именно то. Это так круто. Я, я, я имею в виду, это просто, знаете ли, объем мысли, который вкладывается в то, что делает использование этих систем каким-либо образом похожим на безопасное, просто обнадеживает, как люди, не из сферы безопасности, чтобы знать, что вы, ребята, это нелегкая работа, и вы делаете много работы. Что мы собираемся сделать, ребята, это мы собираемся показать некоторые слайды сообщества. Так что мы ответим на два вопроса от нашего сообщества. Чтобы убедиться, что мы уважаем время всех, мы быстро пройдемся по слайдам. У нас есть еще два вопроса, которые я хочу задать, а затем мы завершим трансляцию. Ребята, если у вас есть другие вопросы, пожалуйста, оставьте их в чате. Мы будем рады связаться с этими ребятами после трансляции. Но пока у нас есть слайды. Так что, если вы слышите об агентах и задаетесь вопросом: "Что, черт возьми, это такое?" О чем вы, ребята, говорите? У нас есть учебные пути, которые учат вас основам агентов. Так что такое они, как вы можете построить один. Они не углубляются в безопасность. Пожалуйста, заткните уши, Рич и Эрик. Но они описывают основные простые шаблоны, которые существуют в агентах. Следующий слайд, пожалуйста, Зак. У нас также есть наш GitHub. Это Nvidia Nemo Neotron. Где вы можете найти всевозможные примеры для всего Neotron, включая такие вещи, как наш агент bash или такие вещи, как наши сквозные рецепты для таких моделей, как Neotron Nano. Следующий слайд, пожалуйста, Зак. У нас есть Discord. Если у вас есть вопросы, и это не 11:00 утра во вторник по тихоокеанскому времени, вы можете задать эти вопросы в нашем Discord.gg/invidia developer Discord. Вы можете найти меня практически 24/7 по адресу newatron models. Приходите, задавайте любые вопросы, которые у вас есть. Если у вас есть вопросы к команде безопасности, я позабочусь о том, чтобы они вернулись к этим ребятам, и они смогут помочь мне ответить на ваш вопрос. Я не буду отвечать на них самостоятельно. Перейдем к следующему слайду, пожалуйста. Если вы хотите отправить Заку по электронной почте любые вопросы о сообществе разработчиков NVIDIA в целом, вы можете отправить ему письмо по адресу communityinvidia.com. Зак живет в пещере, как вы все знаете, и все, что он делает, это отвечает на вопросы и читает вопросы с этого почтового ящика. Так что, пожалуйста, отправьте Заку любые предложения, комментарии или вопросы о более широком сообществе разработчиков NVIDIA. Следующий слайд, пожалуйста, Зак. И тогда у нас есть соревнование по рассуждению. Вы можете отсканировать QR-код. Это будет доступно для страницы Luma, которая расскажет вам все об этом предстоящем соревновании. Будут реальные призы, ребята. Не просто 15 долларов в виде кредитов, а реальные призы на кону. Мы хотим увидеть, как вы, ребята, можете сделать Neotron лучшим рассуждающим. Следующий слайд, пожалуйста. Следующий слайд. У нас есть. Это верно. GTC приближается, и Эрик сказал, что до него месяц. Теперь меньше месяца. [смех] Мы быстро приближаемся к GTC. Не могу дождаться. У нас будут наши Neotron Days, которые полностью посвящены Neotron. Перейдем к следующему слайду. Думаю, есть еще один слайд. Который просто базовый, знаете ли, эй, приходите на GTC. У нас это есть. Это очень весело. Ричард или Эрика, будет ли на GDC в этом году какой-нибудь контент по безопасности? Будет пара сессий "Чат с экспертом", и затем должен быть доклад, где мы поговорим о том, как мы сделали это с одним из наших партнеров, конкретно о безопасности агентов в песочнице. Так что это будет отличный доклад. Хорошо. Так что, если у вас есть вопросы о безопасности, приходите, пообщайтесь с экспертами лицом к лицу на GTC. Хорошо, мы зададим вам еще два вопроса, а затем отпустим вас. Но эти вопросы, я думаю, один очень сфокусированный, а другой немного более широкий. Рич, я начну с вас. Часть, я был осторожен с агентами. Как мне безопасно хранить эти ключи API для использования агентом таким образом, чтобы никто другой не мог их просмотреть? Это большая проблема, верно? Я имею в виду, вы, ребята, сказали ранее, убедитесь, что вы даете моделям их собственные ключи API. Есть ли какой-либо другой шаг, который мы должны предпринять, чтобы помочь, возможно, ограничить утечку этих ключей в ветер?

Я думаю, есть несколько разных вещей, которые вы можете сделать, в зависимости от того, насколько глубоко вы хотите вникнуть. Самое первое — это если вы дадите ему собственный ключ API и сделаете его краткосрочным и отзываемым. Так что то, что вы можете легко вращать, означает, что вам меньше волнует, если он утечет. Вы ограничиваете ущерб, который может быть нанесен, если этот ключ выйдет и сбежит в дикую природу. Другая распространенная вещь — это только внедрять ключи через переменные среды, если вы работаете в контейнере. Или храните ключ только в памяти. Не записывайте его на диск, потому что это облегчит агентам возможность как бы захватить их и скопировать куда-нибудь, куда не следует, или зафиксировать их в репозитории, когда их не следует фиксировать, или что-то в этом роде. Если вы хотите стать более изощренным, другие вещи, которые вы можете начать рассматривать, это гораздо более сложный технический подъем. Вы можете начать рассматривать хранилища секретов, чтобы получать ключ по запросу и не сохранять его. Вы держите его только до тех пор, пока активна определенная сессия. Или вы можете даже рассмотреть возможность использования, если вы контейнеризируете своего агента, вы можете рассмотреть возможность использования какого-либо HTTP-прокси или сквозного соединения, чтобы секрет фактически подставлялся прокси, и он никогда не будет раскрыт внутри контейнера. Так что каждый из них становится немного сложнее. Каждый из них предлагает некоторые свойства безопасности, которых нет у других. И я думаю, вам нужно подумать о конфиденциальности ресурса, к которому дает доступ ключ API, а затем сбалансировать это с тем, как используется этот ключ API, насколько легко его вращать или изменять, насколько легко обнаружить, что он мог быть скомпрометирован, а затем просто сколько усилий вы хотите вложить в это. Так что, начиная с хобби-проекта, вы, возможно, просто получите краткосрочный одноразовый ключ API, вплоть до ваших драгоценных корпоративных данных, которые должны быть в решении для управления секретами, и вы захотите использовать внедрение и горячую замену через прокси. Это идеально. И позвольте мне сказать что-нибудь, Рич, что я наблюдал, пока вы, ребята, учили нас довольно много о безопасности. Мне кажется, мы действительно хотим построить слои, верно? Как будто мы не просто, о, и вот один шаг, который вы выполняете, и это все, что вы делаете. Это как вот один шаг, и другой шаг, а затем еще один слой, а затем еще один слой. И эти слои как бы складываются друг с другом? Как если бы я, из вашего примера, если бы я сделал все эти вещи, я бы стал более безопасным, верно, чем если бы я просто выбрал лучший сверху? Как если бы я сделал лучшее и сделал самое простое, я бы был дополнительно безопасен? Это хороший способ думать об этом, или это наслоение — это просто то, что я рисую шаблон, которого не существует? Нет, я думаю, вы улавливаете что-то, и это теория швейцарского сыра кибербезопасности, верно? Так что у каждой защиты есть определенное количество дыр, верно? Есть способы обойти каждую из этих защит, верно? Я имею в виду, в самом начале мы говорили о том, чтобы не позволять агентам изменять свои собственные конфигурации. И я как бы сказал: ну, также не позволяйте им изменять конфигурации других агентов. Потому что тогда вы можете просто идти туда и обратно, верно? Так что есть определенные дыры в каждой из них, и когда вы накладываете больше слоев, знаете ли, есть определенные дыры в каждой, но вы в конечном итоге можете наложить так, что вы не сможете пройти все очень легко. Прямо сейчас я бы сказал, что это зависит от того, насколько перекрываются эти дыры, верно? Так что, с тем, что Рич только что предложил, если вы делаете, знаете ли, краткосрочные быстро вращающиеся ключи API и используете хранилище ключей, ну, да, я бы сказал, что они не слишком сильно перекрываются. Если вы также добавляете, верно, используете хранилище ключей только на уровне прокси, ну, да, вы можете сделать все это, но на определенных уровнях это будет менее эффективно, и вы как бы смягчили большую часть этого риска, и вы могли бы лучше инвестировать часть своего времени в другие части вашего стека безопасности, потому что, возможно, вы сделали невозможным для меня когда-либо получить ваши ключи API. Хорошо. Ну, а что, если я просто получу выполнение кода? Тогда мне все равно, верно? Тогда это не моя проблема. Так что вам просто нужно, знаете ли, у нас есть только как у людей, занимающихся безопасностью, особенно, у нас есть ограниченные ресурсы, у нас есть ограниченное время, у нас есть ограниченное финансирование. Так что нам приходится как бы продумывать, куда мы применяем наши защиты и уровень конфиденциальности, верно? Так что, знаете ли, если вы просто занимаетесь хобби-проектом, если вы действительно, действительно, действительно не хотите узнать, как сделать этот стек безопасности, возможно, не стоит тратить все это время, верно? Вам лучше инвестировать в обеспечение того, чтобы ваше выполнение кода было соответствующим образом песочницей и т. д. Так что все эти мелочи складываются. Если вы можете сделать все из них, если у вас есть бесконечные ресурсы безопасности, во-первых, отлично. Во-вторых, знаете ли, это, очевидно, будет полезно, но есть как бы предельная выгода, и вы достигаете определенной точки, когда предельная выгода не принесет вам многого. Превосходно сказано. И Рич, из Окагона вы заметили этот комментарий: ключи являются частью настройки агента, а не частью контекста агента. Можете ли вы помочь нам понять, чему нас учит Окагон?

Да. Я хотел отметить это, потому что это на самом деле очень хороший момент, который я должен был упомянуть. Одна вещь, которую вы всегда хотите убедиться, это взять любые секреты, которые, знаете ли, могут быть ключами API, паролями, чем угодно, и не давать прямой доступ к LLM, потому что если они находятся в окне контекста, если они являются частью ввода, который LLM получает в этом агентском цикле, это означает, что злоумышленники могут найти какой-то способ обмануть LLM, чтобы раскрыть их вам, верно? Так что вы всегда хотите убедиться, что эти ключи API, эти секреты никогда не попадают в контекст модели, в окно контекста, во ввод агента, в историю чата, знаете ли, какой бы ни была ваша предпочтительная терминология для этого. И они всегда должны быть чем-то, что находится как бы вне поля зрения LLM, в некотором смысле, верно? Переносится вместе, когда ему нужно сделать определенные запросы, но LLM никогда не видит его напрямую, или у него просто есть возможность вызвать этот инструмент, который ваш каркас затем знает, что ему нужно применить этот ключ API, чтобы использовать его.

Да, это, я имею в виду, это так много из этих умственных, знаете ли, не, я не хочу сводить их к советам и трюкам, верно? Как из этих разных подходов, которые вы можете принять, которые, опять же, я думаю, большинство людей просто никогда не думают. Я знаю, что для себя, знаете ли, конечно, я не буду копировать и вставлять свой ключ API в LLM, но, знаете ли, даже, возможно, для моего агента, использование файла N намного хуже, чем не использовать его, верно? Есть всевозможные разные способы подумать об этом. У меня есть еще один вопрос для вас, ребята, чтобы ответить очень быстро, а затем мы завершим трансляцию. Я, я, я уже задержал вас дольше, чем должен. Мы обязательно должны пригласить вас снова. Кстати, в чате так много отличных вопросов. Люди действительно, действительно, я думаю, ценят ваш опыт, но это небольшой вопрос. Вы можете оставить его очень ограниченным. Какой совет вы бы дали развивающимся инновационным экосистемам при ответственном внедрении фреймворков агентских ИИ? Как бы вы дали свой большой, большой общий совет людям, которые пытаются использовать эти инструменты более ответственно, чем раньше, до того, как они посмотрели этот поток? Начнем с Рича. Мы закончим на Эрике сегодня.

Я думаю, лучший совет, который я могу дать, потому что их так много, и они делают так много разных вещей, и все они сконструированы немного по-разному, это действительно стоит сесть и потратить время и как бы подумать о модели безопасности любого фреймворка, любого приложения, чего бы вы ни использовали, чтобы понять, что оно может делать. И тогда стоит потратить немного времени, чтобы как бы представить наихудший сценарий, верно? Так что, если LLM может быть заставлен выдать что-то плохое, верно? Удалить этот файл, скопировать этот файл куда-нибудь еще, отправить этот сетевой запрос, каков ваш наихудший сценарий? И тогда начните думать о том, как вы собираетесь это смягчить. Так что, часто запуск этих вещей в одноцелевых виртуальных машинах, по крайней мере для первоначального тестирования, часто является хорошей идеей. И тогда будьте продуманны и преднамеренны в том, как вы интегрируете их в свой общий рабочий процесс. Эти вещи очень мощные. Мы видели, как они делают действительно крутые вещи внутри компании, но у вас всегда есть небольшое напряжение, которое вам нужно преодолеть, и вам нужно быть продуманным между мощью этих агентских систем с одной стороны и рисками, которые эта мощь налагает на вас с другой. Так что определенно стоит исследовать и стоит подумать, но вы хотите быть осторожными и преднамеренными, когда дело доходит до того, как вы развертываете их и какие возможности вы в них напрямую вкладываете.

Невероятно. И Эрик, тот же самый, точно тот же вопрос.

Да, я хотел бы, чтобы я мог пойти первым, потому что ответ Рича был буквально идеальным. Я пытаюсь придумать что-то другое. Правильно, как с большой силой приходит большая ответственность. Я думаю, одна из вещей, которая является широким советом, который я бы дал кому-то, кто, возможно, не является техническим, верно? Что-то, что можно было бы донести до нетехнических заинтересованных сторон, это лучше сделать правильно, чем сделать быстро с некоторыми из этих вещей. Знаете, я понимаю, что есть много давления, чтобы выпустить вещи, чтобы просто идти, идти, идти, идти, верно? Как будто вы кодируете всю свою компанию за 17 часов. Конечно, хорошо. Но также, может быть, если бы вы взяли, знаете ли, 36 часов, вы бы не оказались под атакой программы-вымогателя через три месяца и не обанкротились бы, верно? Как будто вы просто немного замедляетесь. Я говорю своим детям все время, когда они делают домашнее задание, верно, и они торопятся с математической задачей, которая приводит к неправильным ответам, замедлитесь. Это никуда не денется, верно? Действительно просто подумайте об этом. Знаете, если вы потратите немного больше времени, чтобы сделать то, что предложил Рич, вы будете лучше в долгосрочной перспективе. Невероятные вещи, ребята. Я имею в виду, в чате так много вопросов. В чате так много комментариев. Мне придется связаться с вами, ребята, после трансляции. Большое спасибо, что уделили нам дополнительное время сегодня. Аудитория определенно ценит это. Я ценю, что все смотрят. Спасибо, что присоединились к нам на еще одну трансляцию Neotron Labs во вторник. Еще раз большое спасибо Ричу и Эрику за то, что они были нашими экспертами сегодня. Я знаю, что я многому научился. И кажется, что все, кто смотрел, тоже. Мы будем здесь в следующий вторник, конечно. Мы сделаем демонстрацию голоса. Поговорим с ИИ после того, как мы поговорили о том, как сделать его способами, которыми мы можем думать о более безопасном будущем, по крайней мере. [смех] Хорошо. Большое спасибо всем за просмотр. Увидимся в следующий вторник в 11:00 по тихоокеанскому времени, и хорошей вам недели. До тех пор, до свидания. До свидания всем. Спасибо всем.