Каталог коннекторов и уровни покрытия

Эта страница — каталог первичных (first-party) коннекторов и, для каждого, честный уровень покрытия, который он способен поддерживать. Она дополняет подключение источника, где объясняется модель коннектора (только наблюдение, минимум данных, три вида наблюдения) — прочитайте её сначала. Эта страница отвечает на следующий вопрос: какие источники существуют и насколько хорош сигнал каждого из них?

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

Cooperative — агент или платформа, сообщающие о том, что они сделали (OpenTelemetry, административный API поставщика). Наивысшая точность при наличии; зависит от того, сотрудничает ли источник.
Clean — хранилище, которое классифицирует чтение и запись нативно, взятое дословно из его собственного аудиторского следа (SQL-аудит, журналы доступа к данным объектного хранилища / хранилища данных).
Lossy — хранилище, аудит которого не может чисто отделить чтение от записи или одного вызывающего от другого (хранилища документов, lineage). Рёбра фиксируются, но часто как approximate.
Impossible passively — система без пригодной пассивной аудиторской поверхности (in-memory-кэши, встроенные однофайловые базы данных). Здесь нет честного сигнала «чтение прежде всего»; продукт не делает вид, что это не так.
Approximate-by-attribution — доступ реален, но атрибуция приписана роли, процессу или общей учётной записи, а не разрешённому агенту, поэтому ребро является approximate.
Untrusted hint — заявленная возможность (аннотация инструмента MCP), подтверждаемая перекрёстно, но никогда не принимаемая на веру в одиночку.

Здесь перечислены коннекторы, зарегистрированные в наборе коннекторов бинарного файла по умолчанию на сегодня — то есть виды, которые вы можете указать в OLIVARES_SOURCES_CONFIG и подключить движком. Продукт находится в стадии до 1.0. Канонические коннекторы R/RW access-map — pgAudit, S3/CloudTrail, подстраховка eBPF/Tetragon, инвентаризация runtime и интроспекция MCP — а также источники документов знаний теперь подключены и настраиваемы в стандартном serve; некоторые из них несут требования к развёртыванию (сенсор Tetragon, доступ к хосту), описанные в разделе Требования к развёртыванию ниже. Покрытие честно разбито на уровни: присутствие коннектора здесь не является утверждением о твёрдой атрибуции на уровне агента, которая остаётся жёсткой зависимостью (общая учётная запись низводит даже хранилище уровня clean до approximate).

Режим процесса для каждого вида

Каждый вид работает ровно в одном режиме процесса, заданном движком:

Внепроцессный плагин. Движок встраивает коннектор как отдельную программу, запускает её как изолированный дочерний процесс (ограниченное окружение; выделенный пользователь и cgroup там, где хост это допускает) и общается с ней по gRPC с AutoMTLS. Деревья зависимостей этих коннекторов никогда не линкуются с движком. Виды источников: claude, cowork, kafka, amqp, nats, mqtt, cloudqueue, debezium, envoy и hubble. Виды получателей: kafka, amqp и cloudqueue. Сборка без task build:connectors не встраивает их, и при запуске движок предупреждает о каждом настроенном таком коннекторе.
Внутрипроцессный. Все остальные виды на этой странице. Коннектор линкуется с бинарником движка и работает в его процессе; паника в коннекторе локализуется, а источник получает статус failed.
Внешний плагин. Источник или получатель, настроенный через plugin (путь к бинарнику, закреплённый digest и подпись, проверенная по connector_trust), всегда работает вне процесса с такой же изоляцией. Программы connectors/<kind>/cmd/ для внутрипроцессных видов в репозитории не входят в релиз; соберите и допустите такую программу как плагин, чтобы запустить этот коннектор в собственном процессе.

При гибели процесса плагина источника движок снова запускает тот же бинарник, повторно проверяет закреплённый digest внешнего плагина, открывает его с настройками источника и возобновляет сбор. Первый перезапуск ждёт около секунды; ожидание удваивается при каждом следующем перезапуске до пяти минут и возвращается к секунде после пяти минут работы плагина. От обнаружения погибшего процесса до запуска нового источник сообщает failed, с ошибкой перезапуска при неудачной попытке.

Плагин получателя перезапускается аналогично, когда доставка не удалась и процесс оказался погибшим: движок снова запускает бинарник (повторно проверяя закреплённый digest внешнего плагина) и открывает его с настройками получателя. Доставка, обнаружившая погибший плагин, всё равно отмечается как неудачная, с ошибкой перезапуска, если он был отклонён; её повторяет механизм повторных уведомлений, теперь обращающийся к новому процессу. Первый перезапуск немедленный; следующие попытки ждут одну секунду с удвоением до пяти минут, а цикл начинается заново, если с последней попытки прошло более пяти минут. Получатель без доставок не перезапускается до появления доставки.

Перезапущенный плагин открывается с теми настройками, с которыми был открыт его коннектор, поэтому изменённый или ротированный секрет попадёт в него при перезагрузке конфигурации или перезапуске движка, как и в плагин, который не погибал.

Плагин с живым процессом, у которого не удаётся сбор или доставка, не перезапускается: это собственная ошибка коннектора.

Cooperative — телеметрия Claude и поставщиков

Источники наивысшей точности при их наличии. Источник среды выполнения Claude Code работает вне процесса как встроенный плагин (обычная dev-сборка опускает его, и загрузка честно выдаёт предупреждение, а не выглядит исправной).

