Catálogo de conectores y niveles de cobertura

Esta página es el catálogo de conectores de primera parte y, para cada uno, el nivel de cobertura honesto que puede admitir. Es el complemento de conectar una fuente, que explica el modelo de conector (solo observación, datos mínimos, los tres tipos de observación) — léelo primero. Esta página responde a la siguiente pregunta: ¿qué fuentes existen y cómo de buena es la señal de cada una?

La cobertura se escalona según lo que la superficie de auditoría de un sistema puede decirte honestamente, nunca según cuánto desearíamos que pudiera. Los niveles, tal como se usan a lo largo de la documentación:

Cooperativo — un agente o plataforma que informa de lo que hizo (OpenTelemetry, una API de administración de un proveedor). La máxima fidelidad cuando está presente; depende de que la fuente coopere.
Limpio — un almacén que clasifica lectura frente a escritura de forma nativa, tomada literalmente de su propio rastro de auditoría (auditoría SQL, registros de acceso a datos de object-store / warehouse).
Con pérdidas — un almacén cuya auditoría no puede separar limpiamente lectura de escritura ni un llamante de otro (document stores, linaje). Las aristas aterrizan, pero a menudo como approximate.
Imposible pasivamente — un sistema sin superficie de auditoría pasiva utilizable (cachés en memoria, bases de datos embebidas de un solo fichero). No hay señal honesta de lectura primero; el producto no pretende lo contrario.
Aproximado por atribución — el acceso es real pero la atribución es a un rol, proceso o credencial compartida, no a un agente resuelto, así que la arista es approximate.
Indicio no fiable — una capacidad declarada (una anotación de herramienta MCP), corroborada, nunca fiada por sí sola.

Esto lista los conectores registrados en el conjunto de conectores del binario por defecto hoy — es decir, kinds que puedes nombrar en OLIVARES_SOURCES_CONFIG y que el motor cableará. El producto es pre-1.0. Los conectores canónicos del access-map R/RW — pgAudit, S3/CloudTrail, el respaldo eBPF/Tetragon, el inventario runtime y la introspección MCP — y las fuentes de documentos de conocimiento ya están cableados y son configurables en un serve de serie; algunos conllevan requisitos de despliegue (un sensor Tetragon, acceso al host) cubiertos en Requisitos de despliegue más abajo. La cobertura está escalonada honestamente: la presencia de un conector aquí no es una afirmación de atribución firme por agente, que sigue siendo la dependencia dura (una cuenta compartida colapsa incluso un almacén de nivel limpio a approximate).

Modo de proceso por tipo

Cada tipo se ejecuta en un único modo de proceso, fijado por el motor:

Plugin fuera de proceso. El motor incorpora el conector como programa separado, lo inicia como subproceso confinado (entorno acotado; usuario y cgroup dedicados cuando el host lo permite) y se comunica por gRPC con AutoMTLS. Sus árboles de dependencias nunca se enlazan al motor. Tipos de fuente: claude, cowork, kafka, amqp, nats, mqtt, cloudqueue, debezium, envoy y hubble. Tipos de destino: kafka, amqp y cloudqueue. Una build sin task build:connectors no los incorpora y el arranque avisa por cada uno que esté configurado.
En proceso. Todos los demás tipos de esta página. El conector está enlazado al binario y corre dentro del proceso del motor; un panic queda contenido y la fuente se marca failed.
Plugin externo. Una fuente o destino configurado con plugin (ruta del binario, digest fijado y firma verificada contra connector_trust) siempre corre fuera de proceso con el mismo confinamiento. Los programas connectors/<kind>/cmd/ de los tipos en proceso no forman parte de la release; compila uno y admítelo así (operar un plugin) para ejecutar ese conector en su propio proceso.

Si muere el proceso de un plugin fuente, el motor reinicia el mismo binario, comprueba de nuevo el digest fijado de un plugin externo, lo abre con los ajustes de la fuente y reanuda la recogida. El primer reinicio espera aproximadamente un segundo; la espera se duplica en cada reinicio posterior hasta cinco minutos y vuelve a un segundo cuando el plugin lleva cinco minutos ejecutándose. Desde que se detecta la muerte hasta que el nuevo proceso está disponible, la fuente informa failed, con el error de reinicio mientras falle un intento.

Un plugin destino se reinicia del mismo modo cuando falla una entrega y se detecta que su proceso ha muerto: el motor reinicia el binario, comprueba de nuevo el digest si es externo y lo abre con los ajustes del destino. La entrega que detectó la muerte sigue informándose como fallida, con el error de reinicio si este se rechazó, y la escala de reintentos de notificaciones la reintenta contra el nuevo proceso. El primer reinicio es inmediato; los posteriores esperan un segundo, duplicándose hasta cinco minutos y empezando de nuevo cuando el último intento tiene más de cinco minutos. Un destino sin entregas no se reinicia hasta que llega una.

El plugin reiniciado se abre con los ajustes originales del conector: un secreto modificado o rotado llega al recargar la configuración o reiniciar el motor, igual que en un plugin que nunca murió. Un plugin cuyo proceso sigue vivo pero cuya recogida o entrega falla no se reinicia: ese fallo es propio del conector.

Cooperativo — Claude y telemetría de proveedores

Las fuentes de máxima fidelidad cuando están presentes. La fuente runtime de Claude Code corre fuera de proceso como un plugin embebido (un dev build sencillo lo omite y el arranque avisa honestamente en lugar de parecer sano).

