Вот честно, я плохо понимаю, что именно нужно написать в промпте, чтобы Клод понаделал таких косяков. Сам сейчас как раз с ним делаю небольшой бэкенд: он всегда включает в план обзор прав доступа, гарантий отсутствия утечек, рекомендации по защите портов и т.п. Иногда советует вещи, о которых я и сам не подумал, и как правило, весьма по делу.
теперь чтобы написать приложение - не нужно много умственных и временных усилий
Времени нужно меньше, да. А вот ума – столько же, если не больше. Именно потому, что ИИ освобождает время для тщательного обдумывания задачи. Фокус сдвигается с чисто технических задач (знание синтаксиса языка, библиотек и протоколов) к проектированию. А оно таки требует ого-го каких умственных усилий.
Более того, я почти уверен, прямого доступа на прод у вас тоже нет и это, конечно, хорошо и правильно. Но, вероятно, он есть у других ваших коллег
Есть. У очень ограниченного числа: админы, релиз менеджер. Больше ни у кого, даже пользовательского – не говоря уж о root. Единственный МСР сервер на проде – читалка логов, больше никакой ИИ там появиться не может. У читалки, естественно, доступ ro, а запись любой сенситивной информации в логи заблокирована другими средствами. Опасности нет.
Соответственно зараженный агент может создать зараженную задачку которую получит кто-то с большими доступами.
Мы вроде с этого начинали. Если у кого-то в команде комп пробит, то это проблема сильно хуже МСР, уже не об этом нужно переживать.
Можно, конечно, бесконечно говорить что у них просто плохая песочница. Но, где гарантии что ваша/наша лучше?
И снова банальный пример: агент написал тест и через HITL просит у вас разрешения его запустить. Вы же не проверяете что именно в этом тесте делается.
Ух. Во-первых, таки проверяю – по крайней мере, если речь о каком-то важном сервисе. Во-вторых (и в главных) – я никогда не запускаю тесты на проде. Тем более, написанные ИИ. А стэйдж – это вообще другая машина, и даже если он там порезвится, ни к каким катастрофическим последствиям это не приведёт. Вот если у вас не так – то это и есть та самая дыра в безопасности, которую нужно срочно закрывать – с МСР или без.
Но сам принцип работает прекрасно и вопрос только в том как подобрать "работающий яд"
Так я всё время именно об этом пишу. Сама возможность подобрать такой "яд" свидетельствует о наличии дыры в защите – которая отнюдь не МСР-специфична, её могли бы эксплуатировать и другие средства проникновения. Скажем, использование OS библиотек гораздо опаснее: там любой апдейт может добавить закладку – примеров хватает. Да, наличие МСР добавляет ещё один вектор атаки – но уязвимости при этом эксплуатируются те же самые, что и в других эксплойтах. Поэтому закрывать нужно именно их, тогда и "отравленный" промпт ничего поделать не сможет.
rm --help НЕ пойдет в интернет и НЕ будет получать описание с удаленного сервера при каждом выполнении
Какая разница? Локально или удалённо, результатом в обоих случаях будет получение описания команды, выполнение которой имеет фатальный эффект на работоспособность системы. Соответственно, и меры, предотвращающие её неавторизованное исполнение в обоих случаях должны быть ровно теми же самыми.
агент при каждом запуске перечитывает описание инструментов
Эмм, и чего? Например, rm --help делает примерно то же самое – но никто ведь не публикует длинных статей о том, как опасно сообщать всем о наличии параметра -rf.
Запретить агенту делать небезопасные действия? А какие действия считать "безопасными"?
Ровно те же, что и при использовании любых других инструментов.
от любого сотрудника имеющего доступ к этой задаче, чье рабочее окружение было скомпрометировано
Боюсь, в случае, если кому-то удалось получить доступ к компам сотрудников, злоумышленник найдёт более эффективные способы добраться до критичных данных или нанести вред, чем инжекции в MCP.
краткая версия:
Проблема не в MCP
Это именно то, о чём я писал: статья полностью (начиная с заголовка) посвящена опасностям, якобы специфичным для использования MCP, тогда как по факту ни одна из них таковой не является. Даже при использовании публичных MCP серверов: не давайте вашему агенту избыточных пермиссий, добавьте в его конфигурацию хуки, запрещающие небезопасные операции и спите спокойно. Ну и разумеется, примите все стандартные меры безопасности, предотвращающие компрометацию внутреннего периметра – включая компы сотрудников. Это в любом случае необходимо, с MCP или без.
Эта статья не претендует на академическую точность
Несомненно. Она вообще ни на какую точность не претендует. Больше похоже на рекомендации не выходить из дома без шапочки из фольги. Вот, например:
Агент прочитал задачу из трекера.
В задаче оказался скрытый текст с заражёнными инструкциями.
Он как туда попал, простите? Таск трекер – внутренний инструмент компании, как туда попала эта зараза? Руководитель проекта так пошутил?
Целиком не осилил, но из прочитанного притянуто за уши буквально всё. Использование МСР серверов с точки зрения безопасности ровно ничем не отличается от любого другого API. Соответственно, если запросы не выходят за границы внутреннего периметра, то для подстановки в них заражённых данных нужно сначала скомпрометировать всю систему.
Еще вчера, когда бизнес не мог без программистов, совсем, они были «программисты», как только стало возможным заменить их на ИИ, сократив издержки, заместо признания фактов а-ля «ИИ умеет программировать», решили уничижительно назвать их «кодерами».
Тут не соглашусь, я всегда проводил границу между теми, кто способен самостоятельно принимать и реализовывать сложные решения, требующие творческого осмысления (программисты), и теми, кто чисто технически переносит тексты спецификаций в код программы (кодеры).
Вот с последней ролью ИИ нынче неплохо справляется – даже отлично уже, я бы сказал. И должен признать, понемногу начинает забираться и на территорию тех самых программистов. Это прогресс буквально за 2-3 года с момента появления первых моделей, способных хоть как-то программировать – как раз примерно тот срок, за который способный джун становится мидлом. Что будет через 10 лет, можно только предполагать – но очень похоже на то, что писать код руками станет просто незачем.
Ну так вы проектный менеджер, а не программист или инженер.
Не совсем так. Я менеджер с бэкграундом инженера, программиста и системного архитектора. Навыки написания кода у меня утрачены за давностью лет, но понимать его я не разучился – равно как и не растерял знаний о том, какой должна быть правильная структура кода. И что, может быть, ещё важнее – я знаю, как управлять разработкой таким образом, чтобы код получался качественным. И эти знания очень помогают получать достойный результат от ИИ в качестве программиста.
Вот я и хочу понять: нужны программисты, или уже нет.
Кодеры – в общем-то, не нужны. Нужны люди с навыками проектирования, которые могут правильно поставить задачу и проверить результат. Такие, как я, например 😁 Не программировал уже лет 20+ – а сейчас спокойно могу в одно лицо делать вполне приличный софт. Не поделки класса hello world – вполне себе серьёзные проекты.
А чего 11-то? Давно уже есть YOLO26, c end2end, который позволяет отказаться от NMS – в результате инференс получается сильно быстрее. У меня на входном потоке 1280*736 средне-нижнего класса телефоны укладываются в бюджет ~250ms, а с 736*480 – <50ms. Для охранной системы потока 2fps более, чем достаточно, причём совершенно не обязательно гнать его постоянно со всех камер: камеры с датчиками движения ныне обыденность.
Нет таких противоречий вообще. Есть team account Claude Code, он всех устраивает. Ловить блох в разнице моделей – непродуктивная трата времени. Ну найдётся какой-то единичный случай, где Codex отработает чуть лучше. Пускай, время дороже, а результат и так устраивает – иначе он ни ревью, ни QA не прошёл бы.
Но AI унификация harness/model уже непосредственно влияет на результат и потому гораздо опаснее.
Ну вот мы и договорились. Отсебятина гораздо опаснее – именно поэтому уровень стандартизации должен быть высоким. Дабы получать неизменно качественный результат, используя проверенные и обкатанные инструменты.
Если конкретная компания умеет закупить всем только одну IDE, но не умеет купить разные лицензии разным разработчикам
Не не умеет, а не хочет. Есть стандарт предприятия, и нет никакой причины его менять из-за капризов программистов. Это как при найме нового токаря каждому покупать его любимый станок.
То же самое и с AI-assisted development: базовые правила едины, а для однотипных задач делаются общедоступные скиллы – дабы каждому не приходилось изобретать их заново, да ещё и со своими отличиями. И программистов такой подход более, чем устраивает: он значительно сокращает количество рутины. А вот составление грамотного описания фичи для передачи ИИ, подготовка критериев готовности и т.п. – работа весьма творческая, всем нравится.
примерно как требовать от всех одну IDE, одинаковые плагины
Разумеется, IDE тоже. Всем покупается по лицензии, а в гит лежит конфигурационный файл – чтобы у всех всё было одинаково. А как иначе? На фига мне, например, гемор с тем, что у одного в IDE два пробела, а у другого таб – и из-за этого каждый коммит меняет сотни файлов? Плагины – дело относительно индивидуальное, а вот линтеры у всех должны быть идентичными – что в разных IDE далеко не всегда возможно.
просто потому, что код в итоге должен одинаково собираться
Озадачен. А зачем мне разработчик, у которого код собирается иначе, чем у других? Он же и работать будет не так, как мне нужно.
Понятно: сначала сами создаёте себе проблемы, а потом пишете статьи о том, что инструмент, отказывающийся поддерживать бардак плох. Унификация окружения – краеугольный камень профессиональной разработки. Иначе через раз будут споры из серии "у меня на компе работает, а что там у вас на проде, понятия не имею, спрашивайте у админов".
кому захочется так работать
У меня буквально всем. И даже мысли ни у кого не возникает, что может быть иначе – кому охота регулярно разбираться, почему явный баг на проде локально не воспроизводится.
Зачем в этой ситуации вообще разные разработчики, достаточно оставить только одного
Если объём работы таков, что один справится – значит, одного. Зачем тогда больше?
Онбординг деградирует до фольклора: «поставь какую‑нибудь модель, настрой какой‑нибудь harness, попробуй такой промпт».
Ну, в командах, где работа действительно организована таким образом, всё вышеуказанное справедливо. Только вот это означает, что там и до ИИ был бардак. Реально нужно делать строго наоборот:
Единая среда разработки. У каждого разработчика поднимается идентичная виртуалка или докер, и код запускается/проверяется только там.
Правила, скиллы, хуки общие, лежат в гит.
Задачи ставятся не промптами, а либо спецификациями в .md (которые тоже лежат в гит), либо прямыми ссылками на тикеты.
Все в команде следуют правилу: за исключением мелких коррекций, агенты никогда не пишут код сразу; сначала уточнённую спецификацию и план исполнения (которые становятся артефактами гит), и только потом код.
Настроен CI пайплайн, включающий в себя ревью независимым агентом.
В конце концов, в команде просто должна быть налажена нормальная коммуникация, обмен знаниями. Когда читаешь статью, складывается впечатление, что каждый программист сидит в своём пузыре, видит только свои тикеты и с другими не общается вовсе.
Если эти условия выполнены, то проблем, подобных описанным в статье, быть не должно вовсе. Разве что вопрос балансировки расхода токенов между разными эккаунтами сохраняется – но по моему опыту, не так уж он и критичен.
Вот честно, я плохо понимаю, что именно нужно написать в промпте, чтобы Клод понаделал таких косяков. Сам сейчас как раз с ним делаю небольшой бэкенд: он всегда включает в план обзор прав доступа, гарантий отсутствия утечек, рекомендации по защите портов и т.п. Иногда советует вещи, о которых я и сам не подумал, и как правило, весьма по делу.
Времени нужно меньше, да. А вот ума – столько же, если не больше. Именно потому, что ИИ освобождает время для тщательного обдумывания задачи. Фокус сдвигается с чисто технических задач (знание синтаксиса языка, библиотек и протоколов) к проектированию. А оно таки требует ого-го каких умственных усилий.
Есть. У очень ограниченного числа: админы, релиз менеджер. Больше ни у кого, даже пользовательского – не говоря уж о root. Единственный МСР сервер на проде – читалка логов, больше никакой ИИ там появиться не может. У читалки, естественно, доступ
ro, а запись любой сенситивной информации в логи заблокирована другими средствами. Опасности нет.Мы вроде с этого начинали. Если у кого-то в команде комп пробит, то это проблема сильно хуже МСР, уже не об этом нужно переживать.
Совершенно разные, изолированные машины
Ух. Во-первых, таки проверяю – по крайней мере, если речь о каком-то важном сервисе. Во-вторых (и в главных) – я никогда не запускаю тесты на проде. Тем более, написанные ИИ. А стэйдж – это вообще другая машина, и даже если он там порезвится, ни к каким катастрофическим последствиям это не приведёт. Вот если у вас не так – то это и есть та самая дыра в безопасности, которую нужно срочно закрывать – с МСР или без.
Так я всё время именно об этом пишу. Сама возможность подобрать такой "яд" свидетельствует о наличии дыры в защите – которая отнюдь не МСР-специфична, её могли бы эксплуатировать и другие средства проникновения. Скажем, использование OS библиотек гораздо опаснее: там любой апдейт может добавить закладку – примеров хватает. Да, наличие МСР добавляет ещё один вектор атаки – но уязвимости при этом эксплуатируются те же самые, что и в других эксплойтах. Поэтому закрывать нужно именно их, тогда и "отравленный" промпт ничего поделать не сможет.
Какая разница? Локально или удалённо, результатом в обоих случаях будет получение описания команды, выполнение которой имеет фатальный эффект на работоспособность системы. Соответственно, и меры, предотвращающие её неавторизованное исполнение в обоих случаях должны быть ровно теми же самыми.
Эмм, и чего? Например,
rm --helpделает примерно то же самое – но никто ведь не публикует длинных статей о том, как опасно сообщать всем о наличии параметра-rf.Ровно те же, что и при использовании любых других инструментов.
Боюсь, в случае, если кому-то удалось получить доступ к компам сотрудников, злоумышленник найдёт более эффективные способы добраться до критичных данных или нанести вред, чем инжекции в MCP.
Это именно то, о чём я писал: статья полностью (начиная с заголовка) посвящена опасностям, якобы специфичным для использования MCP, тогда как по факту ни одна из них таковой не является. Даже при использовании публичных MCP серверов: не давайте вашему агенту избыточных пермиссий, добавьте в его конфигурацию хуки, запрещающие небезопасные операции и спите спокойно. Ну и разумеется, примите все стандартные меры безопасности, предотвращающие компрометацию внутреннего периметра – включая компы сотрудников. Это в любом случае необходимо, с MCP или без.
Несомненно. Она вообще ни на какую точность не претендует. Больше похоже на рекомендации не выходить из дома без шапочки из фольги. Вот, например:
Он как туда попал, простите? Таск трекер – внутренний инструмент компании, как туда попала эта зараза? Руководитель проекта так пошутил?
Целиком не осилил, но из прочитанного притянуто за уши буквально всё. Использование МСР серверов с точки зрения безопасности ровно ничем не отличается от любого другого API. Соответственно, если запросы не выходят за границы внутреннего периметра, то для подстановки в них заражённых данных нужно сначала скомпрометировать всю систему.
Тут не соглашусь, я всегда проводил границу между теми, кто способен самостоятельно принимать и реализовывать сложные решения, требующие творческого осмысления (программисты), и теми, кто чисто технически переносит тексты спецификаций в код программы (кодеры).
Вот с последней ролью ИИ нынче неплохо справляется – даже отлично уже, я бы сказал. И должен признать, понемногу начинает забираться и на территорию тех самых программистов. Это прогресс буквально за 2-3 года с момента появления первых моделей, способных хоть как-то программировать – как раз примерно тот срок, за который способный джун становится мидлом. Что будет через 10 лет, можно только предполагать – но очень похоже на то, что писать код руками станет просто незачем.
Не совсем так. Я менеджер с бэкграундом инженера, программиста и системного архитектора. Навыки написания кода у меня утрачены за давностью лет, но понимать его я не разучился – равно как и не растерял знаний о том, какой должна быть правильная структура кода. И что, может быть, ещё важнее – я знаю, как управлять разработкой таким образом, чтобы код получался качественным. И эти знания очень помогают получать достойный результат от ИИ в качестве программиста.
Кодеры – в общем-то, не нужны. Нужны люди с навыками проектирования, которые могут правильно поставить задачу и проверить результат. Такие, как я, например 😁 Не программировал уже лет 20+ – а сейчас спокойно могу в одно лицо делать вполне приличный софт. Не поделки класса hello world – вполне себе серьёзные проекты.
Так идея, мягко говоря, не новая. Давно уже пользуюсь.
А чего 11-то? Давно уже есть YOLO26, c end2end, который позволяет отказаться от NMS – в результате инференс получается сильно быстрее. У меня на входном потоке 1280*736 средне-нижнего класса телефоны укладываются в бюджет ~250ms, а с 736*480 – <50ms. Для охранной системы потока 2fps более, чем достаточно, причём совершенно не обязательно гнать его постоянно со всех камер: камеры с датчиками движения ныне обыденность.
Нет таких противоречий вообще. Есть team account Claude Code, он всех устраивает. Ловить блох в разнице моделей – непродуктивная трата времени. Ну найдётся какой-то единичный случай, где Codex отработает чуть лучше. Пускай, время дороже, а результат и так устраивает – иначе он ни ревью, ни QA не прошёл бы.
Ну вот мы и договорились. Отсебятина гораздо опаснее – именно поэтому уровень стандартизации должен быть высоким. Дабы получать неизменно качественный результат, используя проверенные и обкатанные инструменты.
Не не умеет, а не хочет. Есть стандарт предприятия, и нет никакой причины его менять из-за капризов программистов. Это как при найме нового токаря каждому покупать его любимый станок.
То же самое и с AI-assisted development: базовые правила едины, а для однотипных задач делаются общедоступные скиллы – дабы каждому не приходилось изобретать их заново, да ещё и со своими отличиями. И программистов такой подход более, чем устраивает: он значительно сокращает количество рутины. А вот составление грамотного описания фичи для передачи ИИ, подготовка критериев готовности и т.п. – работа весьма творческая, всем нравится.
Разумеется, IDE тоже. Всем покупается по лицензии, а в гит лежит конфигурационный файл – чтобы у всех всё было одинаково. А как иначе? На фига мне, например, гемор с тем, что у одного в IDE два пробела, а у другого таб – и из-за этого каждый коммит меняет сотни файлов? Плагины – дело относительно индивидуальное, а вот линтеры у всех должны быть идентичными – что в разных IDE далеко не всегда возможно.
Озадачен. А зачем мне разработчик, у которого код собирается иначе, чем у других? Он же и работать будет не так, как мне нужно.
Понятно: сначала сами создаёте себе проблемы, а потом пишете статьи о том, что инструмент, отказывающийся поддерживать бардак плох. Унификация окружения – краеугольный камень профессиональной разработки. Иначе через раз будут споры из серии "у меня на компе работает, а что там у вас на проде, понятия не имею, спрашивайте у админов".
У меня буквально всем. И даже мысли ни у кого не возникает, что может быть иначе – кому охота регулярно разбираться, почему явный баг на проде локально не воспроизводится.
Если объём работы таков, что один справится – значит, одного. Зачем тогда больше?
Ну, в командах, где работа действительно организована таким образом, всё вышеуказанное справедливо. Только вот это означает, что там и до ИИ был бардак. Реально нужно делать строго наоборот:
Единая среда разработки. У каждого разработчика поднимается идентичная виртуалка или докер, и код запускается/проверяется только там.
Правила, скиллы, хуки общие, лежат в гит.
Задачи ставятся не промптами, а либо спецификациями в
.md(которые тоже лежат в гит), либо прямыми ссылками на тикеты.Все в команде следуют правилу: за исключением мелких коррекций, агенты никогда не пишут код сразу; сначала уточнённую спецификацию и план исполнения (которые становятся артефактами гит), и только потом код.
Настроен CI пайплайн, включающий в себя ревью независимым агентом.
В конце концов, в команде просто должна быть налажена нормальная коммуникация, обмен знаниями. Когда читаешь статью, складывается впечатление, что каждый программист сидит в своём пузыре, видит только свои тикеты и с другими не общается вовсе.
Если эти условия выполнены, то проблем, подобных описанным в статье, быть не должно вовсе. Разве что вопрос балансировки расхода токенов между разными эккаунтами сохраняется – но по моему опыту, не так уж он и критичен.