Вид	Наблюдает	Примечания
`claude`	Телеметрия инструментов Claude Code OTLP + интроспекция MCP → рёбра / стоимость / находки	Плагин вне процесса; `attributed` при наличии идентичности на уровне агента, иначе `approximate`
`claude-api`	Образцы стоимости Claude Admin-API + находки о состоянии управления	В процессе; no-op в офлайне (нет административного ключа)
`claude-compliance`	Доказательства из ленты активности Claude Compliance → находки	Только GET по построению; no-op в офлайне (Business)
`claude-config`	Статическое дерево конфигурации Claude (субагенты / Skills / плагины) → рёбра заявленной возможности	Только метаданные — поверхность возможностей, а не наблюдаемый доступ
`claude-console`	IAM организации Claude → находки о состоянии SSO/SCIM (реестр идентичностей + источник)	Business: Identity & Scale;
`claude-wif`	Реестр нечеловеческих идентичностей / рабочих идентичностей Anthropic + рёбра разрешённой области	Business: Identity & Scale; Моделирует объявленную оператором федерацию; помечает риски статических ключей
`claude-managed-agents`	Инвентарь управляемых агентов Claude + события потоков (приёмник webhook + GET-опросчики)	Потоковый источник (`poll_seconds: 0`); в офлайне no-op
`claude-projects`	Инвентарь проектов организации Claude (участники / API-ключи) + объявленная оператором политика проектов	Admin API только для чтения; в офлайне no-op
`claude-apps-gateway`	Состояние Claude apps gateway, объявленные гранты моделей и ingest событий аудита → топология + находки	Читает существующий `gateway.yaml` и необязательный JSONL-экспорт аудита
`claude-batch`	Инвентарь Anthropic Message Batches + Files API, принуждение batch-политик, истечение хранения загрузок	Никогда не читает payload или содержимое файла; без admin-ключа выдаёт честную offline-находку
`claude-routines`	Инвентарь Claude Code Routines (плановые триггеры) → рёбра + находки по cadence/review	Только GET; содержимое prompt только хешируется; потоковый (`poll_seconds: 0`)
`cowork`	Приёмник журналов Claude Cowork OTLP/HTTP → свидетельства активности	Внепроцессный плагин (изоляция зависимости OTel-proto)
`cowork-analytics`	Аналитика вовлечённости Claude Cowork	В процессе (только клиент modelprovider)
`codex`	Образцы стоимости OpenAI Codex, свидетельства usage/auth/admin-аудита, находки adoption	Admin API только для чтения; закрытые тарифом поверхности деградируют до находки состояния
`cursor`	Стоимость по счетам Cursor Admin API, журналы аудита команды, инвентарь участников, состояние бюджета	Закрытые тарифом `403`/`404` деградируют до находки, никогда не приводят к сбою

Нейтральный к поставщику профиль GenAI-фреймворков (`gen_ai.*`) — opt-in

Агентные фреймворки, которые обещает каталог — LangGraph / LangChain, CrewAI, AutoGen / Microsoft Agent Framework, Google ADK (а также OpenAI SDK, LlamaIndex, Pydantic-AI, Strands, …) — не эмитят схему Claude claude_code.*. Они сходятся на семантических соглашениях OpenTelemetry GenAI (gen_ai.*). Тот же источник claude принимает и этот профиль, так что OTel-инструментированный парк питает access map и FinOps через один приёмник, а не через отдельный коннектор на каждый фреймворк — интеграция с наибольшим рычагом.

Этот профиль является OPT-IN и честно помечен как экспериментальный. Вся область gen_ai имеет статус OpenTelemetry Development (не Stable, июнь-2026), поэтому она активируется только когда вы воспроизводите собственный гейт спецификации. Установите в semconv_opt_in коннектора список через запятую, содержащий токен gen_ai_latest_experimental (зеркало OTEL_SEMCONV_STABILITY_OPT_IN). Выключенный по умолчанию, сигнал gen_ai.* всё равно питает сторожевой таймер тишины, но не отображает ни ребра, ни стоимости — мы никогда не заявляем стабильность, которой у соглашений нет.

Поскольку соглашения находятся в процессе изменений, приёмник двухимённый (он читает текущий ключ и устаревшего предшественника, всё ещё встречающегося в реальном мире) и многосигнальный (он отображает трассировочные spans, лог-событие gen_ai.client.inference.operation.details и распознаёт клиентские метрики):

Что он читает	Текущий ключ	Также принимается (устаревший, всё ещё эмитируется)
Поставщик	`gen_ai.provider.name`	`gen_ai.system` (по умолчанию для v1.36.0-или-ранее; Google ADK, напр. `gcp.gemini`)
Входные токены	`gen_ai.usage.input_tokens`	`gen_ai.usage.prompt_tokens` (OpenLLMetry/Traceloop → LangChain/LangGraph/CrewAI)
Выходные токены	`gen_ai.usage.output_tokens`	`gen_ai.usage.completion_tokens` (то же)

Атрибут gen_ai	отображается в	уверенность
`gen_ai.usage.*` (токены)	`CostSample` (происхождение estimated — токены, а не выставленная стоимость)	—
`gen_ai.provider.name` / `request.model` / `response.model`	поставщик стоимости + модель (предпочтительно response)	—
`gen_ai.operation.name = execute_tool` + `gen_ai.tool.name`	ребро доступа агент→инструмент (режим `unknown`)	`attributed`
`gen_ai.conversation.id` + `gen_ai.agent.{name,id}`	ребро атрибуции беседа→агент + ссылка на сессию	`attributed`

Матрица поддерживаемых диалектов (нормализатор нескольких поколений)

Соглашения GenAI менялись в трёх сосуществующих поколениях в реальных парках 2026 года. Приёмник определяет поколение для каждого сигнала по эксклюзивным для поколения маркерам и штампует нормализованное событие соответствующим пином semconv (находка о состоянии genai.semconv записывает активный набор за запуск; одна информационная находка drift за запуск помечает каждый увиденный устаревший диалект, чтобы вы знали, каким паркам нужно обновить инструментацию). Содержимое сообщений никогда не читается ни из одного поколения — ключи содержимого выступают только как маркеры диалекта (состояние минимума данных).

Обнаруженный диалект	Поставленный пин	Эксклюзивные маркеры (проверено)	Эмитируется (проверено июнь-2026)
Устаревший OpenLLMetry/Traceloop (до semconv)	`openllmetry`	индексированные `gen_ai.prompt.{i}.` / `gen_ai.completion.{i}.`, `gen_ai.usage.prompt_tokens`/`completion_tokens`, `llm.usage.total_tokens`, `llm.request.type`, `llm.vendor`, `traceloop.span.kind`	Traceloop-инструментированные LangChain / LangGraph / CrewAI, закреплённые < openllmetry v0.55.0 (выпущена 2026-03-29). Поставщики с заглавной буквы (`OpenAI`, `Langchain`) приводятся к нижнему регистру, чтобы FinOps не разделял по регистру
События v1.36-или-ранее (собственное имя спецификации)	`1.36.0`	`gen_ai.system`; пять лог-событий на сообщение `gen_ai.{system,user,assistant,tool}.message`, `gen_ai.choice` (распознаются по имени — их единственный атрибут необязателен)	LLM-spans Google ADK (`gcp.vertex.agent`), AutoGen (`autogen`), Microsoft Agent Framework — все ещё эмитят `gen_ai.system`
Сообщения v1.37+ (текущие)	`1.41.1`	`gen_ai.provider.name`, `gen_ai.input.messages` / `gen_ai.output.messages` / `gen_ai.system_instructions`, событие `gen_ai.client.inference.operation.details`, `gen_ai.workflow.name`	Официальные инструментации OTel; openllmetry ≥ v0.55.0