Kind	Observa	Notas
`claude`	Telemetría OTLP de herramientas de Claude Code + introspección MCP → aristas / coste / hallazgos	Plugin fuera de proceso; `attributed` cuando hay una identidad por agente presente, si no `approximate`
`claude-api`	Muestras de coste de la Admin-API de Claude + hallazgos de postura de gobernanza	En proceso; no-op offline (sin admin key)
`claude-compliance`	Evidencia del activity-feed de Claude Compliance → hallazgos	Solo GET por construcción; no-op offline (Business)
`claude-config`	Árbol estático de config de Claude (subagents / Skills / plugins) → aristas de capacidad-declarada	Solo metadatos — una superficie de capacidad, no un acceso observado
`claude-console`	IAM de la org de Claude → hallazgos de postura SSO/SCIM (roster de identidad + fuente)	Business: Identity & Scale;
`claude-wif`	Roster de identidad no humana / workload-identity de Anthropic + aristas de scope permitido	Business: Identity & Scale; Modela la federación declarada por el operador; señala los footguns de claves estáticas
`claude-managed-agents`	Inventario de managed agents de Claude + eventos de hilos (receptor webhook + pollers GET)	Fuente en streaming (`poll_seconds: 0`); offline es un no-op
`claude-projects`	Inventario de Projects de Claude Organization (membresía / claves API) + política de proyecto declarada por el operador	Admin-API de solo lectura; no-op offline
`claude-apps-gateway`	Postura de apps-gateway de Claude, grants de modelos declarados e ingest de eventos de auditoría → topología + hallazgos	Lee un `gateway.yaml` existente y una exportación de auditoría JSONL opcional
`claude-batch`	Inventario de Anthropic Message Batches + Files API, aplicación de políticas de lotes y vencimiento de retención de uploads	Nunca lee payloads ni contenido de ficheros; emite un hallazgo offline honesto sin una admin key
`claude-routines`	Inventario de Claude Code Routines (triggers programados) → aristas + hallazgos de cadencia/revisión	Solo GET; el contenido del prompt solo se hashea; streaming (`poll_seconds: 0`)
`cowork`	Receptor de logs OTLP/HTTP de Claude Cowork → evidencia de actividad	Plugin fuera de proceso (aislamiento de dependencias OTel-proto)
`cowork-analytics`	Analítica de uso de Claude Cowork	En proceso (solo cliente modelprovider)
`codex`	Muestras de coste de OpenAI Codex, evidencia de uso/auth/auditoría admin y hallazgos de adopción	Admin-API de solo lectura; las superficies sujetas a ventas se degradan a un hallazgo de postura
`cursor`	Coste facturado de la Admin-API de Cursor, logs de auditoría del equipo, inventario de miembros y postura de presupuesto	Un 403/404 por limitación del plan se degrada a un hallazgo, nunca falla

Perfil de framework GenAI neutral de proveedor (`gen_ai.*`) — opt-in

Los frameworks de agentes que promete el catálogo — LangGraph / LangChain, CrewAI, AutoGen / Microsoft Agent Framework, Google ADK (y el OpenAI SDK, LlamaIndex, Pydantic-AI, Strands, …) — no emiten el esquema claude_code.* de Claude. Convergen en las convenciones semánticas GenAI de OpenTelemetry (gen_ai.*). La misma fuente claude ingesta también ese perfil, de modo que una flota instrumentada con OTel alimenta el access map y FinOps a través de un único ingest en lugar de un conector a medida por framework — la integración de máximo apalancamiento.

Este perfil es OPT-IN y está honestamente etiquetado como experimental. Toda el área gen_ai está en estado Development de OpenTelemetry (no Stable, jun-2026), así que se activa solo cuando reflejas el propio gate de la especificación. Pon el semconv_opt_in del conector a una lista separada por comas que contenga el token gen_ai_latest_experimental (reflejando OTEL_SEMCONV_STABILITY_OPT_IN). Desactivada por defecto, una señal gen_ai.* sigue alimentando el watchdog de silencio pero no mapea arista/coste — nunca afirmamos una estabilidad que las convenciones no tienen.

Como las convenciones están en plena rotación, el ingest es de doble nombre (lee la clave actual y el predecesor obsoleto que aún se emite en el mundo real) y multi-señal (mapea spans de traza, el log event gen_ai.client.inference.operation.details y reconoce las metrics del cliente):

Lo que lee	Clave actual	También aceptado (obsoleta, aún emitida por)
Proveedor	`gen_ai.provider.name`	`gen_ai.system` (default en v1.36.0 o anterior; Google ADK, p. ej. `gcp.gemini`)
Tokens de entrada	`gen_ai.usage.input_tokens`	`gen_ai.usage.prompt_tokens` (OpenLLMetry/Traceloop → LangChain/LangGraph/CrewAI)
Tokens de salida	`gen_ai.usage.output_tokens`	`gen_ai.usage.completion_tokens` (igual)

atributo gen_ai	mapea a	confianza
`gen_ai.usage.*` (tokens)	`CostSample` (provenance estimated — tokens, no coste facturado)	—
`gen_ai.provider.name` / `request.model` / `response.model`	proveedor de coste + modelo (se prefiere response)	—
`gen_ai.operation.name = execute_tool` + `gen_ai.tool.name`	arista de acceso agente→herramienta (modo `unknown`)	`attributed`
`gen_ai.conversation.id` + `gen_ai.agent.{name,id}`	arista de atribución conversación→agente + ref de sesión	`attributed`

Matriz de dialectos admitidos (normalizador multi-generación)

Las convenciones GenAI cambiaron en tres generaciones que coexisten en flotas reales de 2026. El ingest detecta la generación por señal a partir de marcadores exclusivos de cada generación y estampa el evento normalizado con el pin de semconv correspondiente (el hallazgo de postura genai.semconv registra el conjunto activo por run; un hallazgo drift informativo por run señala cada dialecto obsoleto visto, así sabes qué flotas necesitan actualizar su instrumentación). El contenido de los mensajes nunca se lee de ninguna generación — las claves de contenido actúan solo como marcadores de dialecto (postura de datos mínimos).

Dialecto detectado	Pin estampado	Marcadores exclusivos (verificados)	Emitido por (verificado jun-2026)
OpenLLMetry/Traceloop legacy (pre-semconv)	`openllmetry`	`gen_ai.prompt.{i}.` / `gen_ai.completion.{i}.` indexados, `gen_ai.usage.prompt_tokens`/`completion_tokens`, `llm.usage.total_tokens`, `llm.request.type`, `llm.vendor`, `traceloop.span.kind`	LangChain / LangGraph / CrewAI instrumentados con Traceloop fijados a < openllmetry v0.55.0 (publicado 2026-03-29). Los proveedores en mayúsculas (`OpenAI`, `Langchain`) se pasan a minúsculas para que FinOps no se divida por mayúsculas/minúsculas
eventos v1.36 o anterior (el nombre de la propia especificación)	`1.36.0`	`gen_ai.system`; los cinco log events por mensaje `gen_ai.{system,user,assistant,tool}.message`, `gen_ai.choice` (reconocidos por nombre — su único atributo es opcional)	Spans LLM de Google ADK (`gcp.vertex.agent`), AutoGen (`autogen`), Microsoft Agent Framework — todos siguen emitiendo `gen_ai.system`
mensajes v1.37+ (actual)	`1.41.1`	`gen_ai.provider.name`, `gen_ai.input.messages` / `gen_ai.output.messages` / `gen_ai.system_instructions`, el event `gen_ai.client.inference.operation.details`, `gen_ai.workflow.name`	Instrumentaciones oficiales de OTel; openllmetry ≥ v0.55.0

