Ещё один слой обычно уже куплен: существующие средства предотвращения утечек подключаются к инструменту тремя способами. Агент на устройстве смотрит исходящий трафик к доменам сервиса и блокирует или сигналит по своим правилам - он ничего не знает про смысл работы, зато действует и там, где обработчики не настроены, и оплачивается задержкой на проверке трафика. Собственная логика в обработчиках проверяет запрос до отправки модели и сгенерированный код до записи на диск. Вызов из обработчика внешнего сервиса поставщика даёт решение по его ответу - и это ровно та сетевая зависимость, которая при обрыве оставляет проверку без вердикта. Рядом стоит ограничение источников для браузера: список разрешённых доменов, за пределы которого переход агента блокируется.

Отдельно нужно повторить сказанное про режимы: вероятностный классификатор не является границей безопасности. Он полезен как регулятор автономности по умолчанию - снимает рутинные подтверждения там, где риск невелик, и тем самым сохраняет внимание человека для случаев, где оно нужно. Но секреты, разрушительные команды и регулируемые области защищают детерминированными средствами и внешней изоляцией, а не оценкой, потому что оценка ошибается тихо и на редких входах.

Эта фраза кажется очевидной, пока не увидишь конфигурацию, где вся защита держится на режиме с проверкой. Она выглядит аккуратно, работает большую часть времени и рассыпается ровно тогда, когда содержимое репозитория, страницы или ответа внешнего сервера окажется специально составленным, то есть в единственном случае, ради которого защита и строилась. Слой оценки хорош вместе с жёсткими границами и плох вместо них.

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

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

Типичные провалы предсказуемы. Строить защиту на одном слое, обычно на режиме с проверкой. Оставить чувствительные репозитории в области видимости, ограничившись правилами. Сделать критичный обработчик зависимым от сети и получить пропускающий режим при обрыве. Не проверить обработчики в режиме блокировки. И не отработать канареечное обновление и откат.