Сигнал, несущий только ключи, чьи имена идентичны во всех поколениях (напр., ADK-span invoke_agent: операция + агент + беседа, вообще без ключа поставщика), нормализуется под текущим пином — применяемое отображение байт-идентично, а реальный релиз производителя невозможно узнать из протокола передачи.

Соглашения MCP (`mcp.*`, semconv v1.39 — Development)

Вверху по течению существует ровно четыре атрибута mcp.* (mcp.method.name, mcp.protocol.version, mcp.resource.uri, mcp.session.id); инструмент едет на gen_ai.tool.name, а промпт — на gen_ai.prompt.name. Приёмник объединяет эти трассировки с собственными фактами управления MCP продукта, повторно используя те же виды ресурсов, что эмитирует путь Claude:

Сигнал MCP	отображается в
любой клиентский span `mcp.*` с `server.address`	ребро сессия→`mcp.server` (объединяется с рёбрами `claude_code.mcp_server_connection`)
`tools/call` + `gen_ai.tool.name`	ребро доступа `mcp.tool` (`server.address/tool`, когда конечная точка известна) — тот же вид, что вызовы Claude `mcp__server__tool`
`resources/read` / `resources/subscribe` + `mcp.resource.uri`	ребро `mcp.resource` в режиме чтения (URI санитизирован: учётные данные/запрос удалены)
`prompts/get` + `gen_ai.prompt.name`	ребро `mcp.prompt` в режиме чтения (поверхность промптов)
spans вида SERVER / метрики `mcp.client	server.*.duration`

Spans агентов (разделение `invoke_agent` client/internal + `invoke_workflow`, semconv v1.41 — Development)

v1.41.0 разделила invoke_agent на вариант CLIENT (удалённая агентная служба) и вариант INTERNAL (в процессе). Реальные фреймворки сегодня нарушают этот вид (AutoGen и Microsoft Agent Framework жёстко прописывают CLIENT для агентов в процессе; Google ADK использует INTERNAL), поэтому приёмник классифицирует вызов как удалённый только когда span — CLIENT и несёт server.address — это даёт ребро делегирования беседа→genai.agent.remote. Всё остальное остаётся вызовом в процессе, охваченным ребром атрибуции беседа→genai.agent: чисто деградировано, никогда не сфабрикованное «удалённое». invoke_workflow (новое в v1.41; команды в стиле CrewAI) отображает ребро беседа→genai.workflow. Spans агентов остаются вверху по течению Development (экспериментальными) — никакая стабильность не заявляется.

Стабильное против экспериментального, честно: механизм (гейт opt-in, обнаружение диалекта + двухимённые чтения, отображение span/event/metric, запечатанные формы CostSample/EdgeObservation) стабилен в этом продукте. Словарь, который он отображает (ключи gen_ai.*/mcp.*, перечисление операций), вверху по течению имеет статус Development и может снова переименоваться; именно поэтому приёмник нормализует каждое поколение, а не закрепляет одно. v1.41.1 — последний версионированный релиз соглашений gen-ai (они переехали в open-telemetry/semantic-conventions-genai, у которого по состоянию на июнь-2026 нет релизов). Примечания:

Стоимость дедуплицируется по идентификатору W3C span. Когда одна операция сообщает об использовании как на своём span, так и в своём событии operation.details (они делят один span id), она тарифицируется один раз, а не дважды.
Метрики питают живучесть, никогда — стоимость. gen_ai.client.token.usage — это агрегат; span/event является авторитетным использованием на уровне операции, поэтому тарификация и метрики тоже привела бы к двойному счёту. Гистограммы длительности mcp.* v1.39 распознаются тем же образом.
Поставщик может быть unknown. Если span несёт модель, но не поставщика/систему, стоимость атрибутируется unknown, а не угадывается из идентификатора модели.
Счёт только общего числа токенов не разделяется. Устаревший llm.usage.total_tokens без разделения на prompt/completion никогда не угадывается в input/output (без сфабрикованной стоимости).
OpenInference (Arize/Phoenix) — другое соглашение и не принимается этим профилем — читаемые здесь ключи llm.* (llm.request.type, llm.usage.total_tokens, llm.vendor) являются устаревшими маркерами OpenLLMetry, а не пространством имён llm.* от OpenInference.

Cooperative — локальная конфигурация agent-surface

Эти источники читают объявленную локальную конфигурацию агента и эмитят permitted- рёбра и находки состояния. Это не живые трассы исполнения; если у фреймворка есть нативный OTEL, живое использование по-прежнему поступает через ingest gen_ai.* выше.