Una señal que solo lleva claves cuyos nombres son idénticos entre generaciones (p. ej. un span invoke_agent de ADK: operación + agente + conversación, sin clave de proveedor en absoluto) se normaliza bajo el pin actual — el mapeo aplicado es idéntico byte a byte, y la release real del productor no es conocible desde el wire.

Convenciones MCP (`mcp.*`, semconv v1.39 — Development)

Existen exactamente cuatro atributos mcp.* upstream (mcp.method.name, mcp.protocol.version, mcp.resource.uri, mcp.session.id); la herramienta viaja en gen_ai.tool.name y el prompt en gen_ai.prompt.name. El ingest une estas trazas con los propios hechos de gobernanza MCP del producto reutilizando los mismos resource kinds que emite la ruta de Claude:

Señal MCP	mapea a
cualquier span `mcp.*` del lado cliente con `server.address`	arista sesión→`mcp.server` (se une a las aristas `claude_code.mcp_server_connection`)
`tools/call` + `gen_ai.tool.name`	arista de acceso `mcp.tool` (`server.address/tool` cuando el endpoint es conocido) — el mismo kind que las invocaciones `mcp__server__tool` de Claude
`resources/read` / `resources/subscribe` + `mcp.resource.uri`	arista `mcp.resource` en modo lectura (URI saneada: credenciales/query eliminadas)
`prompts/get` + `gen_ai.prompt.name`	arista `mcp.prompt` en modo lectura (superficie de prompt)
spans de kind SERVER / metrics `mcp.client	server.*.duration`

Spans de agente (split CLIENT/INTERNAL de `invoke_agent` + `invoke_workflow`, semconv v1.41 — Development)

v1.41.0 dividió invoke_agent en una variante CLIENT (servicio de agente remoto) y una variante INTERNAL (en proceso). Los frameworks reales violan el kind hoy (AutoGen y Microsoft Agent Framework codifican CLIENT a fuego para agentes en proceso; Google ADK usa INTERNAL), así que el ingest clasifica una invocación como remota solo cuando el span es CLIENT y lleva un server.address — eso da una arista de delegación conversación→genai.agent.remote. Todo lo demás se queda como invocación en proceso cubierta por la arista de atribución conversación→genai.agent: degradada limpiamente, nunca un “remote” fabricado. invoke_workflow (nuevo en v1.41; crews al estilo CrewAI) mapea una arista conversación→genai.workflow. Los spans de agente siguen en Development upstream (experimental) — no se afirma estabilidad alguna.

Estable frente a experimental, honestamente: el mecanismo (gate opt-in, detección de dialecto + lecturas de doble nombre, mapeo span/event/metric, las formas selladas CostSample/EdgeObservation) es estable en este producto. El vocabulario que mapea (claves gen_ai.*/mcp.*, el enum de operación) está en Development upstream y puede volver a renombrarse; ese es exactamente el motivo por el que el ingest normaliza cada generación en lugar de fijar una sola. v1.41.1 es la última release versionada de las convenciones gen-ai (se movieron a open-telemetry/semantic-conventions-genai, que no tiene releases a fecha de jun-2026). Notas:

El coste se deduplica por id de span de W3C. Cuando una operación reporta uso en ambos, su span y su event operation.details (comparten un id de span), se contabiliza una vez, no dos.
Las metrics alimentan liveness, nunca coste. gen_ai.client.token.usage es un agregado; el span/event es el uso por operación autoritativo, así que contabilizar también la metric duplicaría la cuenta. Los histogramas de duración mcp.* de v1.39 se reconocen igual.
El proveedor puede ser unknown. Si un span lleva un modelo pero ningún proveedor/system, el coste se atribuye a unknown en lugar de adivinarse a partir del id del modelo.
Un recuento de tokens solo-total no se divide. El llm.usage.total_tokens legacy sin un split prompt/completion nunca se adivina en entrada/salida (sin coste fabricado).
OpenInference (Arize/Phoenix) es una convención distinta y no es ingestada por este perfil — las claves llm.* que se leen aquí (llm.request.type, llm.usage.total_tokens, llm.vendor) son marcadores legacy de OpenLLMetry, no el namespace llm.* de OpenInference.

Cooperativo — configuración de la superficie del agente local

Estas fuentes leen la configuración declarada de un agente local y emiten aristas permitidas, además de hallazgos de postura. No son trazas de ejecución en vivo; cuando un framework tiene OTEL nativo, el uso en vivo sigue llegando por el ingest gen_ai.* anterior.

