Не упускает ли пассивное обнаружение то, что поймал бы прокси?

На полностью кооперативных трактах оба подхода сходятся. Прокси видит каждый байт потоков, которые он терминирует, тогда как пассивное обнаружение зависит от телеметрии и журналов аудита, которые отдаёт агент или его хост. Разрыв возникает на некооперативных трактах, которые отдают мало данных. Именно для этого предназначена подстраховка на уровне ядра через eBPF: системный вызов, обращающийся к сокету или файлу, наблюдаем независимо от того, что приложение решило записать в лог. Там, где свидетельств меньше, карта доступа помечает связь как приблизительную, а не атрибутированную, поэтому наблюдение с низкой степенью достоверности никогда не выдаётся за уверенность.

Если коллектор откажет, сломает ли это моих агентов?

Нет. Пассивный коллектор по своей конструкции находится вне тракта запросов: он читает OpenTelemetry, нативные журналы аудита и сигналы ядра вне основного потока и никогда не терминирует и не пересылает трафик агента. Если он остановится, ваши агенты продолжат работать ровно как прежде; вы теряете актуальную видимость до его восстановления, но не продакшен. Эта асимметрия — отсутствие риска для тракта данных в случае сбоя — и есть весь смысл сбора по принципу read-first.

Пассивное обнаружение против прокси: инвентаризация AI-агентов без размещения в тракте данных

Большинство команд приходят к одному и тому же неприятному факту в одном и том же порядке. Сначала они осознают, что AI-агенты уже работают по всей инфраструктуре: вызывают модели, открывают MCP-серверы, обращаются к базам данных и объектным хранилищам. Затем они пытаются их инвентаризировать и обнаруживают, что никакого списка нет. Независимое отраслевое исследование (CSA/Token, n=418) даёт цифры этого разрыва: примерно у 82% организаций работают агенты, о которых им неизвестно, и лишь около 21% ведут инвентаризацию в реальном времени. Прежде чем чем-либо из этого управлять, нужно это увидеть. Вопрос в том, как получить эту видимость, не ухудшив ситуацию.

Есть два честных ответа, и они находятся на противоположных концах спектра рисков.

Два способа увидеть агента

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

Второй — это пассивное обнаружение. Вместо того чтобы стоять в потоке, вы наблюдаете за ним сбоку: OpenTelemetry, который агент уже отдаёт, нативные журналы аудита систем, к которым он обращается (PostgreSQL pgAudit, облачные журналы аудита вроде AWS CloudTrail, аудит Kubernetes), и сигналы уровня ядра через eBPF в качестве подстраховки, отражающей фактическое положение дел. Вы никогда не терминируете соединение. Вы наблюдаете за тем, что произошло, и реконструируете, кто к чему обращался.

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

Радиус поражения — вот настоящая ось

Встроенный прокси по своей конструкции находится в тракте данных. Это даёт управление в реальном времени и обходится вам общим режимом отказа. Если прокси медленный — медленны и ваши агенты. Если он падает, безопасным значением по умолчанию обычно является fail closed, то есть ваши агенты останавливаются, либо fail open, то есть ваш контроль незаметно исчезает в самый неподходящий момент. В любом случае компонент видимости теперь делит радиус поражения с продакшеном. Кроме того, он добавляет хоп задержки к каждому вызову и поверхность развёртывания, которую кто-то должен эксплуатировать, масштабировать и патчить на критическом пути.

У пассивного обнаружения профиль противоположный. Коллектор работает вне основного потока и по принципу read-first: он читает телеметрию, журналы аудита и события ядра; он не пересылает и не переписывает трафик агента. Если он деградирует или умирает, в тракте запросов ничего не меняется. Вы теряете актуальную видимость до его восстановления — не пропускную способность, не доступность. Вот что на практике означает read-first и низкий асимметричный риск: компонент, единственная задача которого — наблюдать, не несёт никакого риска для продакшена.

	Встроенный прокси	Пассивное обнаружение