Вид	Наблюдает	Честное покрытие
`opencode`	Локальные слои JSONC `opencode.json` / `opencode.jsonc` → состояние permission и managed/admin override, разрешённые рёбра MCP/tool/custom-agent, находки credential-in-config/share/autoupdate/OTEL и фрагмент для авторинга	Только объявленная конфигурация. Managed-слой обнаруживается локально, но это не неизменяемый замок: runtime `OPENCODE_PERMISSION`, перенаправление каталога тестов и удалённая конфигурация организации остаются вне этого читателя. Нативный OTEL может подавать живое использование `gen_ai.` через out-of-band-экспортёр `OTEL_`
`gemini-cli`	Слои `settings.json` Gemini CLI (system/user/workspace) → разрешённые рёбра MCP/tool, состояние пробелов принуждения, инвентарь эффективной конфигурации	Только объявленная конфигурация; живое использование идёт через ingest `gen_ai.*` (CLI эмитит его нативно). Не Gemini API (это поверхность hosted-provider)
`openhands`	`config.toml` OpenHands + env → состояние sandbox/model-pinning/credential/telemetry, разрешённые рёбра MCP/action	Только объявленная конфигурация; живое использование через нативный OTEL `gen_ai.*`
`goose`	`profiles.yaml` Goose (Block) + env → состояние admin-settings/model-pinning/extension/tool-approval, разрешённые рёбра extensions	Только объявленная конфигурация
`cline`	Пространства имён Cline / Kilo Code в VSCode `settings.json` → состояние auto-approve/MCP-allowlist/credential/model-pinning	Только объявленная конфигурация; upstream не имеет нативного OTEL
`grok`	Grok Build (xAI), терминальный агент для программирования: локальная конфигурация, подключение хуков, события с документированной поддержкой запрета и объявленное состояние управления	Объявленное конфигурацией состояние агента. Коннектор API `xai` читает каталог моделей и стоимость, включая `grok-build-0.1` как модель; этот коннектор читает агента. Живое наблюдение использует ingest OTLP, который эмитирует Grok Build. `PostureEnforced` применяется только к `PreToolUse`, единственному событию с документированной поддержкой запрета; остальные события — `observed`
`openclaw`	`openclaw.json` OpenClaw (обнаружение JSON5, ограниченный `$include`) → состояние gateway/channel/tool/sandbox/skill/model по агенту, объявленные рёбра channel/skill/model	Только объявленная конфигурация; inline PEP hook upstream не подтверждён
`hermes`	`config.yaml` Hermes Agent + деревья профилей + managed scope → состояние terminal/channel/skill/security/model/MCP, объявленные рёбра	Только объявленная конфигурация; inline PEP hook и нативный OTEL upstream не подтверждены
`paperclip`	REST API Paperclip (API-ключ board, только GET) → компании как коллекции групп и агенты как записи roster NHI (`paperclip/<adapterType>`, роль, должность, `reports_to`), число запусков за завершённый день, рекомендательные образцы стоимости (`cost_type=paperclip`)	Только наблюдение: не запускает и не изолирует агентов Paperclip. Стоимость — суточный агрегат, потому что Paperclip не предоставляет список отдельных событий стоимости; отклонённая часть сбора сообщается как находка о покрытии
`google-adk`	Экспортированный JSON Session Google ADK 2.0 → инвентарь agent/app, sub-agents, вызовы tool-функций, передачи, дрейф approved-tool, корреляция Vertex reasoningEngine	Экспорт только для чтения; никогда содержимое сообщений. Отличается от платформенной поверхности `google-agent`
`agents-md`	Обход репозитория по файлам инструкций агентов (AGENTS.md и файлы памяти/инструкций каждого агента) → дрейф базовой линии SHA-256 + скан instruction-injection / hidden-Unicode / секретов	Минимальные данные: очищенные пути + хешированные детали, никогда содержимое
`mcpb`	Установленные / распространённые desktop-расширения `.mcpb` → скан состояния манифеста, дрейф enterprise-allowlist, проверка подписи PKCS#7	PERMITTED-vs-OBSERVED на поверхности расширений
`codex-managed-config`	Файлы managed-config OpenAI Codex → состояние принуждения + дрейф относительно авторской базовой линии	Только наблюдение: не может остановить разработчика, обходящего managed-слой (зеркало `managed-settings` для Codex)

Clean — нативный аудит хранилища (чтение/запись дословно)

Эти коннекторы читают собственный аудиторский след хранилища и берут классификацию чтение/запись дословно — никогда не выводя её из текста запроса. pgaudit и s3cloudtrail — канонические источники R/RW, вокруг которых построена access map (их дефисные псевдонимы pg-audit / s3-cloudtrail тоже разрешаются).

Вид	Наблюдает
`pgaudit`	След PostgreSQL pgAudit (csvlog/jsonlog) → доступ R/RW к таблицам, `READ`/`WRITE` дословно из CLASS pgAudit
`s3cloudtrail`	События S3 AWS CloudTrail → R/RW объектов, чтение/запись из флага `readOnly` CloudTrail (также выявляет вызовы модели Claude-on-Bedrock)
`snowflake-audit`	Нативная история доступа Snowflake
`databricks-uc`	Аудит Databricks Unity Catalog
`bigquery-audit`	Аудит доступа к данным BigQuery
`redshift-audit`	Аудит Amazon Redshift
`mssql-audit`	Аудит SQL Server
`oracle-audit`	Унифицированный аудит Oracle (Business)
`gcs-audit`	Аудит доступа к данным Google Cloud Storage
`azure-blob-audit`	Аудит Azure Blob Storage

Облачный management plane — инвентарь org/tenant + активность control plane

Паритет по трём облакам для плоскости управления — отличной от плоскости данных на уровне ресурсов, которую покрывают коннекторы аудита хранилищ выше. Каждый из них — живой, только для чтения API-клиент control plane облака на уровне org/tenant: он обнаруживает топологию ресурсов (рёбра инвентаря, mode=unknown, attributed) и читает нативную ленту аудита облака для активности control plane (рёбра identity→…api, классифицированные по чтению/записи). Они завершают матрицу, которую AWS уже якорит с s3cloudtrail (плоскость данных) плюс коннектор aws уровня учётной записи IAM/CloudTrail. Оба работают в процессе и безопасны в офлайне (нет учётных данных ⇒ Gather является no-op); оба наблюдают только control plane — никогда полезную нагрузку, секрет, ключ или свойство ресурса.

Вид	Наблюдает	Честное покрытие
`gcp-audit`	GCP Resource Manager / IAM (топология org→folder→project→service-account) + Cloud Audit Logs (Admin Activity + Data Access) → `identity→gcp.api`	Clean там, где логируется: Admin Activity — это запись по определению типа лога, Data Access — чтение/запись из стандартного глагола метода. Lossy там, где логирование Data Access отключено (по умолчанию выключено в GCP) или глагол метода нестандартен (`unknown`, никогда не угадывается). `approximate` для объявленных общих принципалов; `principalEmail` сходится с реестром SPIFFE/SA
`azure-activity`	Azure Resource Graph (топология tenant→subscription→resource) + Azure Monitor Activity Log (операции control plane) → `identity→azure.api`	Clean для записей/удалений control plane (дословно из действия RBAC). Обобщённый суффикс `action` является lossy (`unknown` — он может читать или писать). Чтения плоскости данных отсутствуют в Activity Log (их покрывает плоскость данных `azure-blob-audit` / `azurekeyvault`). `approximate` для общих вызывающих; вызывающий `objectId`/`appId` сходится с реестром Entra
`cloudflare`	Edge-estate Cloudflare — Workers, бакеты R2, задачи Logpush через REST API v4 → рёбра топологии	Только инвентарь (в этом коннекторе нет audit feed); ограниченный токен только для чтения. Отличается от AI-поверхностей `cloudflare-ai-gateway` / MCP portals