Kind	Observa	Cobertura honesta
`opencode`	Capas JSONC locales `opencode.json` / `opencode.jsonc` → postura de permisos, postura de managed/admin-override, aristas permitidas de MCP/herramienta/agente personalizado, hallazgos de credenciales en config/share/autoupdate/OTEL y un fragmento de autoría	Solo lo declarado en la configuración. La capa gestionada se detecta localmente, pero no es un bloqueo inmutable: `OPENCODE_PERMISSION` en runtime, la redirección del directorio de tests y la configuración remota de la organización quedan fuera de este lector. OTEL nativo, cuando está habilitado, puede alimentar uso `gen_ai.` en vivo mediante el exportador `OTEL_` fuera de banda
`gemini-cli`	Capas `settings.json` de Gemini CLI (sistema/usuario/workspace) → aristas permitidas de MCP/herramientas, postura de brecha de aplicación e inventario de configuración efectiva	Solo lo declarado en la configuración; el uso en vivo viaja por el ingest `gen_ai.*` (la CLI lo emite de forma nativa). No es la API de Gemini (esa es la superficie de proveedor alojado)
`openhands`	`config.toml` + entorno de OpenHands → postura de sandbox/fijación de modelo/credencial/telemetría y aristas permitidas de MCP/acciones	Solo lo declarado en la configuración; uso en vivo mediante OTEL `gen_ai.*` nativo
`goose`	`profiles.yaml` + entorno de Goose (Block) → postura de ajustes admin/fijación de modelo/extensión/aprobación de herramientas y aristas permitidas de extensiones	Solo lo declarado en la configuración
`cline`	Namespaces de Cline / Kilo Code en `settings.json` de VSCode → postura de aprobación automática/allowlist MCP/credencial/fijación de modelo	Solo lo declarado en la configuración; no hay OTEL nativo upstream
`grok`	Grok Build (xAI), el agente de codificación de terminal: configuración local, cableado de hooks, eventos con veto documentado y postura de gobernanza declarada	Postura del agente declarada por configuración. El conector de API `xai` lee el catálogo de modelos y los costes, con `grok-build-0.1` como modelo; este conector lee el agente. La observación en vivo usa el ingest OTLP emitido por Grok Build. `PostureEnforced` solo se aplica a `PreToolUse`, el único evento con veto documentado; los demás son `observed`
`openclaw`	`openclaw.json` de OpenClaw (descubrimiento JSON5, `$include` confinado) → postura de gateway/canal/herramienta/sandbox/skill/modelo por agente y aristas declaradas de canal/skill/modelo	Solo lo declarado en la configuración; no se ha verificado un hook PEP inline upstream
`hermes`	`config.yaml` + árboles de perfiles + ámbito gestionado de Hermes Agent → postura de terminal/canal/skill/seguridad/modelo/MCP y aristas declaradas	Solo lo declarado en la configuración; no se ha verificado un hook PEP inline ni OTEL nativo upstream
`paperclip`	API REST de Paperclip (clave de API del board, solo GET) → empresas como colecciones de grupos y agentes como filas del roster NHI (`paperclip/<adapterType>`, rol, título, `reports_to`), recuentos de ejecuciones de días completos y muestras orientativas de coste (`cost_type=paperclip`)	Solo observación: no inicia ni confina los agentes de Paperclip. El coste es un agregado diario porque Paperclip no ofrece una lista de eventos de coste en bruto; una parte rechazada se informa como hallazgo de cobertura
`google-adk`	JSON de sesión exportado de Google ADK 2.0 → inventario de agente/app, subagentes, llamadas de funciones de herramientas, transferencias, drift de herramientas aprobadas y correlación Vertex reasoningEngine	Exportación de solo lectura; nunca contenido de mensajes. Distinto de la superficie de plataforma `google-agent`
`agents-md`	Recorrido del repo de ficheros de instrucciones de agentes (AGENTS.md y ficheros de memoria/instrucciones por agente) → drift de línea base SHA-256 + escaneo de inyección de instrucciones / Unicode oculto / secretos	Datos mínimos: rutas saneadas + detalles hasheados, nunca contenido
`mcpb`	Extensiones de escritorio `.mcpb` instaladas / distribuidas → escaneo de postura del manifiesto, drift de allowlist enterprise y verificación de firma PKCS#7	PERMITIDO-frente-a-OBSERVADO en la superficie de extensiones
`codex-managed-config`	Ficheros managed-config de OpenAI Codex → postura de aplicación + drift respecto a la línea base escrita	Solo observación: no puede impedir que un desarrollador eluda la capa gestionada (el equivalente de `managed-settings` para Codex)

Limpio — auditoría nativa del almacén (lectura/escritura literal)

Estos leen el rastro de auditoría propio de un almacén y toman la clasificación lectura/escritura literalmente — nunca inferida del texto de la query. pgaudit y s3cloudtrail son las fuentes R/RW canónicas en torno a las que se construye el access map (sus alias con guion pg-audit / s3-cloudtrail también resuelven).

Kind	Observa
`pgaudit`	Rastro pgAudit de PostgreSQL (csvlog/jsonlog) → acceso a tablas R/RW, `READ`/`WRITE` literal del CLASS de pgAudit
`s3cloudtrail`	Eventos S3 de AWS CloudTrail → R/RW de objetos, lectura/escritura del flag `readOnly` de CloudTrail (también expone invocaciones de modelos Claude-on-Bedrock)
`snowflake-audit`	Historial de acceso nativo de Snowflake
`databricks-uc`	Auditoría de Databricks Unity Catalog
`bigquery-audit`	Auditoría de acceso a datos de BigQuery
`redshift-audit`	Auditoría de Amazon Redshift
`mssql-audit`	Auditoría de SQL Server
`oracle-audit`	Auditoría unificada de Oracle (Business)
`gcs-audit`	Auditoría de acceso a datos de Google Cloud Storage
`azure-blob-audit`	Auditoría de Azure Blob Storage

Plano de gestión cloud — inventario org/tenant + actividad del control plane

La paridad tri-cloud para el plano de gestión — distinto del plano de datos por recurso que cubren los conectores de auditoría de almacén de arriba. Cada uno es un cliente de API en vivo, de solo lectura, del control plane org/tenant de una cloud: descubre la topología de recursos (aristas de inventario, mode=unknown, attributed) y lee el feed de auditoría nativo de la cloud para la actividad del control plane (aristas identity→…api, clasificadas lectura/escritura). Completan la matriz que AWS ya ancla con s3cloudtrail (plano de datos) más el conector aws de IAM/CloudTrail a nivel de cuenta. Ambos corren en proceso y son offline-safe (sin credencial ⇒ Gather es un no-op); ambos observan solo el control plane — nunca un payload, secreto, clave o propiedad de recurso.

Kind	Observa	Cobertura honesta
`gcp-audit`	GCP Resource Manager / IAM (topología org→folder→project→service-account) + Cloud Audit Logs (Admin Activity + Data Access) → `identity→gcp.api`	Limpio donde se registra: Admin Activity es una escritura por la definición del tipo de log, Data Access es lectura/escritura del verbo de método estándar. Con pérdidas donde el logging de Data Access está deshabilitado (off por defecto en GCP) o un verbo de método no es estándar (`unknown`, nunca adivinado). `approximate` para principals compartidos declarados; el `principalEmail` converge con el roster SPIFFE/SA
`azure-activity`	Azure Resource Graph (topología tenant→subscription→resource) + Azure Monitor Activity Log (operaciones del control plane) → `identity→azure.api`	Limpio para escrituras/eliminaciones del control plane (literal de la acción RBAC). El sufijo `action` genérico es con pérdidas (`unknown` — puede leer o escribir). Las lecturas del plano de datos no están en el Activity Log (el plano de datos `azure-blob-audit` / `azurekeyvault` cubre esas). `approximate` para llamantes compartidos; el `objectId`/`appId` del llamante converge con el roster de Entra
`cloudflare`	Estate de edge de Cloudflare — Workers, buckets R2 y jobs de Logpush mediante la REST API v4 → aristas de topología	Solo inventario (este conector no incluye un feed de auditoría); token acotado de solo lectura. Distinto de las superficies de IA `cloudflare-ai-gateway` / portales MCP

