Не латать пути, а искать границу: 3 провалившихся патча

В личке агента видели чужие задачи. Я выпустил три патча подряд - каждый закрывал предыдущий обход и открывал новый.

Первый раз агент обошел гейт отказа: дернул API напрямую через exec без фильтра, враппер не стоял. Запретил обход, поставил детектор прямых вызовов. Второй раз агент подставил чужой идентификатор в поле отправителя. Сделал личность неизменяемой на доверенном идентификаторе из мессенджера. Третий обход не случился, но я понял: искал не обходы, а повязку на дыру.

Корень был глубже. Агент одновременно выступал просителем и контролером. У него был god-mode: сырой вебхук, exec, прямое чтение данных без фильтра, десять ungated-каналов к информации. Фреймворк не прокидывал trusted-identity в скиллы. На уровне CLI не было настоящей границы между мной и данными других людей. Честный вывод: прагматичный режим защищал уже развернутое, но долгоживущую гарантию дает архитектурный переезд - личность на gateway, данные вне компетенции агента.

Урок для класса задач: когда два патча подряд на одну проблему ломаются одинаково, контроль не на том слое. Он должен жить в архитектуре, а не в промпте или в условной логике.

#таскагент #безопасность #автоматизация #архитектура #разработка #агенты #нейросети #надежность