Позиция	В тракте данных	Вне основного потока, рядом с ним
Блокировка в реальном времени	Нативная	Требует принуждения в точке доступа
Добавленная задержка	Да, на каждый вызов	Нет
При сбое	Агенты зависают или контроль исчезает	Видимость устаревает; на агентов не влияет
Охват «тихих» трактов	Высокий (он терминирует поток)	Зависит от отдаваемых сигналов + подстраховка eBPF

Именно поэтому позиция продукта — отсутствие обязательного прокси, а не «прокси бесполезны». Есть тракты, где встроенный компонент — правильное решение, и они сочетаются с остальным. Но обнаружение — та часть, которой никогда нельзя позволять ронять систему, которую она инвентаризирует, — это неподходящая задача, чтобы навешивать её на критический путь.

Компромисс, изложенный честно

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

Две вещи делают этот факт честным, а не фатальным.

Первая — это подстраховка на уровне ядра через eBPF. Логи приложения могут быть неполными, запаздывающими или, во враждебном сценарии, намеренно подавленными. Ядро нельзя вежливо попросить забыть о системном вызове. Агент, открывающий сокет к базе данных или пишущий файл, оставляет след на границе системного вызова независимо от того, что решило записать его логирование. Это делает eBPF отражающим фактическое положение дел средством против уклонения: когда сигналы более высокого уровня расходятся или замолкают, представление со стороны ядра становится подтверждающим слоем. По этой же причине аннотации MCP-инструментов, такие как readOnlyHint и destructiveHint, при всей их полезности как подсказок, считаются недоверенными согласно спецификации MCP. Инструмент, который заявляет, что работает только на чтение, а наблюдается за записью, — это и есть то расхождение, которое стоит вывести на поверхность, и поймать его можно, только сверив заявление с тем, что произошло на самом деле.

Вторая — это честные уровни достоверности. Не каждое наблюдение заслуживает одинакового веса, поэтому карта доступа и не делает вид, что заслуживает. Связь, подкреплённая сигналом ядра и совпадающей записью аудита, помечается как атрибутированная; связь, выведенная из частичной телеметрии, помечается как приблизительная. Продукт никогда не выдаёт догадку за факт. Проверяющий должен с одного взгляда видеть, насколько доверять каждой строке.

От наблюдения к diff, который имеет значение

Обнаружение — это лишь вход. Выход — это сравнение между PERMITTED, тем, что разрешает политика, и OBSERVED, тем, что коллектор фактически увидел. Этот diff и есть отклонение от least-privilege, и главный случай — это наблюдаемая запись, которую политика никогда не разрешала и которую никто не проверял.

Несколько строк из ленты доступа делают это наглядным. Чтения рутинны; помеченная запись — вот суть истории:

agent             action  resource                outcome   confidence
data-export-job   READ    s3://billing-exports    allowed   attributed
data-export-job   READ    prod-postgres           allowed   attributed
data-export-job   WRITE   prod-postgres           flagged   attributed
support-rag       READ    internal-wiki-mcp       allowed   approximate

Задание экспорта, читающее продакшен-базу данных, ничем не примечательно. То же задание, пишущее в неё, когда политика когда-либо разрешала только чтение, — это та связь, которая никогда не должна проходить без проверки. Поскольку запись подтверждена на границе ядра, она помечена как attributed, а не как осторожная оговорка.

Увидеть отклонение — половина работы; устранить его — вторая половина. Принуждение должно жить в точке доступа, выраженное как policy-as-code, чтобы правило поддавалось проверке, а на нарушение реагировали, а не просто его логировали:

policy "data-export-readonly" {
  agent        = "data-export-job"
  resource     = "prod-postgres"
  allow        = ["read"]
  deny         = ["write"]
  on_violation = "block + alert"
}

Пассивное обнаружение находит неразрешённую запись; политика возвращает агента к least-privilege и блокирует следующую. Видимость и контроль остаются отдельными задачами, и именно поэтому слой обнаружения может позволить себе работать по принципу read-first.

Вывод

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

Если вам нужна полная картина того, как коллекторы, карта доступа и журнал аудита складываются вместе, обзор архитектуры проводит по этому пути от начала до конца.