El opt-in de Data Access de GCP y los huecos de lectura-no-registrada de Azure son las aristas opacas honestas de este plano: una arista de actividad ausente no es prueba de no-acceso donde esos logs están apagados. La tabla completa de niveles por cloud está en el contrato incluido de conectores de gestión cloud (docs/contracts/S165-connectors-cloud-management.md).

Proveedores de modelos alojados — catálogo, postura y medición

Estas fuentes gobiernan cuentas y catálogos de proveedores de modelos alojados. No actúan como proxy de la inferencia; cuando un proveedor carece de una API de uso utilizable, el conector estima el gasto mediante su Meter alrededor de la vía de inferencia, en lugar de extraerlo de un feed de facturación agregado.

Kind	Observa	Cobertura honesta
`openai`	Uso y coste de la plataforma OpenAI (API de org), además del catálogo de modelos y claves API	Clave de org/admin de solo lectura; sin payloads del data plane. Distinto de `azure-openai`, que usa las superficies reales de Azure, no las rutas de la org de OpenAI
`gemini`	Catálogo de modelos alojados de Gemini (Google) y una exportación de uso cableada por el operador	La superficie de proveedor alojado. Distinta de `gemini-cli`, que observa ajustes locales de la CLI, y de `vertex`, que cubre las superficies enterprise de Vertex. Google no expone una API de uso agregado en esta vía, por lo que el uso es el que cablea el operador
`deepseek`	Catálogo alojado de DeepSeek, disponibilidad del saldo de la cuenta y postura de soberanía PRC	Sin API de uso agregado; el coste se mide alrededor de la inferencia a partir del precio declarado
`mistral`	Catálogo de Mistral y postura de gobierno	Sin API pública de uso/facturación/límite de gasto; el coste se mide alrededor de la inferencia a partir del precio de lista
`xai`	Catálogo en vivo de xAI/Grok, endpoints de facturación, inventario de claves/ACL y postura de crédito y límite de gasto	Usa los endpoints de gestión de facturación de solo lectura para el coste; las credenciales de gestión e inferencia son distintas
`glm`	Catálogo declarado de Zhipu GLM / Z.ai, Meter de precio de lista en USD, prueba de entitlement y postura de soberanía	Solo catálogo + Meter: GLM no expone ninguna API verificada de uso, facturación, saldo, admin, claves u organización. La salvedad de nexo con la PRC / Entity List se aplica tanto a las superficies `z.ai` como `bigmodel.cn`
`vertex`	Catálogo de Google Vertex AI, uso de tokens por modelo (Cloud Monitoring), coste facturado opt-in (exportación de facturación) y postura de seguridad Model Armor opt-in	La superficie enterprise de Google que no cubre la vía AI Studio; GCP no tiene API de coste en tiempo real
`azure-openai`	Deployments + modelos de Azure OpenAI / AI Foundry (ARM), uso de tokens de Azure Monitor y superficies de coste	Cliente del plano de gestión de solo lectura; sin payloads del data plane
`openrouter`	Catálogo en vivo de OpenRouter (precios USD/MTok), postura de uso/límite de cuenta y drift de política de modelos aprobados	Coste facturado mediante el `MeterCall` exportado; no-op offline
`cohere`	Catálogo en vivo de modelos de Cohere (Models API paginada por cursor)	Sin API pública de uso/facturación/org (solo dashboard): salvedad de cobertura honesta; coste medido alrededor de la inferencia a partir del precio de lista
`fal`	Inventario del ciclo de vida de claves API de fal.ai + postura de rotación; coste medido alrededor de la API de colas	Sin API pública de uso/auditoría: el gobierno se basa en el ciclo de vida de claves; las superficies profundas están sujetas a ventas y marcadas como UNVERIFIED

Inferencia autoalojada — catálogos y uso locales

La inferencia autoalojada siempre está dentro del alcance, por lo que es una fuente de primera clase y no una idea secundaria del gateway. Este nivel observa lo que sirve realmente un runtime local.

Kind	Observa	Cobertura honesta
`local`	Catálogo de modelos de Ollama (`/api/tags`), residencia de Ollama (`/api/ps`) — qué modelos están cargados ahora mismo, su reparto GPU/CPU y el plazo de descarga — y uso de tokens de vLLM mediante su superficie compatible con OpenAI	La residencia se informa como postura, y su gravedad es la COLOCACIÓN: un modelo enteramente en VRAM es informativo, mientras que uno residente en CPU o REPARTIDO entre CPU y GPU se marca, porque en ese caso el operador paga latencia sin que se le diga. Ollama no publica métricas de tokens agregadas, así que no aporta medición. Esta fuente todavía no proporciona identidad ni política por llamada sobre la inferencia local; gobernarlas requiere la vía del gateway u OTel. Ollama en localhost no necesita credencial, por lo que una config vacía es un valor por defecto funcional de solo lectura; deshabilitar un servidor requiere una URL vacía EXPLÍCITA, y ambos vacíos son un no-op

Respaldo de kernel — eBPF / Tetragon (señal limpia, atribución aproximada)

La mitad no cooperativa del moat: donde la ruta cooperativa ve lo que un agente reporta, esto ve lo que el kernel hizo — lecturas/escrituras de fichero y conexiones salientes — incluso cuando un agente deshabilita su propia telemetría. El acceso es ground-truth del kernel (una señal de nivel limpio de lo que ocurrió); la atribución es deliberadamente honesta sobre su límite — el kernel atribuye a una identidad de runtime (proceso/cgroup/contenedor), nunca a un agente resuelto, así que toda arista eBPF es approximate. Nunca descifra ni inspecciona payloads (es ciego al cuerpo TLS).

Kind	Observa	Límite honesto
`ebpf`	Eventos de kernel de Tetragon → R/RW de fichero (máscara `MAY_*`) y aristas de red; hallazgo opcional anti-evasión cuando un agente actúa en el kernel sin telemetría cooperativa	Anónimo respecto al agente → siempre `approximate`; un respaldo en streaming, no un ledger por agente