Opt-in для GCP Data Access и пробелы Azure read-not-logged являются честными непрозрачными рёбрами этой плоскости: отсутствие ребра активности не является доказательством отсутствия доступа там, где эти логи выключены. Полная таблица уровней по каждому облаку находится в docs/contracts/S165-connectors-cloud-management.md в поставляемом дереве исходного кода.

Поставщики hosted-моделей — каталог, состояние и учёт

Эти источники управляют учётными записями и каталогами hosted-провайдеров моделей. Они не проксируют inference; если у провайдера нет пригодного usage API, расходы оцениваются Meter коннектора вокруг пути inference, а не извлекаются из общего billing feed.

Вид	Наблюдает	Честное покрытие
`openai`	Использование и стоимость платформы OpenAI (org API), каталог моделей и API-ключей	Org/admin-ключ только для чтения; без payload плоскости данных. Отличается от `azure-openai`, который обращается к настоящим поверхностям Azure, а не к путям OpenAI-org
`gemini`	Каталог hosted-моделей Gemini (Google) и подключённый оператором экспорт использования	Поверхность hosted-provider. Отличается от `gemini-cli`, наблюдающего локальные настройки CLI, и `vertex`, покрывающего enterprise-поверхности Vertex. На этом пути Google не предоставляет общий usage API, поэтому usage — только подключённое оператором
`deepseek`	Hosted-каталог DeepSeek, доступность баланса учётной записи и состояние суверенитета PRC	Нет общего usage API; стоимость измеряется вокруг inference из объявленных цен
`mistral`	Каталог Mistral и состояние governance	Нет публичного usage/billing/spending-cap API; стоимость измеряется вокруг inference из цен списка
`xai`	Живой каталог xAI/Grok, billing endpoints, инвентарь ключей/ACL, состояние кредита и лимита расходов	Для стоимости используются management billing endpoints только для чтения; учётные данные управления и inference различаются
`glm`	Объявленный каталог Zhipu GLM / Z.ai, Meter по ценам списка в USD, проверка entitlement и состояние суверенитета	Только каталог + Meter: для GLM не подтверждены usage, billing, balance, admin, key или organization API. Предупреждение о связи с PRC / Entity List относится к поверхностям `z.ai` и `bigmodel.cn`
`vertex`	Каталог Google Vertex AI, использование токенов по модели (Cloud Monitoring), opt-in billed cost (billing export) и opt-in состояние Model Armor	Enterprise-поверхность Google, которой нет у пути AI Studio; у GCP нет API стоимости реального времени
`azure-openai`	Развёртывания + модели Azure OpenAI / AI Foundry (ARM), использование токенов Azure Monitor и поверхности стоимости	Клиент management plane только для чтения; без payload плоскости данных
`openrouter`	Живой каталог OpenRouter (цены USD/MTok), состояние usage/limit учётной записи, дрейф политики разрешённых моделей	Billed cost через экспортируемый `MeterCall`; в офлайне no-op
`cohere`	Живой каталог моделей Cohere (Models API с курсорной пагинацией)	Нет публичного usage/billing/org API (только dashboard) — честное ограничение покрытия; стоимость измеряется вокруг inference из цен списка
`fal`	Инвентарь жизненного цикла API-ключей fal.ai + состояние ротации; стоимость измеряется вокруг queue API	Нет публичного usage/audit API — управление по жизненному циклу ключа; глубокие поверхности закрыты продажами и помечены UNVERIFIED

Self-hosted inference — локальные каталоги и использование

Self-hosted inference всегда в области действия, поэтому это первоклассный источник, а не дополнение к gateway. Этот уровень наблюдает, что локальный runtime действительно обслуживает.

Вид	Наблюдает	Честное покрытие
`local`	Каталог моделей Ollama (`/api/tags`), резидентность Ollama (`/api/ps`) — какие модели загружены сейчас, их разделение GPU/CPU и срок выгрузки — и использование токенов vLLM через OpenAI-совместимую поверхность	Резидентность сообщается как состояние, а серьёзность равна РАЗМЕЩЕНИЮ: полностью находящаяся в VRAM модель — informational, а модель в CPU или РАЗДЕЛЁННАЯ между CPU и GPU помечается, поскольку оператор платит задержкой, не получая предупреждения. Ollama не публикует общие token metrics, поэтому не даёт учёта. Источник по-прежнему не даёт per-call identity или policy на локальном inference; для этого нужен gateway или путь OTel. Ollama на localhost не требует учётных данных, поэтому пустая конфигурация — рабочее значение только для чтения; отключение сервера задаётся ЯВНО пустым URL, а оба пустых значения дают no-op

Подстраховка ядра — eBPF / Tetragon (чистый сигнал, приблизительная атрибуция)

Несотрудничающая половина рва: где кооперативный путь видит то, что агент сообщает, здесь видно то, что сделало ядро — чтения/записи файлов и исходящие соединения — даже когда агент отключает собственную телеметрию. Доступ — это истина на уровне ядра (сигнал уровня clean о том, что произошло); атрибуция намеренно честна относительно своего предела — ядро атрибутирует идентичности среды выполнения (процесс/cgroup/контейнер), никогда — разрешённому агенту, поэтому каждое ребро eBPF является approximate. Оно никогда не расшифровывает и не инспектирует полезные нагрузки (оно слепо к телу TLS).

Вид	Наблюдает	Честный предел
`ebpf`	События ядра Tetragon → R/RW файлов (маска `MAY_*`) и сетевые рёбра; опциональная находка анти-уклонения, когда агент действует на уровне ядра без кооперативной телеметрии	Анонимный по агенту → всегда `approximate`; потоковая подстраховка, а не журнал на уровне агента

Он не загружает eBPF-программы сам: захват ядра выполняется Tetragon (отдельным закалённым DaemonSet). См. Требования к развёртыванию.

Lossy — рёбра фиксируются, часто приблизительно

Вид	Наблюдает	Почему lossy
`mongo-audit`	Аудит MongoDB	Хранилище документов; разделение вызывающих слабое
`openlineage`	События запусков OpenLineage → lineage наборов данных	Lineage — не аудит на уровне вызова
`delta-sharing`	Активность получателей Delta Sharing	Атрибуция общего получателя

