Большинство команд приходят к одному и тому же неприятному факту в одном и том же порядке. Сначала они осознают, что AI-агенты уже работают по всей инфраструктуре: вызывают модели, открывают MCP-серверы, обращаются к базам данных и объектным хранилищам. Затем они пытаются их инвентаризировать и обнаруживают, что никакого списка нет. Независимое отраслевое исследование (CSA/Token, n=418) даёт цифры этого разрыва: примерно у 82% организаций работают агенты, о которых им неизвестно. Прежде чем чем-либо из этого управлять, нужно это увидеть. Вопрос в том, как получить эту видимость, не ухудшив ситуацию.
Есть два честных ответа, и они находятся на противоположных концах спектра рисков.
Два способа увидеть агента
Первый — это встроенный прокси. Вы направляете трафик агента через компонент, который контролируете, и поскольку каждый запрос и ответ проходит через него, вы можете видеть, формировать и блокировать в реальном времени. Это легитимная, мощная архитектура. Именно так сегодня реализуется значительная часть фильтрации исходящего трафика, брокеринга секретов и политик на уровне запросов.
Второй — это пассивное обнаружение. Вместо того чтобы стоять в потоке, вы наблюдаете за ним сбоку: OpenTelemetry, который агент уже отдаёт, нативные журналы аудита систем, к которым он обращается (PostgreSQL pgAudit, облачные журналы аудита вроде AWS CloudTrail, аудит Kubernetes), и сигналы уровня ядра через eBPF в качестве подстраховки, отражающей фактическое положение дел. Вы никогда не терминируете соединение. Вы наблюдаете за тем, что произошло, и реконструируете, кто к чему обращался. Захват на уровне ядра обеспечивает сенсор Tetragon, который вы разворачиваете сами; Olivares AI читает экспорт Tetragon и сам не загружает программы eBPF.
Принципиальная разница не в том, сколько каждый из подходов способен увидеть в лучшем случае. Она в том, что происходит, когда отказывает сам слой видимости.
Радиус поражения — вот настоящая ось
Встроенный прокси по своей конструкции находится в тракте данных. Это даёт управление в реальном времени и обходится вам общим режимом отказа. Если прокси медленный — медленны и ваши агенты. Если он падает, безопасным значением по умолчанию обычно является fail closed, то есть ваши агенты останавливаются, либо fail open, то есть ваш контроль незаметно исчезает в самый неподходящий момент. В любом случае компонент видимости теперь делит радиус поражения с продакшеном. Кроме того, он добавляет хоп задержки к каждому вызову и поверхность развёртывания, которую кто-то должен эксплуатировать, масштабировать и патчить на критическом пути.
У пассивного обнаружения профиль противоположный. Коллектор работает вне основного потока и по принципу read-first: он читает телеметрию, журналы аудита и события ядра; он не пересылает и не переписывает трафик агента. Если он деградирует или умирает, в тракте запросов ничего не меняется. Вы теряете актуальную видимость до его восстановления — не пропускную способность, не доступность. Вот что на практике означает read-first и низкий асимметричный риск: компонент, единственная задача которого — наблюдать, не несёт никакого риска для продакшена.
| Встроенный прокси | Пассивное обнаружение | |
|---|---|---|
| Позиция | В тракте данных | Вне основного потока, рядом с ним |
| Блокировка в реальном времени | Нативная | Требует принуждения в точке доступа |
| Добавленная задержка | Да, на каждый вызов | Нет |
| При сбое | Агенты зависают или контроль исчезает | Видимость устаревает; на агентов не влияет |
| Охват «тихих» трактов | Высокий (он терминирует поток) | Зависит от отдаваемых сигналов + подстраховка eBPF |
Именно поэтому позиция продукта — отсутствие обязательного прокси, а не «прокси бесполезны». Есть тракты, где встроенный компонент — правильное решение, и они сочетаются с остальным. Но обнаружение — та часть, которой никогда нельзя позволять ронять систему, которую она инвентаризирует, — это неподходящая задача, чтобы навешивать её на критический путь.
Компромисс, изложенный честно
У пассивного обнаружения есть подлинная слабость, и притворяться обратным было бы той разновидностью соломенного чучела, из-за которой архитектуре тихо перестают доверять. Прокси, терминирующий поток, видит каждый его байт. Пассивный коллектор видит лишь то, что решили отдать агент, его рантайм или ресурс. На полностью некооперативном тракте — таком, который мало логирует и не отдаёт полезной телеметрии, — обнаружение на уровне приложения истончается. Можно сделать вывод, что что-то произошло, но с атрибуцией становится сложнее.
Две вещи делают этот факт честным, а не фатальным.
Первая — это подстраховка на уровне ядра через eBPF. Логи приложения могут быть неполными, запаздывающими или, во враждебном сценарии, намеренно подавленными. Ядро нельзя вежливо попросить забыть о системном вызове. Агент, открывающий сокет к базе данных или пишущий файл, оставляет след на границе системного вызова независимо от того, что решило записать его логирование. Это делает eBPF отражающим фактическое положение дел средством против уклонения: когда сигналы более высокого уровня расходятся или замолкают, представление со стороны ядра становится подтверждающим слоем. По этой же причине аннотации MCP-инструментов, такие как readOnlyHint и destructiveHint, при всей их полезности как подсказок, считаются недоверенными согласно спецификации MCP. Инструмент, который заявляет, что работает только на чтение, а наблюдается за записью, — это и есть то расхождение, которое стоит вывести на поверхность, и поймать его можно, только сверив заявление с тем, что произошло на самом деле.
Вторая — это честные уровни достоверности. Не каждое наблюдение заслуживает одинакового веса, поэтому карта доступа и не делает вид, что заслуживает. Связь, источник которой несёт идентичность отдельного агента, например кооперативный OpenTelemetry с идентификатором агента или журнал аудита, где у агента есть собственная роль в базе данных, помечается как атрибутированная. Связь, выведенная из частичной телеметрии, и любая связь, которую видит только ядро, помечается как приблизительная, потому что сигналы ядра называют процесс, cgroup или контейнер, а не агента. Продукт никогда не выдаёт догадку за факт. Проверяющий должен с одного взгляда видеть, насколько доверять каждой строке.
От наблюдения к 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 approximate
support-rag READ internal-wiki-mcp allowed approximateЗадание экспорта, читающее продакшен-базу данных, ничем не примечательно. То же задание, пишущее в неё, когда политика когда-либо разрешала только чтение, — это та связь, которая никогда не должна проходить без проверки. Ядро подтверждает, что запись произошла, но называет процесс или контейнер, а не агента, поэтому эта связь помечена как approximate.
Увидеть отклонение — половина работы; устранить его — вторая половина. Принуждение должно жить в точке доступа, выраженное как policy-as-code, чтобы правило поддавалось проверке. Olivares AI вычисляет Cedar как наложение forbid поверх ролей с запретом по умолчанию, поэтому правило может только отнимать доступ; это правило отклоняет любой запрос, затрагивающий секретные учётные данные, что бы ни говорила роль.
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };Писать собственные правила Cedar можно в редакции Business; Community применяет встроенные роли, встроенный слой запретов и kill switch, а пользовательские роли и ограниченные по области гранты относятся к Business.
Пассивное обнаружение находит неразрешённую запись, а карта доступа помечает её как дрейф. Olivares AI блокирует действие только в четырёх точках применения: внутри Claude Code, в прокси моделей, при каждом вызове инструмента MCP и между агентами. Запись, которая проходит через одну из них и которую роль агента не разрешает, отклоняется до выполнения и попадает в подписанный журнал аудита, защищённый от подделки; прямая запись в базу данных наблюдается, но не блокируется. Видимость и контроль остаются отдельными задачами, и именно поэтому слой обнаружения может позволить себе работать по принципу read-first.
Вывод
Видимость AI-агентов — это решение о рисках прежде, чем решение о функциональности. Встроенный прокси даёт вам управление в реальном времени ценой общего радиуса поражения с продакшеном. Пассивное обнаружение жертвует частью охвата на «тихих» трактах в обмен на принципиальную неспособность уронить продакшен, а затем закрывает большую часть этого охвата подстраховкой eBPF, отражающей фактическое положение дел, и уровнями достоверности, которые остаются честными в отношении того, что было увидено на самом деле. Для инвентаризации — слоя, чья единственная задача — наблюдать, — эта асимметрия и есть правильное значение по умолчанию.
Если вам нужна полная картина того, как коллекторы, карта доступа и журнал аудита складываются вместе, обзор архитектуры проводит по этому пути от начала до конца.