No carga programas eBPF por sí mismo: la captura del kernel la hace Tetragon (un DaemonSet aparte, endurecido). Ver Requisitos de despliegue.

Con pérdidas — las aristas aterrizan, a menudo aproximadas

Kind	Observa	Por qué con pérdidas
`mongo-audit`	Auditoría de MongoDB	Document-store; la separación de llamantes es débil
`openlineage`	Eventos de run de OpenLineage → linaje de datasets	El linaje no es auditoría por llamada
`delta-sharing`	Actividad de recipients de Delta Sharing	Atribución a recipient compartido

Fuentes aproximadas-por-atribución y del lado permitido

Estas emiten o bien el lado permitido (grants declarados) o accesos atribuidos a un rol / proceso / credencial compartida en lugar de a un agente resuelto.

Kind	Observa	Nivel
`iceberg-catalog`	Catálogo REST de Iceberg → grants permitidos + identidades de credencial servida	permitido
`inference-gateway`	Enrutamiento de K8s Gateway API Inference-Extension → rutas de inferencia permitidas	permitido
`aws-kms` / `gcp-kms` / `azure-key-vault`	Auditoría de KMS cloud → aristas de acceso a claves (nunca material de clave)	approximate
`external-secrets` / `sops` / `kmip`	Manifiestos de gestión de secretos / locate KMIP → aristas de aprovisionamiento/custodia	approximate (existencia, no uso); `kmip`: Business
`istio-telemetry`	CRDs de Istio Telemetry → aristas de mesh L7	approximate (CRDs parseados, no flujos en vivo)
`egress-proxy`	Log de veredicto de egress-proxy → aristas de egress L7	approximate
`kong-audit`	Logs de auditoría de Kong → hallazgos de cambio de config	approximate
`ai-gateway`	Registros de uso de Envoy AI Gateway → muestras de coste (FinOps)	flujo de coste
`git`	Vínculo de publicación Git simple: la fila del roster que aprueba un remoto Git SSH o HTTPS para pushes de gitpublish	No observa nada; solo push (un remoto simple no tiene API de pull requests ni de merge)
`github`	Repositorios GitHub como fuentes de datos de agentes → aristas de acceso R/RW observadas (webhook primero, reconciliación por polling de API) + aristas ACL permitidas	observado + permitido; streaming (`poll_seconds: 0`)
`gitlab`	Repositorios GitLab → aristas de acceso R/RW observadas + aristas ACL permitidas	observado + permitido; streaming (`poll_seconds: 0`)

Observadores de postura — hallazgos, no aristas de acceso

Observadores de lectura primero que exponen postura (sync/salud/drift, anomalías de auth) como hallazgos; nunca mutan el estate.

Kind	Observa
`runtime`	Dónde corren las cargas de trabajo de IA (procfs de Linux, demonio Docker, API de Kubernetes) → aristas de contención + hallazgos de salud (necesita acceso al host — ver Requisitos de despliegue)
`argocd` / `flux` / `crossplane`	CRDs de GitOps / control plane → postura de sync, salud, drift, composición
`kerberos`	Telemetría de auth del KDC → hallazgos de Kerberoasting
`aaa`	Observaciones AAA de RADIUS / TACACS+
`ssf`	Receptor de Shared-Signals / CAEP (kill-switch de agentes)
`edugain` / `openidfed`	Agregado de federación / cadenas de confianza OpenID-Federation → postura de federación
`managed-settings`	Política `managed-settings` de Claude → aristas permitidas + hallazgos de drift
`envoy-ai-gateway`	Exportación de configuración declarada de Envoy AI Gateway → postura del gateway + drift de política gateway-frente-a-Olivares (el hermano de configuración del flujo de uso `ai-gateway`)
`kong-agent-gateway`	Exportación de configuración declarada de Kong agent-gateway → postura + drift de política
`litellm`	Exportación de configuración declarada del proxy LiteLLM → postura + drift de política
`bedrock-kb`	Salud/configuración de recuperación de Amazon Bedrock Knowledge Bases (health check Retrieve de Agent Runtime) → hallazgos de postura por KB + aristas KB→fuente de datos. Nunca `RetrieveAndGenerate` (sin inferencia facturable), nunca contenido completo del documento
`tak`	Postura de `CoreConfig.xml` de TAK Server (+ prueba mTLS opcional) e ingest gobernado y de datos mínimos de Cursor-on-Target (posiciones resumidas, uid hasheado)
`a2a`	Peers de Agent2Agent (A2A) v1.0 → descubrimiento de Agent Card + verificación de firma JWS/JCS (nivel de confianza del peer) e interacciones observadas de tarea/mensaje como aristas agente↔agente. Solo observación: nunca despacha una tarea; emitir cards firmadas es una capacidad separada

Indicio no fiable — introspección MCP

La fuente mcp introspecciona servidores MCP (stdio + Streamable HTTP) y emite aristas de capacidad que llevan los indicios R/RW declarados del servidor, más hallazgos de protocol-revision, feature-surface y registry-provenance. Según la especificación MCP, una anotación de herramienta es una declaración no fiable — una afirmación de capacidad, corroborada contra una fuente observada, nunca fiada por sí sola. (La fuente cooperativa claude también introspecciona MCP como parte de su ruta OTLP; mcp es el introspector independiente que apuntas a una lista de servidores o a un .mcp.json.)

Kind	Observa	Nivel
`mcp`	tools/resources/prompts de servidor MCP → aristas de capacidad-declarada + hallazgos de postura	indicio no fiable

Observadores de broker y mesh fuera de proceso

Estos llevan árboles de dependencias de protocolo de wire pesados, así que cada uno corre fuera de proceso (la dependencia nunca se enlaza con el core). Un conector alcanza muchos targets.

Kind	Observa
`kafka`	Actividad de topics de Kafka / Event Hubs / Redpanda / MSK
`amqp`	Brokers AMQP (RabbitMQ, Azure Service Bus)
`nats` / `mqtt` / `cloudqueue`	Actividad de NATS, MQTT, cloud queue
`debezium`	Flujos de change-data-capture de Debezium
`envoy`	Servicios de observación Envoy ALS / ext_authz / ext_proc
`hubble`	Datos de flujo de Cilium Hubble

Proveedores de roster de identidad