Источники approximate-by-attribution и стороны permitted

Они эмитят либо сторону permitted (объявленные гранты), либо доступы, атрибутированные роли / процессу / общей учётной записи, а не разрешённому агенту.

Вид	Наблюдает	Уровень
`iceberg-catalog`	Iceberg REST catalog → разрешённые гранты + выданные идентичности	permitted
`inference-gateway`	Маршрутизация K8s Gateway API Inference-Extension → разрешённые маршруты инференса	permitted
`aws-kms` / `gcp-kms` / `azure-key-vault`	Аудит облачного KMS → рёбра доступа к ключам (никогда — материал ключа)	approximate
`external-secrets` / `sops` / `kmip`	Манифесты управления секретами / KMIP locate → рёбра выдачи/хранения	approximate (существование, а не использование); `kmip`: Business
`istio-telemetry`	CRD Istio Telemetry → рёбра L7-меша	approximate (распарсенные CRD, а не живые потоки)
`egress-proxy`	Лог вердиктов egress-прокси → рёбра L7-egress	approximate
`kong-audit`	Логи аудита Kong → находки об изменении конфигурации	approximate
`ai-gateway`	Записи использования Envoy AI Gateway → образцы стоимости (FinOps)	поток стоимости
`git`	Привязка публикации в обычный git: запись roster, одобряющая один удалённый репозиторий git по SSH или HTTPS для отправок gitpublish	Ничего не наблюдает; только push (у обычного remote нет API pull request или слияния)
`github`	Репозитории GitHub как источники данных агентов → наблюдаемые рёбра доступа R/RW (сначала webhook, сверка опросом API) + разрешённые рёбра ACL	observed + permitted; потоковый (`poll_seconds: 0`)
`gitlab`	Репозитории GitLab → наблюдаемые рёбра доступа R/RW + разрешённые рёбра ACL	observed + permitted; потоковый (`poll_seconds: 0`)

Наблюдатели состояния — находки, а не рёбра доступа

Наблюдатели «чтение прежде всего», выявляющие состояние (синхронизация/здоровье/дрейф, аномалии аутентификации) как находки; они никогда не мутируют estate.

Вид	Наблюдает
`runtime`	Где работают ИИ-нагрузки (Linux procfs, демон Docker, Kubernetes API) → рёбра контейнмента + находки о здоровье (требует доступ к хосту — см. Требования к развёртыванию)
`argocd` / `flux` / `crossplane`	GitOps / CRD control plane → состояние синхронизации, здоровья, дрейфа, композиции
`kerberos`	Телеметрия аутентификации KDC → находки Kerberoasting
`aaa`	Наблюдения RADIUS / TACACS+ AAA
`ssf`	Приёмник Shared-Signals / CAEP (kill-switch агента)
`edugain` / `openidfed`	Агрегат федерации / цепочки доверия OpenID-Federation → состояние федерации
`managed-settings`	Политика Claude `managed-settings` → разрешённые рёбра + находки дрейфа
`envoy-ai-gateway`	Экспорт объявленной конфигурации Envoy AI Gateway → состояние gateway + дрейф политики gateway-vs-Olivares (конфигурационный сосед потока usage `ai-gateway`)
`kong-agent-gateway`	Экспорт объявленной конфигурации Kong agent-gateway → состояние + дрейф политики
`litellm`	Экспорт объявленной конфигурации proxy LiteLLM → состояние + дрейф политики
`bedrock-kb`	Здоровье/конфигурация извлечения Amazon Bedrock Knowledge Bases (health-check Agent Runtime Retrieve) → находки состояния каждого KB + рёбра KB→data-source. Никогда `RetrieveAndGenerate` (без платного inference), никогда полное содержимое документа
`tak`	Состояние `CoreConfig.xml` TAK Server (+ необязательная проверка mTLS) и управляемый ingest Cursor-on-Target с минимальными данными (позиции в digest, uid хеширован)
`a2a`	Пиры Agent2Agent (A2A) v1.0 → обнаружение Agent Card + проверка подписи JWS/JCS (уровень доверия пира) и наблюдаемые взаимодействия task/message как рёбра agent↔agent. Только наблюдение — никогда не отправляет task; выпуск подписанных cards — отдельная возможность

Untrusted hint — интроспекция MCP

Источник mcp интроспектирует MCP-серверы (stdio + Streamable HTTP) и эмитит рёбра возможностей, несущие заявленные подсказки R/RW сервера, плюс находки о ревизии протокола, поверхности возможностей и происхождении из реестра. Согласно спецификации MCP аннотация инструмента является недоверенным заявлением — претензией на возможность, подтверждаемой перекрёстно с наблюдаемым источником, никогда не принимаемой на веру в одиночку. (Кооперативный источник claude также интроспектирует MCP как часть своего OTLP-пути; mcp — это автономный интроспектор, который вы направляете на список серверов или на .mcp.json.)

Вид	Наблюдает	Уровень
`mcp`	Инструменты/ресурсы/промпты MCP-сервера → рёбра заявленных возможностей + находки о состоянии	untrusted hint

Наблюдатели брокеров и мешей вне процесса

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

Вид	Наблюдает
`kafka`	Активность топиков Kafka / Event Hubs / Redpanda / MSK
`amqp`	AMQP-брокеры (RabbitMQ, Azure Service Bus)
`nats` / `mqtt` / `cloudqueue`	Активность NATS, MQTT, облачных очередей
`debezium`	Потоки change-data-capture Debezium
`envoy`	Службы наблюдения Envoy ALS / ext_authz / ext_proc
`hubble`	Данные потоков Cilium Hubble

Поставщики реестра идентичностей

Они заполняют реестр нечеловеческих идентичностей, который обостряет атрибуцию (превращая рёбра approximate в attributed). Каждый источник с поверхностью грантов также эмитит свои рёбра разрешённого доступа (SignalPolicy) из Gather — сторону PERMITTED диффа permitted-vs-observed:

Вид	Реестр	Разрешённые рёбра
`vault`	сущности, группы, политики	гранты пути ACL-политики (`vault.path`), раскрытые по каждой связанной сущности
`ldap`	пользователи, служебные/компьютерные учётные записи, группы	членство в привилегированных группах → гранты каталога (`ldap.directory`)
`idp` (Okta / Entra)	пользователи, приложения/служебные принципалы, группы	гранты назначения приложения / области (`okta.app` / `entra.app`)
`infisical`	машинные идентичности, члены организации, проекты	гранты проекта (`infisical.project`)
`keycloak`	realms, клиенты, роли, группы, пользователи	только реестр (no-op `Gather`)
`pingone` / `forgerock`	Реестры каталогов PingOne / ForgeRock через тот же multi-provider reader (kind задаёт соответствующий `provider`; `ping` — псевдоним `pingone`)	только реестр (no-op `Gather`)
`spiffe`	записи регистрации SPIRE	только реестр (no-op `Gather`)

Установите as_source: true в записи identity для однократного прохода разрешённых грантов за загрузку, либо отдельную запись sources с poll_seconds для периодических повторных сканирований. Каждая запись регистрируется под своим собственным name, поэтому несколько записей одного вида работают рядом: okta и entra обслуживает один коннектор idp, и это по-прежнему два разных источника, у каждого своя конфигурация, свой статус и свой жизненный цикл. Уникальным должно быть имя, а не коннектор. Членства в группах/ролях путешествуют только в типизированном снимке реестра, никогда как рёбра.

Федерация идентичностей агентов

Гиперскейлерные реестры агентов федерируются только для чтения против реестра SPIFFE/WIF плоскости. Их строки на уровне агента (виды agent_identity / workload_identity) являются выделенными, не общими идентичностями, поэтому access map трактует их как твёрдую атрибуцию на уровне агента; вспомогательные строки из тех же источников (принципалы blueprint, поставщики учётных данных, агенты на базе служебных учётных записей) остаются приблизительными. Федерация никогда не пишет в реестр; экспорт в управляющие башни — отдельная, более поздняя возможность.

Вид	Федерирует	Gather
`entra-agent`	Microsoft Entra Agent ID (идентичности агентов, пользователи-агенты, blueprints, принципалы blueprint, владельцы/спонсоры, вычисление сирот в снимке, opt-in мягко удалённые) через Graph v1.0	находки `nhi_longlived_credential`, состояния CA/risky-agent/governance/отсутствия спонсора и opt-in наблюдаемые рёбра доступа агентов из beta `auditLogs/signIns` — добавьте запись `sources` с `poll_seconds`
`agentcore`	AWS Bedrock AgentCore Identity (рабочие идентичности, поставщики учётных данных token-vault) + движки AgentCore Policy/политики Cedar как коллекции	находки дрейфа `nhi_longlived_credential` (поставщики статических API-ключей) — добавьте запись `sources` с `poll_seconds`
`google-agent`	Google Agent Identity (reasoning engines Agent Runtime; идентичности агентов на базе SPIFFE) плюс состояние Agent Registry / Agent Gateway. Строки используют полный SPIFFE ID как ссылку, сходясь с реестром `spiffe`; Gather обнаруживает неатрибутированных агентов registry, теневые reasoning engines вне читаемого registry, рискованные аннотации MCP tools и состояние gateway registry	находки состояния registry/gateway и обнаружение теневых агентов — добавьте запись `sources` с `poll_seconds`
`agent365`	Реестр Microsoft Agent 365 (инвентарь на уровне пакетов, вкл. агентов без идентичности Entra) через Graph v1.0, client credentials с app permission или delegated token, opt-in детали пакетов	находки гигиены реестра (заблокированные развёрнутые пакеты; external/shared-пакеты, развёрнутые для всех users) — добавьте запись `sources` с `poll_seconds`
`foundry-agents`	Проекты Microsoft Foundry, приложения/развёртывания агентов и текущие агенты Agent Service через ARM + Foundry Agent Service v1; коррелирует ссылки идентичности приложения с `entra-agent`	Выведенные из ARM находки состояния приложения (нет Entra agent identity; неудачное развёртывание включённого приложения) — добавьте запись `sources` с `poll_seconds`
`ai-control-tower`	Инвентарь цифровых активов ServiceNow AI Control Tower (Table API, только чтение)	no-op (только реестр)
`oasf`	Дескрипторы агентов AGNTCY/OASF + верификация Agent Badge — EXPERIMENTAL до соответствия спецификации идентичности VCDM 2.0	находки бейджей — добавьте запись `sources` с `poll_seconds`
`onepassword`	Учётная запись 1Password как хранитель `secret_store`	рёбра доступа к секретам по использованию элементов — добавьте запись `sources` с `poll_seconds`

Для семи видов с повторно опрашиваемым Gather (entra-agent, agent365, agentcore, foundry-agents, google-agent, oasf, onepassword) подключите половину реестра как запись identity без as_source, а половину рёбер/находок как отдельную запись sources с poll_seconds — не оба через as_source: true, который запускает сканирование лишь однажды за загрузку. (Две записи одного вида больше не являются препятствием: каждая регистрируется под своим собственным name. Причина — периодичность: один проход за загрузку не является повторным сканированием.)

Объявленные в реестре владелец/спонсор ложатся на записи жизненного цикла NHI во время синхронизации реестра (та же семантика, что у PUT /nhi/{ref}/ownership), а заявленная реестром сирота (агент Entra, чей blueprint исчез) ложится на флаг registry_orphaned той же записи — sweep жизненного цикла ИЛИ-объединяет его в orphaned и эмитит находку nhi_orphaned, так что обнаружение сирот наблюдает федерированных агентов без какой-либо дополнительной обвязки. Источник vault-audit (под sources, не identity) следит за аудиторским устройством файлов Vault и эмитит наблюдаемый аналог разрешённых грантов vault для тех же ссылок entity:<name>.

Источники документов знаний (не покрытие access-map)

Они питают модуль knowledge (модуль VIII), а не access map: они принимают содержимое документов для управляемого извлечения, эмитят ни одного ребра R/RW и не производят никакого наблюдения на шине. Модуль вытягивает их (List → Fetch) по запросу на приём (POST /v1/m/knowledge/kbs/{id}/ingest {"source":"<name>"}), поэтому они подключены к этому модулю — назовите их под documents в OLIVARES_SOURCES_CONFIG, а не sources. Каждый из них только для чтения и с минимумом данных: он несёт ACL и происхождение источника (никогда — личную почту; модуль маскирует тело перед сохранением).