Estos pueblan el roster de identidad no humana que afina la atribución (convirtiendo aristas approximate en attributed). Cada fuente con una superficie de grants también emite sus aristas de acceso-permitido (SignalPolicy) desde Gather — el lado PERMITIDO del diff permitido-frente-a-observado:

Kind	Roster	Aristas permitidas
`vault`	entidades, grupos, políticas	grants de path de política ACL (`vault.path`), expandidos por entidad enlazada
`ldap`	usuarios, cuentas de servicio/computer, grupos	membresía de grupo privilegiado → grants de directorio (`ldap.directory`)
`idp` (Okta / Entra)	usuarios, apps/service principals, grupos	grants de app-assignment / scope (`okta.app` / `entra.app`)
`infisical`	identidades de máquina, miembros de org, proyectos	grants de proyecto (`infisical.project`)
`keycloak`	realms, clients, roles, grupos, usuarios	solo roster (`Gather` no-op)
`pingone` / `forgerock`	Rosters de directorio de PingOne / ForgeRock mediante el mismo lector multiproveedor (el kind establece el `provider` correspondiente; `ping` es alias de `pingone`)	solo roster (`Gather` no-op)
`spiffe`	entradas de registro de SPIRE	solo roster (`Gather` no-op)

Cablea as_source: true en la entrada identity para una pasada de grants permitidos de una sola vez por arranque, o una entrada sources separada con poll_seconds para re-escaneos periódicos. Cada entrada se registra con su propio name, así que varias entradas de un mismo kind conviven: okta y entra los sirve el único conector idp y siguen siendo dos fuentes distintas, cada una con su configuración, su estado y su ciclo de vida. Lo que debe ser único es el nombre, no el conector. Las membresías de grupo/rol viajan solo en el snapshot tipado del roster, nunca como aristas.

Federación de identidad de agentes

Los registros de agentes de los hyperscalers federan de solo lectura contra el roster SPIFFE/WIF del plano. Sus filas por agente (kinds agent_identity / workload_identity) son identidades dedicadas, no compartidas, así que el access map las trata como atribución firme por agente; las filas auxiliares de las mismas fuentes (blueprint principals, proveedores de credenciales, agentes respaldados por service-account) se quedan aproximadas. La federación nunca escribe a un registro; exportar a las torres de control es una capacidad separada y posterior.

Kind	Federa	Gather
`entra-agent`	Microsoft Entra Agent ID (identidades de agente, usuarios de agente, blueprints, blueprint principals, owners/sponsors, cómputo de huérfanos en snapshot, soft-deleted opt-in) vía Graph v1.0	hallazgos de drift `nhi_longlived_credential`, hallazgos de postura CA/agente de riesgo/gobierno/sin sponsor y aristas observadas de acceso de agentes de `auditLogs/signIns` beta opt-in — añade una entrada `sources` con `poll_seconds`
`agentcore`	AWS Bedrock AgentCore Identity (workload identities, proveedores de credenciales de token-vault) + motores AgentCore Policy/políticas Cedar como colecciones	hallazgos de drift `nhi_longlived_credential` (proveedores de API-key estática) — añade una entrada `sources` con `poll_seconds`
`google-agent`	Google Agent Identity (reasoning engines de Agent Runtime; identidades de agente basadas en SPIFFE), además de postura de Agent Registry / Agent Gateway. Las filas usan el SPIFFE ID completo como ref, convergiendo con el roster `spiffe`; Gather detecta agentes de registro no atribuidos, reasoning engines en sombra fuera de un registro legible, anotaciones de herramientas MCP de riesgo y postura del registro del gateway	hallazgos de postura de registro/gateway y detección de agentes en sombra — añade una entrada `sources` con `poll_seconds`
`agent365`	Registro de Microsoft Agent 365 (inventario a nivel de paquete, incluidos agentes sin una identidad Entra) mediante Graph v1.0, credenciales de cliente con permisos de aplicación o token delegado, detalles de paquete opt-in	hallazgos de higiene del registro (paquetes desplegados bloqueados; paquetes externos/compartidos desplegados para todos los usuarios) — añade una entrada `sources` con `poll_seconds`
`foundry-agents`	Proyectos Microsoft Foundry, aplicaciones/deployments de agentes y agentes actuales de Agent Service mediante ARM + Foundry Agent Service v1; correlaciona los enlaces de identidad de app con `entra-agent`	hallazgos de postura de aplicación derivados de ARM (falta identidad de agente Entra; deployment fallido en una app habilitada) — añade una entrada `sources` con `poll_seconds`
`ai-control-tower`	Inventario de digital-asset de ServiceNow AI Control Tower (Table API, solo lectura)	no-op (solo roster)
`oasf`	Descriptores de agente AGNTCY/OASF + verificación de Agent Badge — EXPERIMENTAL hasta que la especificación de identidad sea conforme a VCDM 2.0	hallazgos de badge — añade una entrada `sources` con `poll_seconds`
`onepassword`	Cuenta 1Password como custodio `secret_store`	aristas de acceso a secretos por item-usage — añade una entrada `sources` con `poll_seconds`

Para los siete kinds con un Gather re-poleable (entra-agent, agent365, agentcore, foundry-agents, google-agent, oasf, onepassword), cablea la mitad del roster como una entrada identity sin as_source y la mitad de aristas/hallazgos como una entrada sources separada con poll_seconds — no ambas vía as_source: true, que corre el escaneo solo una vez por arranque. (Dos entradas de un mismo kind ya no son el obstáculo: cada una se registra con su propio name. La razón es la cadencia: una pasada por arranque no es un re-escaneo.)

El owner/sponsor declarado por el registro aterriza en los registros de ciclo de vida NHI durante el sync del roster (la misma semántica que PUT /nhi/{ref}/ownership), y un huérfano afirmado por el registro (un agente Entra cuyo blueprint ha desaparecido) aterriza en el flag registry_orphaned del mismo registro — el barrido de ciclo de vida lo combina con OR en orphaned y emite el hallazgo nhi_orphaned, así que la detección de huérfanos vigila agentes federados con cero cableado extra. La fuente vault-audit (bajo sources, no identity) sigue el dispositivo de auditoría de fichero de Vault y emite la contraparte OBSERVADA de los grants permitidos de vault para las mismas refs entity:<name>.

Fuentes de documentos de conocimiento (no es cobertura de access-map)

Estas alimentan el módulo de conocimiento (módulo VIII), no el access map: ingestan contenido de documento para recuperación gobernada, emiten ninguna arista R/RW y no producen ninguna observación en el bus. El módulo los extrae (List → Fetch) ante una petición de ingest (POST /v1/m/knowledge/kbs/{id}/ingest {"source":"<name>"}), así que están cableados en ese módulo — nómbralos bajo documents en OLIVARES_SOURCES_CONFIG, no sources. Cada uno es de solo lectura y datos mínimos: lleva la ACL y la procedencia de la fuente (nunca un email personal; el módulo expurga el cuerpo antes de persistir).

Kind	Ingesta
`gdrive`	Documentos de Google Drive (Docs/Sheets/Slides/ficheros)
`confluence`	Espacios y páginas de Atlassian Confluence
`notion`	Workspaces, bases de datos y páginas de Notion
`sharepoint`	Sitios y documentos de Microsoft SharePoint / OneDrive (Business)
`s3content`	Contenido de object-storage (objetos S3 / R2 / GCS)
`sap_odata`	Entidades de servicios SAP OData como documentos gobernados (Business)
`salesforce`	Objetos/registros de Salesforce como documentos gobernados (Business)
`snowflake`	Tablas/filas de Snowflake como documentos gobernados (distinto del observador R/RW `snowflake-audit`)
`azure_ai_search`	Documentos de índices de Azure AI Search
`postgres`	Filas de PostgreSQL como documentos gobernados — solo lectura por construcción, ACL declarada por fila, clasificación por columna (distinto del observador R/RW `pgaudit`; no es NL-to-SQL). Consulta Postgres como fuente de contexto gobernada.
`filesystem`	Contenido de servidor de ficheros (local / NFS / SMB) — lectura confinada a la raíz por construcción, owner/group/ACL POSIX mapeados a ACL de documentos, clasificación xattr (distinto del sink de logs `filelog`). Consulta Gobierna tu servidor de ficheros.

// OLIVARES_SOURCES_CONFIG — las fuentes de documentos van bajo "documents", nunca "sources"
{
  "documents": [
    { "name": "eng-wiki", "kind": "confluence",
      "config": { "export_path": "/var/lib/olivares/confluence" } }
  ]
}

Destinos de salida (no es cobertura)

Los conectores de salida entregan hallazgos y notificaciones; no observan nada y no tienen nivel de cobertura. Se cablean por separado de las fuentes.

Kinds de destino en proceso: slack, teams, pagerduty, opsgenie, webhook, siem, splunkhec, syslog, servicenow, jira, email, twilio, chronicle, datadog, elastic, snmp, filelog, otlplog (logs OTLP/HTTP), s3archive (Business: Regulated Operations) (el sink WORM de S3 Object Lock: un objeto inmutable y con bloqueo verificado por notificación) y teamsbot (Business: Regulated Operations, el conector de Teams con bot registrado del ciclo de incidentes; un binario Community omite un destino de ese tipo con una línea de log que nombra Business).

Tres kinds de egreso a brokers se ejecutan fuera de proceso como plugins embebidos (sus árboles de dependencias del protocolo de wire nunca se enlazan al motor, exactamente igual que las fuentes plugin): kafka, amqp y cloudqueue — los mismos nombres de kind que sus gemelos de fuente; como destino, cada uno entrega la notificación como CloudEvent al broker/cola configurado. Una build sencilla de desarrollo sin task build:connectors omite ese destino con un aviso honesto en el arranque, en lugar de fingir que existe.

Requisitos de despliegue y atribución honesta

Los conectores de diferencial R/RW están cableados en el binario por defecto, pero dos conllevan un requisito de despliegue que el resto no — el código del conector es agnóstico del host, los datos que consume no:

ebpf consume la exportación de eventos de kernel de Tetragon. El conector no necesita ninguna capability de kernel — lee un fichero/FIFO/stdin 0600 que Tetragon posee (events_path, default -). Tetragon mismo es un DaemonSet aparte, endurecido que sostiene los mínimos CAP_BPF + CAP_PERFMON, corriendo sin root con seccomp/AppArmor y sin listener entrante. Así que el despliegue es: corre Tetragon privilegiado (sus TracingPolicies de acceso a fichero + conexión TCP empaquetadas), luego apunta ebpf a su exportación. Tetragon mínimo: v1.0.
runtime lee el procfs del host (proc_root, default /proc), el socket del demonio Docker (docker_socket, off por defecto — el acceso de lectura a docker.sock es equivalente a root; haz opt-in deliberadamente, idealmente vía un proxy de socket con allowlist de GET) y/o la API de Kubernetes (ServiceAccount in-cluster por defecto). Monta solo lo que habilites.
gcp-audit se autentica como una service account de GCP (key JSON o un access_token emitido por WIF/ADC) y necesita solo roles de gestión de solo lectura: roles/resourcemanager.organizationViewer + roles/iam.serviceAccountViewer + roles/logging.viewer — leer entradas de Data Access necesita adicionalmente roles/logging.privateLogViewer. Acota organization_id (org walk + auditoría con scope de org) y/o projects. Los logs de auditoría de Data Access están off por defecto en GCP: habilítalos según la config de IAM/data-access, o el feed de actividad sub-reporta honestamente.
azure-activity se autentica como un service principal de Entra (client-credentials) o un access_token de managed-identity, y necesita solo el rol Reader en la raíz del tenant (o por subscription) — ese único rol cubre Resource Graph, el listado de subscriptions y el Activity Log. Las subscriptions se listan automáticamente cuando subscriptions no está fijado.

Ambos corren en proceso, como todo tipo no listado como plugin en Modo de proceso por tipo. Para ejecutar uno en su propio proceso, compila su programa connectors/<kind>/cmd/ y admítelo como plugin externo.

Toda fuente es opt-in, deny-closed: un log_path/path/events_path faltante es un error de configuración en el arranque (la fuente no se cablea), nunca un no-op silencioso. El estate de demo (quickstart) siembra observaciones sintéticas equivalentes a través del bus real para que puedas ver la señal de nivel limpio de extremo a extremo antes de cablear una fuente en vivo.

Relacionado

Conectar una fuente — el modelo de conector y cómo cablear uno.
Conectar Claude Code — la ruta cooperativa de extremo a extremo.
Módulo III — el access map — en qué se convierten las aristas.
Honestidad y límites — el contrato honesto de todo el producto.