Вид	Принимает
`gdrive`	Документы Google Drive (Docs/Sheets/Slides/файлы)
`confluence`	Пространства и страницы Atlassian Confluence
`notion`	Рабочие пространства, базы данных и страницы Notion
`sharepoint`	Сайты и документы Microsoft SharePoint / OneDrive (Business)
`s3content`	Содержимое объектного хранилища (объекты S3 / R2 / GCS)
`sap_odata`	Сущности сервиса SAP OData как управляемые документы (Business)
`salesforce`	Объекты/записи Salesforce как управляемые документы (Business)
`snowflake`	Таблицы/строки Snowflake как управляемые документы (отличается от наблюдателя R/RW `snowflake-audit`)
`azure_ai_search`	Документы индекса Azure AI Search
`postgres`	Строки PostgreSQL как управляемые документы — только чтение по построению, объявленная ACL каждой строки, классификация каждого столбца (отличается от наблюдателя R/RW `pgaudit`; не NL-to-SQL). См. Postgres как источник управляемого контекста.
`filesystem`	Содержимое файлового сервера (локальный / NFS / SMB) — чтение ограничено корнем по построению, owner/group/ACL POSIX отображаются в ACL Document, классификация xattr (отличается от log sink `filelog`). См. Управление файловым сервером.

// OLIVARES_SOURCES_CONFIG — источники документов живут под "documents", никогда "sources"
{
  "documents": [
    { "name": "eng-wiki", "kind": "confluence",
      "config": { "export_path": "/var/lib/olivares/confluence" } }
  ]
}

Пункты назначения вывода (не покрытие)

Коннекторы вывода доставляют находки и уведомления; они ничего не наблюдают и не имеют уровня покрытия. Они подключаются отдельно от источников.

Внутрипроцессные виды назначений: slack, teams, pagerduty, opsgenie, webhook, siem, splunkhec, syslog, servicenow, jira, email, twilio, chronicle, datadog, elastic, snmp, filelog, otlplog (журналы OTLP/HTTP), s3archive (Business: Regulated Operations) (WORM sink S3 Object Lock — по одному неизменяемому объекту с проверенным lock на уведомление) и teamsbot (Business: Regulated Operations, коннектор Teams с зарегистрированным ботом для цикла инцидентов; бинарный файл Community пропускает получателя этого вида и пишет строку журнала, в которой названа Business).

Три вида egress через брокер работают вне процесса как встроенные плагины (деревья зависимостей их сетевых протоколов никогда не линкуются с движком, как и у plugin-источников): kafka, amqp и cloudqueue — те же имена kind, что у их source-близнецов; в качестве назначения каждый доставляет уведомление как CloudEvent настроенному брокеру/очереди. Обычная dev-сборка без task build:connectors пропускает такое назначение с честным предупреждением при загрузке, а не притворяется, что оно существует.

Требования к развёртыванию и честная атрибуция

Дифференциальные коннекторы R/RW встроены в бинарный файл по умолчанию, но два из них несут требование к развёртыванию, которого нет у остальных — код коннектора агностичен к хосту, а данные, которые он потребляет, — нет:

ebpf потребляет экспорт событий ядра Tetragon. Коннектору не нужна никакая возможность ядра — он читает файл/FIFO/stdin с правами 0600, которым владеет Tetragon (events_path, по умолчанию -). Сам Tetragon — это отдельный закалённый DaemonSet, удерживающий минимальные CAP_BPF + CAP_PERFMON, работающий не от root с seccomp/AppArmor и без входящего слушателя. Поэтому развёртывание таково: запустите Tetragon привилегированно (его встроенные TracingPolicies file-access + TCP-connect), затем направьте ebpf на его экспорт. Минимальный Tetragon: v1.0.
runtime читает procfs хоста (proc_root, по умолчанию /proc), сокет демона Docker (docker_socket, по умолчанию выключен — доступ на чтение к docker.sock эквивалентен root; включайте намеренно, в идеале через прокси сокета с allowlist на GET) и/или Kubernetes API (по умолчанию внутрикластерный ServiceAccount). Монтируйте только то, что вы включаете.
gcp-audit аутентифицируется как служебная учётная запись GCP (JSON-ключ или выданный WIF/ADC access_token) и нуждается только в ролях только для чтения management: roles/resourcemanager.organizationViewer + roles/iam.serviceAccountViewer + roles/logging.viewer — чтение записей Data Access дополнительно требует roles/logging.privateLogViewer. Задайте область organization_id (обход org + org-scoped аудит) и/или projects. Логи аудита Data Access по умолчанию выключены в GCP: включите их согласно конфигурации IAM/data-access, иначе лента активности честно недосчитывается.
azure-activity аутентифицируется как служебный принципал Entra (client-credentials) или access_token управляемой идентичности, и нуждается только в роли Reader в корне тенанта (или на подписку) — эта единственная роль покрывает Resource Graph, перечисление подписок и Activity Log. Подписки перечисляются автоматически, когда subscriptions не задан.

Оба работают внутри процесса, как и все виды, не указанные как плагины в разделе Режим процесса для каждого вида. Чтобы запустить такой коннектор в собственном процессе, соберите его программу connectors/<kind>/cmd/ и допустите её как внешний плагин.

Каждый источник opt-in, deny-closed: отсутствующий log_path/path/events_path — это ошибка конфигурации при запуске (источник не подключается), никогда — тихий no-op. Демо-estate (quickstart) засевает эквивалентные синтетические наблюдения через реальную шину, чтобы вы могли увидеть сигнал уровня clean от начала до конца до подключения живого источника.

Отсутствие ребра не является доказательством отсутствия доступа там, где покрытие lossy, невозможно, или источник не подключён. Access map честна относительно собственного охвата.
Идентичность на уровне агента — это жёсткая зависимость. Общая служебная учётная запись за пулом соединений низводит атрибуцию до approximate даже на хранилище уровня clean — см. управляйте и одобряйте.
Аннотации инструментов MCP недоверенны согласно спецификации MCP: заявленная подсказка о возможности, подтверждаемая перекрёстно с наблюдаемым источником, никогда не принимаемая на веру в одиночку.

Связанное

Подключите источник — модель коннектора и как подключить один.
Подключите Claude Code — кооперативный путь от начала до конца.
Модуль III — access map — во что превращаются рёбра.
Честность и пределы — честный контракт на уровне всего продукта.