Catalogue des connecteurs et niveaux de couverture

Cette page est le catalogue des connecteurs first-party et, pour chacun, le niveau de couverture honnête qu’il peut prendre en charge. Elle complète connecter une source, qui explique le modèle de connecteur (observe-only, minimal-data, les trois types d’observation) — lisez-la d’abord. Cette page répond à la question suivante : quelles sources existent, et à quel point le signal de chacune est-il bon ?

La couverture est classée par niveaux selon ce que la surface d’audit d’un système peut honnêtement vous dire, jamais selon ce qu’on voudrait qu’elle puisse dire. Les niveaux, tels qu’employés dans toute la documentation :

Cooperative — un agent ou une plateforme qui rapporte ce qu’il a fait (OpenTelemetry, une API admin d’un éditeur). Fidélité la plus élevée lorsqu’elle est présente ; dépend de la coopération de la source.
Clean — un store qui classe lecture vs écriture nativement, repris tel quel depuis sa propre piste d’audit (audit SQL, journaux d’accès aux données d’un object-store / entrepôt).
Lossy — un store dont l’audit ne sépare pas proprement lecture et écriture, ni appelant et appelant (document stores, lineage). Les arêtes apparaissent, mais souvent en approximate.
Impossible passively — un système sans surface d’audit passive exploitable (caches en mémoire, bases de données embarquées en fichier unique). Il n’y a pas de signal read-first honnête ; le produit ne prétend pas le contraire.
Approximate-by-attribution — l’accès est réel mais l’attribution se fait à un rôle, un processus ou une credential partagée, et non à un agent résolu ; l’arête est donc approximate.
Untrusted hint — une capacité déclarée (une annotation d’outil MCP), corroborée, jamais accordée seule.

Cette liste recense les connecteurs enregistrés dans le jeu de connecteurs du binaire par défaut aujourd’hui — c’est-à-dire les kinds que vous pouvez nommer dans OLIVARES_SOURCES_CONFIG et faire câbler par le moteur. Le produit est en pré-1.0. Les connecteurs canoniques de l’access-map R/RW — pgAudit, S3/CloudTrail, le backstop eBPF/Tetragon, l’inventaire runtime et l’introspection MCP — ainsi que les sources de documents de connaissance sont désormais câblés et configurables dans un serve standard ; certains comportent des exigences de déploiement (un capteur Tetragon, un accès hôte) couvertes dans Exigences de déploiement ci-dessous. La couverture est classée honnêtement par niveaux : la présence d’un connecteur ici n’est pas une affirmation d’attribution per-agent ferme, qui reste la dépendance dure (un compte partagé fait retomber même un store de niveau clean à approximate).

Mode de processus par type

Chaque type utilise exactement un mode de processus fixé par le moteur :

Plugin hors processus. Le moteur embarque le connecteur comme programme séparé, le lance en sous-processus confiné (environnement limité ; utilisateur et cgroup dédiés lorsque l’hôte le permet) et communique via gRPC avec AutoMTLS. Ses dépendances ne sont jamais liées au moteur. Types de sources : claude, cowork, kafka, amqp, nats, mqtt, cloudqueue, debezium, envoy, hubble. Types de destinations : kafka, amqp, cloudqueue. Un build sans task build:connectors ne les embarque pas et le démarrage avertit pour chaque connecteur configuré.
In-process. Tous les autres types de cette page. Le connecteur est lié au binaire du moteur et s’exécute dans son processus ; une panic est contenue et la source est marquée failed.
Plugin externe. Une source ou destination configurée avec plugin (chemin du binaire, digest épinglé et signature vérifiée contre connector_trust) tourne toujours hors processus, avec le même confinement. Les programmes connectors/<kind>/cmd/ du dépôt pour les types in-process ne font pas partie de la release ; construisez-en un et admettez-le ainsi (exploiter un plugin) pour exécuter ce connecteur dans son propre processus.

Quand le processus d’un plugin source meurt, le moteur relance le même binaire, revérifie le digest épinglé d’un plugin externe, le rouvre avec les paramètres de la source et reprend la collecte. Le premier redémarrage attend environ une seconde ; l’attente double à chaque redémarrage, jusqu’à cinq minutes, puis revient à une seconde après cinq minutes de fonctionnement. De la détection de la mort du processus au démarrage du nouveau, la source indique failed, avec l’erreur de redémarrage tant qu’une tentative échoue.

Un plugin destination est relancé de la même façon lorsqu’une livraison échoue et que son processus est mort : le moteur relance le binaire (avec nouvelle vérification du digest d’un plugin externe) et l’ouvre avec les paramètres de la destination. La livraison qui a détecté sa mort reste signalée comme échouée, avec l’erreur de redémarrage si celui-ci a été refusé, et la progression des retries de notification la réessaie contre le nouveau processus. Le premier redémarrage est immédiat ; les suivants attendent une seconde, doublent jusqu’à cinq minutes et repartent de zéro si la dernière tentative date de plus de cinq minutes. Une destination sans livraison ne redémarre qu’à l’arrivée d’une livraison.

Le plugin relancé utilise les paramètres avec lesquels son connecteur a été ouvert. Un secret modifié ou renouvelé lui parvient donc lors du rechargement de la configuration ou du redémarrage du moteur, comme pour un plugin jamais arrêté. Un plugin dont le processus vit mais dont la collecte ou la livraison échoue n’est pas relancé : cette défaillance est celle du connecteur.

Cooperative — télémétrie Claude et éditeurs

Les sources de plus haute fidélité lorsqu’elles sont présentes. La source runtime de Claude Code s’exécute hors processus sous forme de plugin embarqué (un simple build de dev l’omet et le boot le signale honnêtement plutôt que d’avoir l’air sain).

Kind	Observe	Notes
`claude`	Télémétrie d’outils OTLP de Claude Code + introspection MCP → arêtes / coût / findings	Plugin hors processus ; `attributed` quand une identité per-agent est présente, sinon `approximate`
`claude-api`	Échantillons de coût de l’Admin API Claude + findings de posture de gouvernance	In-process ; no-op hors ligne (pas de clé admin)
`claude-compliance`	Preuves du flux d’activité Compliance de Claude → findings	GET-only par construction ; no-op hors ligne (Business)
`claude-config`	Arbre de configuration Claude statique (subagents / Skills / plugins) → arêtes de capacité déclarée	Métadonnées uniquement — une surface de capacité, pas un accès observé
`claude-console`	IAM de l’organisation Claude → findings de posture SSO/SCIM (roster d’identités + source)	Business: Identity & Scale;
`claude-wif`	Roster d’identités non-humaines / workload-identity Anthropic + arêtes de scope permis	Business: Identity & Scale; Modélise la fédération déclarée par l’opérateur ; signale les pièges des clés statiques
`claude-managed-agents`	Inventaire des managed agents Claude + événements de threads (récepteur webhook + pollers GET)	Source en streaming (`poll_seconds: 0`) ; hors ligne, c’est un no-op
`claude-projects`	Inventaire des Projects de Claude Organization (appartenance / clés API) + politique de projet déclarée par l’opérateur	Admin API en lecture seule ; no-op hors ligne
`claude-apps-gateway`	Posture d’apps-gateway Claude, octrois de modèles déclarés et ingest d’événements d’audit → topologie + findings	Lit un `gateway.yaml` existant et un export d’audit JSONL facultatif
`claude-batch`	Inventaire d’Anthropic Message Batches + Files API, application des politiques de batch et expiration de la rétention des uploads	Ne lit jamais les payloads ni le contenu des fichiers ; finding hors ligne honnête sans clé admin
`claude-routines`	Inventaire de Claude Code Routines (déclencheurs planifiés) → arêtes + findings de cadence/revue	GET-only ; le contenu des prompts est uniquement haché ; streaming (`poll_seconds: 0`)
`cowork`	Récepteur de logs OTLP/HTTP Claude Cowork → preuves d’activité	Plugin hors processus (isolation des dépendances OTel-proto)
`cowork-analytics`	Analytique d’engagement Claude Cowork	In-process (client modelprovider uniquement)
`codex`	Échantillons de coût OpenAI Codex, preuves d’usage/auth/audit admin et findings d’adoption	Admin API en lecture seule ; les surfaces soumises à la vente se dégradent en finding de posture
`cursor`	Coût facturé par l’Admin API Cursor, journaux d’audit de l’équipe, inventaire des membres et posture budgétaire	Un 403/404 lié au plan se dégrade en finding, sans jamais faire échouer la source

Profil framework GenAI vendor-neutral (`gen_ai.*`) — opt-in

Les frameworks d’agents que le catalogue promet — LangGraph / LangChain, CrewAI, AutoGen / Microsoft Agent Framework, Google ADK (et le SDK OpenAI, LlamaIndex, Pydantic-AI, Strands, …) — n’émettent pas le schéma claude_code.* de Claude. Ils convergent vers les conventions sémantiques OpenTelemetry GenAI (gen_ai.*). La même source claude ingère aussi ce profil, si bien qu’une flotte instrumentée OTel alimente l’access map et les FinOps via un seul ingest plutôt qu’un connecteur sur mesure par framework — l’intégration au plus fort effet de levier.

Ce profil est OPT-IN et honnêtement étiqueté expérimental. Toute la zone gen_ai est au statut OpenTelemetry Development (pas Stable, juin 2026), elle ne s’active donc que lorsque vous reproduisez le propre gate de la spec. Réglez le semconv_opt_in du connecteur sur une liste séparée par des virgules contenant le token gen_ai_latest_experimental (en miroir de OTEL_SEMCONV_STABILITY_OPT_IN). Désactivé par défaut, un signal gen_ai.* alimente quand même le watchdog de silence mais ne mappe aucune arête/coût — nous ne revendiquons jamais une stabilité que les conventions n’ont pas.

Parce que les conventions sont en pleine mutation, l’ingest est dual-name (il lit la clé actuelle et le prédécesseur déprécié encore émis dans la nature) et multi-signal (il mappe les spans de trace, l’event de log gen_ai.client.inference.operation.details et reconnaît les métriques client) :

Ce qu’il lit	Clé actuelle	Aussi accepté (déprécié, encore émis par)
Provider	`gen_ai.provider.name`	`gen_ai.system` (défaut v1.36.0-ou-antérieur ; Google ADK, p. ex. `gcp.gemini`)
Tokens d’entrée	`gen_ai.usage.input_tokens`	`gen_ai.usage.prompt_tokens` (OpenLLMetry/Traceloop → LangChain/LangGraph/CrewAI)
Tokens de sortie	`gen_ai.usage.output_tokens`	`gen_ai.usage.completion_tokens` (idem)

Attribut gen_ai	mappe vers	confiance
`gen_ai.usage.*` (tokens)	`CostSample` (provenance estimated — tokens, pas coût facturé)	—
`gen_ai.provider.name` / `request.model` / `response.model`	provider de coût + modèle (response préféré)	—
`gen_ai.operation.name = execute_tool` + `gen_ai.tool.name`	arête d’accès agent→outil (mode `unknown`)	`attributed`
`gen_ai.conversation.id` + `gen_ai.agent.{name,id}`	arête d’attribution conversation→agent + ref de session	`attributed`

Matrice de dialectes supportés (normalizer multi-génération)

Les conventions GenAI ont changé en trois générations qui coexistent dans les flottes réelles de 2026. L’ingest détecte la génération par signal à partir de marqueurs exclusifs à chaque génération et estampille l’event normalisé avec le pin semconv correspondant (le finding de posture genai.semconv enregistre le jeu actif par run ; un finding drift info par run signale chaque dialecte déprécié vu, afin que vous sachiez quelles flottes doivent mettre à niveau leur instrumentation). Le contenu des messages n’est jamais lu, quelle que soit la génération — les clés de contenu ne servent que de marqueurs de dialecte (posture minimal-data).

Dialecte détecté	Pin estampillé	Marqueurs exclusifs (vérifiés)	Émis par (vérifié juin 2026)
Legacy OpenLLMetry/Traceloop (pre-semconv)	`openllmetry`	`gen_ai.prompt.{i}.` / `gen_ai.completion.{i}.` indexés, `gen_ai.usage.prompt_tokens`/`completion_tokens`, `llm.usage.total_tokens`, `llm.request.type`, `llm.vendor`, `traceloop.span.kind`	LangChain / LangGraph / CrewAI instrumentés Traceloop épinglés < openllmetry v0.55.0 (sorti le 2026-03-29). Les providers en majuscules (`OpenAI`, `Langchain`) sont mis en minuscules pour que les FinOps ne se scindent pas selon la casse
events v1.36-ou-antérieur (le nom propre de la spec)	`1.36.0`	`gen_ai.system` ; les cinq events de log par message `gen_ai.{system,user,assistant,tool}.message`, `gen_ai.choice` (reconnus par nom — leur unique attribut est optionnel)	spans LLM Google ADK (`gcp.vertex.agent`), AutoGen (`autogen`), Microsoft Agent Framework — tous émettent encore `gen_ai.system`
messages v1.37+ (actuel)	`1.41.1`	`gen_ai.provider.name`, `gen_ai.input.messages` / `gen_ai.output.messages` / `gen_ai.system_instructions`, l’event `gen_ai.client.inference.operation.details`, `gen_ai.workflow.name`	instrumentations officielles OTel ; openllmetry ≥ v0.55.0

Un signal ne portant que des clés dont les noms sont identiques d’une génération à l’autre (p. ex. un span ADK invoke_agent : operation + agent + conversation, aucune clé provider) est normalisé sous le pin actuel — le mapping appliqué est identique au byte près, et la vraie release du producteur n’est pas déductible du wire.

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

Exactement quatre attributs mcp.* existent en amont (mcp.method.name, mcp.protocol.version, mcp.resource.uri, mcp.session.id) ; l’outil voyage sur gen_ai.tool.name et le prompt sur gen_ai.prompt.name. L’ingest joint ces traces aux propres faits de gouvernance MCP du produit en réutilisant les mêmes resource kinds qu’émet le chemin Claude :

Signal MCP	mappe vers
tout span `mcp.*` côté client avec `server.address`	arête session→`mcp.server` (rejoint les arêtes `claude_code.mcp_server_connection`)
`tools/call` + `gen_ai.tool.name`	arête d’accès `mcp.tool` (`server.address/tool` quand l’endpoint est connu) — le même kind que les invocations `mcp__server__tool` de Claude
`resources/read` / `resources/subscribe` + `mcp.resource.uri`	arête `mcp.resource` en mode lecture (URI nettoyée : credentials/query supprimés)
`prompts/get` + `gen_ai.prompt.name`	arête `mcp.prompt` en mode lecture (surface de prompt)
spans de kind SERVER / métriques `mcp.client	server.*.duration`

Spans d’agent (split client/internal de `invoke_agent` + `invoke_workflow`, semconv v1.41 — Development)

v1.41.0 a scindé invoke_agent en une variante CLIENT (service d’agent distant) et une variante INTERNAL (in-process). Les frameworks réels violent le kind aujourd’hui (AutoGen et Microsoft Agent Framework codent en dur CLIENT pour des agents in-process ; Google ADK utilise INTERNAL), aussi l’ingest ne classe une invocation comme distante que lorsque le span est CLIENT et porte un server.address — ce qui produit une arête de délégation conversation→genai.agent.remote. Tout le reste demeure une invocation in-process couverte par l’arête d’attribution conversation→genai.agent : dégradé proprement, jamais un « remote » fabriqué. invoke_workflow (nouveau en v1.41 ; équipes de style CrewAI) mappe une arête conversation→genai.workflow. Les spans d’agent restent en Development (expérimental) en amont — aucune stabilité n’est revendiquée.

Stable vs expérimental, honnêtement : le mécanisme (gate opt-in, détection de dialecte + lectures dual-name, mapping span/event/métrique, les shapes scellées CostSample/EdgeObservation) est stable dans ce produit. Le vocabulaire qu’il mappe (clés gen_ai.*/mcp.*, l’enum d’opération) est en Development amont et pourra être renommé à nouveau ; c’est exactement pourquoi l’ingest normalise chaque génération plutôt que d’en épingler une. v1.41.1 est la dernière release versionnée des conventions gen-ai (elles ont migré vers open-telemetry/semantic-conventions-genai, qui n’a aucune release en juin 2026). Notes :

Le coût est dédupliqué par span id W3C. Lorsqu’une opération rapporte un usage à la fois sur son span et sur son event operation.details (ils partagent un span id), il est facturé une fois, pas deux.
Les métriques alimentent la liveness, jamais le coût. gen_ai.client.token.usage est un agrégat ; le span/event est l’usage par opération faisant autorité, si bien que facturer aussi la métrique double-compterait. Les histogrammes de durée mcp.* v1.39 sont reconnus de la même façon.
Le provider peut être unknown. Si un span porte un modèle mais pas de provider/system, le coût est attribué à unknown plutôt que deviné depuis l’id du modèle.
Un total-only de tokens n’est pas scindé. Le legacy llm.usage.total_tokens sans split prompt/completion n’est jamais deviné en entrée/sortie (pas de coût fabriqué).
OpenInference (Arize/Phoenix) est une convention différente et n’est pas ingérée par ce profil — les clés llm.* lues ici (llm.request.type, llm.usage.total_tokens, llm.vendor) sont des marqueurs legacy OpenLLMetry, pas le namespace llm.* d’OpenInference.

Cooperative — configuration de la surface de l’agent local

Ces sources lisent la configuration déclarée d’un agent local et émettent des arêtes permises, ainsi que des findings de posture. Ce ne sont pas des traces d’exécution en direct ; lorsqu’un framework dispose d’OTEL natif, l’usage live arrive toujours par l’ingest gen_ai.* ci-dessus.

Kind	Observe	Couverture honnête
`opencode`	Couches JSONC locales `opencode.json` / `opencode.jsonc` → posture des permissions, posture managed/admin-override, arêtes permises de MCP/outils/agents personnalisés, findings de credential-in-config/share/autoupdate/OTEL et fragment d’authoring	Configuration déclarée uniquement. La couche managed est détectée localement, mais ce n’est pas un verrou immuable : `OPENCODE_PERMISSION` au runtime, la redirection du répertoire de tests et la configuration distante de l’organisation restent hors de ce lecteur. OTEL natif, lorsqu’il est activé, peut alimenter l’usage live `gen_ai.` via l’exporteur `OTEL_` hors bande
`gemini-cli`	Couches `settings.json` Gemini CLI (système/utilisateur/workspace) → arêtes permises de MCP/outils, posture de lacune d’application et inventaire de configuration effective	Configuration déclarée uniquement ; l’usage live passe par l’ingest `gen_ai.*` (la CLI l’émet nativement). Ce n’est pas l’API Gemini (qui relève de la surface de fournisseur hébergé)
`openhands`	`config.toml` + environnement OpenHands → posture de sandbox/épinglage de modèle/credential/télémétrie et arêtes permises de MCP/actions	Configuration déclarée uniquement ; usage live via OTEL `gen_ai.*` natif
`goose`	`profiles.yaml` + environnement Goose (Block) → posture des réglages admin/de l’épinglage de modèle/des extensions/de l’approbation des outils et arêtes permises d’extensions	Configuration déclarée uniquement
`cline`	Namespaces Cline / Kilo Code dans le `settings.json` VSCode → posture d’approbation automatique/allowlist MCP/credential/épinglage de modèle	Configuration déclarée uniquement ; pas d’OTEL natif en amont
`grok`	Grok Build (xAI), l’agent de code en terminal : configuration locale, câblage des hooks, événements avec veto documenté et posture de gouvernance déclarée	Posture d’agent déclarée par configuration. Le connecteur API `xai` lit catalogue et coûts des modèles, dont `grok-build-0.1` comme modèle ; ce connecteur lit l’agent. L’observation live utilise l’ingest OTLP émis par Grok Build. `PostureEnforced` s’applique uniquement à `PreToolUse`, seul événement avec veto documenté ; les autres sont `observed`
`openclaw`	`openclaw.json` OpenClaw (découverte JSON5, `$include` confiné) → posture gateway/canal/outil/sandbox/skill/modèle par agent et arêtes déclarées de canal/skill/modèle	Configuration déclarée uniquement ; aucun hook PEP inline vérifié en amont
`hermes`	`config.yaml` + arbres de profils + scope managed Hermes Agent → posture terminal/canal/skill/sécurité/modèle/MCP et arêtes déclarées	Configuration déclarée uniquement ; aucun hook PEP inline ni OTEL natif vérifié en amont
`paperclip`	API REST Paperclip (clé API du board, GET uniquement) → entreprises comme collections de groupes et agents comme lignes de roster NHI (`paperclip/<adapterType>`, rôle, titre, `reports_to`), nombres de runs par jour terminé, échantillons de coût indicatifs (`cost_type=paperclip`)	Observation seule : ne démarre ni ne confine les agents Paperclip. Le coût est agrégé par jour car Paperclip ne fournit pas de liste brute d’événements de coût ; une partie refusée est signalée comme finding de couverture
`google-adk`	JSON de session Google ADK 2.0 exporté → inventaire agent/app, sous-agents, appels de fonctions d’outils, transferts, drift des outils approuvés et corrélation Vertex reasoningEngine	Export en lecture seule ; jamais le contenu des messages. Distinct de la surface de plateforme `google-agent`
`agents-md`	Parcours du dépôt des fichiers d’instructions d’agents (AGENTS.md et fichiers de mémoire/instructions par agent) → drift de baseline SHA-256 + scan d’injection d’instructions / Unicode masqué / secrets	Données minimales : chemins assainis + détails hachés, jamais le contenu
`mcpb`	Extensions desktop `.mcpb` installées / distribuées → scan de posture du manifeste, drift de l’allowlist enterprise et vérification de signature PKCS#7	PERMIS-vs-OBSERVÉ sur la surface d’extensions
`codex-managed-config`	Fichiers managed-config OpenAI Codex → posture d’application + drift par rapport à la baseline rédigée	Observation uniquement : il ne peut pas empêcher un développeur de contourner la couche managed (le pendant de `managed-settings` pour Codex)

Clean — audit natif du store (lecture/écriture telle quelle)

Ces connecteurs lisent la propre piste d’audit d’un store et reprennent la classification lecture/écriture telle quelle — jamais inférée du texte de la requête. pgaudit et s3cloudtrail sont les sources R/RW canoniques autour desquelles l’access map est construite (leurs alias avec tiret pg-audit / s3-cloudtrail résolvent aussi).

Kind	Observe
`pgaudit`	Piste pgAudit PostgreSQL (csvlog/jsonlog) → accès R/RW aux tables, `READ`/`WRITE` tels quels depuis la CLASS de pgAudit
`s3cloudtrail`	Events S3 d’AWS CloudTrail → R/RW d’objets, lecture/écriture depuis le flag `readOnly` de CloudTrail (fait aussi remonter les invocations de modèles Claude-on-Bedrock)
`snowflake-audit`	Historique d’accès natif Snowflake
`databricks-uc`	Audit Databricks Unity Catalog
`bigquery-audit`	Audit d’accès aux données BigQuery
`redshift-audit`	Audit Amazon Redshift
`mssql-audit`	Audit SQL Server
`oracle-audit`	Audit unifié Oracle (Business)
`gcs-audit`	Audit d’accès aux données Google Cloud Storage
`azure-blob-audit`	Audit Azure Blob Storage

Management plane cloud — inventaire org/tenant + activité du control plane

La parité tri-cloud pour le plane de management — distinct du plane de données par ressource que couvrent les connecteurs d’audit de store ci-dessus. Chacun est un client API vivant, en lecture seule, du control plane org/tenant d’un cloud : il découvre la topologie des ressources (arêtes d’inventaire, mode=unknown, attributed) et lit le flux d’audit natif du cloud pour l’activité du control plane (arêtes identity→…api, classées lecture/écriture). Ils complètent la matrice qu’AWS ancre déjà avec s3cloudtrail (plane de données) plus le connecteur aws IAM/CloudTrail au niveau du compte. Les deux tournent in-process, comme chaque type non listé comme plugin dans Mode de processus par type. Pour en exécuter un dans son propre processus, construisez son programme connectors/<kind>/cmd/ et admettez-le comme plugin externe.

Kind	Observe	Couverture honnête
`gcp-audit`	GCP Resource Manager / IAM (topologie org→folder→project→service-account) + Cloud Audit Logs (Admin Activity + Data Access) → `identity→gcp.api`	Clean là où c’est journalisé : Admin Activity est une écriture par définition du type de log, Data Access est lecture/écriture d’après le verbe de méthode standard. Lossy là où la journalisation Data Access est désactivée (off par défaut dans GCP) ou qu’un verbe de méthode est non standard (`unknown`, jamais deviné). `approximate` pour les principals partagés déclarés ; le `principalEmail` converge avec le roster SPIFFE/SA
`azure-activity`	Azure Resource Graph (topologie tenant→subscription→resource) + Azure Monitor Activity Log (opérations du control plane) → `identity→azure.api`	Clean pour les écritures/suppressions du control plane (telles quelles depuis l’action RBAC). Le suffixe `action` générique est lossy (`unknown` — il peut lire ou écrire). Les lectures du plane de données ne sont pas dans l’Activity Log (le plane de données `azure-blob-audit` / `azurekeyvault` les couvre). `approximate` pour les appelants partagés ; l’`objectId`/`appId` de l’appelant converge avec le roster Entra
`cloudflare`	Estate edge Cloudflare — Workers, buckets R2 et jobs Logpush via l’API REST v4 → arêtes de topologie	Inventaire uniquement (aucun flux d’audit dans ce connecteur) ; jeton en lecture seule à scope limité. Distinct des surfaces IA `cloudflare-ai-gateway` / portails MCP

L’opt-in Data Access de GCP et les trous lecture-non-journalisée d’Azure sont les arêtes honnêtement opaques de ce plane : l’absence d’arête d’activité n’est pas une preuve d’absence d’accès là où ces logs sont désactivés. La table complète de niveaux par cloud se trouve dans le contrat livré du connecteur cloud-management (docs/contracts/S165-connectors-cloud-management.md).

Fournisseurs de modèles hébergés — catalogue, posture et mesure

Ces sources gouvernent les comptes et catalogues des fournisseurs de modèles hébergés. Elles ne font pas proxy de l’inférence ; lorsqu’un fournisseur ne propose pas d’API d’usage exploitable, la dépense est estimée par le Meter du connecteur autour du chemin d’inférence plutôt que tirée d’un flux de facturation agrégé.

Kind	Observe	Couverture honnête
`openai`	Usage et coût de la plateforme OpenAI (API d’organisation), plus catalogue des modèles et clés API	Clé org/admin en lecture seule ; aucun payload du data plane. Distinct de `azure-openai`, qui utilise les véritables surfaces Azure et non les chemins d’organisation OpenAI
`gemini`	Catalogue de modèles hébergés Gemini (Google) et export d’usage câblé par l’opérateur	Surface du fournisseur hébergé. Distincte de `gemini-cli`, qui observe les réglages locaux de la CLI, et de `vertex`, qui couvre les surfaces Vertex enterprise. Google n’expose aucune API d’usage agrégé sur ce chemin ; l’usage est donc celui que câble l’opérateur
`deepseek`	Catalogue hébergé DeepSeek, disponibilité du solde du compte et posture de souveraineté PRC	Aucune API d’usage agrégé ; coût mesuré autour de l’inférence à partir du tarif déclaré
`mistral`	Catalogue Mistral et posture de gouvernance	Aucune API publique d’usage/facturation/plafond de dépense ; coût mesuré autour de l’inférence à partir du prix catalogue
`xai`	Catalogue xAI/Grok en direct, endpoints de facturation, inventaire clés/ACL et posture de crédit et de plafond de dépense	Utilise les endpoints de gestion de facturation en lecture seule pour le coût ; les credentials de gestion et d’inférence sont distincts
`glm`	Catalogue déclaré Zhipu GLM / Z.ai, Meter de prix catalogue en USD, sonde d’entitlement et posture de souveraineté	Catalogue uniquement + Meter : GLM n’expose aucune API vérifiée d’usage, facturation, solde, admin, clés ou organisation. La réserve liée à la PRC / Entity List s’applique aux surfaces `z.ai` et `bigmodel.cn`
`vertex`	Catalogue Google Vertex AI, usage de tokens par modèle (Cloud Monitoring), coût facturé opt-in (export de facturation) et posture de sûreté Model Armor opt-in	Surface Google enterprise que le chemin AI Studio ne couvre pas ; GCP n’a pas d’API de coût en temps réel
`azure-openai`	Déploiements + modèles Azure OpenAI / AI Foundry (ARM), usage des tokens Azure Monitor et surfaces de coût	Client du management plane en lecture seule ; aucun payload du data plane
`openrouter`	Catalogue OpenRouter en direct (prix USD/MTok), posture d’usage/limite du compte et drift de politique des modèles approuvés	Coût facturé via le `MeterCall` exporté ; no-op hors ligne
`cohere`	Catalogue de modèles Cohere en direct (Models API paginée par curseur)	Aucune API publique d’usage/facturation/org (dashboard uniquement) — réserve de couverture honnête ; coût mesuré autour de l’inférence à partir du prix catalogue
`fal`	Inventaire du cycle de vie des clés API fal.ai + posture de rotation ; coût mesuré autour de l’API de file d’attente	Aucune API publique d’usage/audit — gouvernance par le cycle de vie des clés ; les surfaces profondes sont soumises à la vente et marquées UNVERIFIED

Inférence auto-hébergée — catalogues et usage locaux

L’inférence auto-hébergée est toujours dans le périmètre ; c’est donc une source de première classe plutôt qu’une réflexion tardive du gateway. Ce niveau observe ce qu’un runtime local sert réellement.

Kind	Observe	Couverture honnête
`local`	Catalogue de modèles Ollama (`/api/tags`), résidence Ollama (`/api/ps`) — modèles chargés à cet instant, répartition GPU/CPU et échéance de déchargement — et usage de tokens vLLM sur sa surface compatible OpenAI	La résidence est signalée comme posture, et sa gravité est le PLACEMENT : un modèle entièrement en VRAM est informatif, tandis qu’un modèle résidant sur CPU ou RÉPARTI entre CPU et GPU est signalé, car c’est le cas où l’opérateur paie de la latence sans en être informé. Ollama ne publie aucune métrique agrégée de tokens, donc n’apporte aucune mesure. Cette source ne fournit toujours ni identité ni politique par appel sur l’inférence locale ; les gouverner exige le chemin gateway ou OTel. Ollama sur localhost ne requiert aucun credential : une config vide constitue donc un défaut fonctionnel en lecture seule ; désactiver un serveur exige une URL vide EXPLICITE, et les deux vides donnent un no-op

Backstop kernel — eBPF / Tetragon (signal clean, attribution approximate)

La moitié non coopérative du moat : là où le chemin coopératif voit ce qu’un agent rapporte, celui-ci voit ce que le noyau a fait — lectures/écritures de fichiers et connexions sortantes — même quand un agent désactive sa propre télémétrie. L’accès est une vérité-terrain noyau (un signal de niveau clean de ce qui s’est passé) ; l’attribution est délibérément honnête sur sa limite — le noyau attribue à une identité runtime (process/cgroup/conteneur), jamais à un agent résolu, si bien que chaque arête eBPF est approximate. Il ne déchiffre ni n’inspecte jamais les payloads (il est aveugle au corps TLS).

Kind	Observe	Limite honnête
`ebpf`	Events noyau Tetragon → R/RW de fichiers (masque `MAY_*`) et arêtes réseau ; finding anti-évasion optionnel quand un agent agit au niveau du noyau sans télémétrie coopérative	Anonyme côté agent → toujours `approximate` ; un backstop en flux, pas un ledger per-agent

Il ne charge pas lui-même de programmes eBPF : la capture noyau est faite par Tetragon (un DaemonSet séparé et durci). Voir Exigences de déploiement.

Lossy — les arêtes apparaissent, souvent approximate

Kind	Observe	Pourquoi lossy
`mongo-audit`	Audit MongoDB	Document-store ; la séparation des appelants est faible
`openlineage`	Events de run OpenLineage → lineage de datasets	Le lineage n’est pas un audit par appel
`delta-sharing`	Activité des destinataires Delta Sharing	Attribution destinataire-partagé

Sources approximate-by-attribution et côté permis

Celles-ci émettent soit le côté permis (grants déclarés), soit des accès attribués à un rôle / processus / credential partagée plutôt qu’à un agent résolu.

Kind	Observe	Niveau
`iceberg-catalog`	Catalogue REST Iceberg → grants permis + identités de credentials délivrées	permitted
`inference-gateway`	Routage K8s Gateway API Inference-Extension → routes d’inférence permises	permitted
`aws-kms` / `gcp-kms` / `azure-key-vault`	Audit cloud KMS → arêtes d’accès aux clés (jamais le matériel de clé)	approximate
`external-secrets` / `sops` / `kmip`	Manifests de gestion de secrets / locate KMIP → arêtes de provisioning/custody	approximate (existence, pas usage); `kmip`: Business
`istio-telemetry`	CRDs Istio Telemetry → arêtes de mesh L7	approximate (CRDs parsés, pas flux en direct)
`egress-proxy`	Journal de verdicts du proxy d’egress → arêtes d’egress L7	approximate
`kong-audit`	Journaux d’audit Kong → findings de changement de configuration	approximate
`ai-gateway`	Enregistrements d’usage Envoy AI Gateway → échantillons de coût (FinOps)	flux de coût
`git`	Liaison de publication Git simple : ligne du roster autorisant un remote Git SSH ou HTTPS pour les push gitpublish	N’observe rien ; push uniquement (un remote simple n’a pas d’API pull request ou merge)
`github`	Dépôts GitHub comme sources de données d’agents → arêtes d’accès R/RW observées (webhook d’abord, réconciliation par polling API) + arêtes ACL permises	observé + permis ; streaming (`poll_seconds: 0`)
`gitlab`	Dépôts GitLab → arêtes d’accès R/RW observées + arêtes ACL permises	observé + permis ; streaming (`poll_seconds: 0`)

Observateurs de posture — findings, pas arêtes d’accès

Des observateurs read-first qui font remonter la posture (sync/santé/drift, anomalies d’auth) sous forme de findings ; ils ne mutent jamais l’estate.

Kind	Observe
`runtime`	Où s’exécutent les charges AI (Linux procfs, daemon Docker, API Kubernetes) → arêtes de containment + findings de santé (nécessite un accès hôte — voir Exigences de déploiement)
`argocd` / `flux` / `crossplane`	CRDs GitOps / control plane → posture de sync, santé, drift, composition
`kerberos`	Télémétrie d’auth KDC → findings de Kerberoasting
`aaa`	Observations AAA RADIUS / TACACS+
`ssf`	Récepteur Shared-Signals / CAEP (kill-switch d’agent)
`edugain` / `openidfed`	Agrégat de fédération / chaînes de confiance OpenID-Federation → posture de fédération
`managed-settings`	Politique Claude `managed-settings` → arêtes permises + findings de drift
`envoy-ai-gateway`	Export de configuration déclarée Envoy AI Gateway → posture gateway + drift de politique gateway-vs-Olivares (le pendant de configuration du flux d’usage `ai-gateway`)
`kong-agent-gateway`	Export de configuration déclarée Kong agent-gateway → posture + drift de politique
`litellm`	Export de configuration déclarée du proxy LiteLLM → posture + drift de politique
`bedrock-kb`	Santé/configuration de récupération Amazon Bedrock Knowledge Bases (health-check Retrieve d’Agent Runtime) → findings de posture par KB + arêtes KB→source de données. Jamais `RetrieveAndGenerate` (aucune inférence facturable), jamais le contenu complet d’un document
`tak`	Posture du `CoreConfig.xml` TAK Server (+ sonde mTLS facultative) et ingest Cursor-on-Target gouverné et minimal-data (positions condensées, uid haché)
`a2a`	Pairs Agent2Agent (A2A) v1.0 → découverte d’Agent Card + vérification de signature JWS/JCS (niveau de confiance du pair) et interactions tâche/message observées comme arêtes agent↔agent. Observation uniquement — ne distribue jamais une tâche ; l’émission de cards signées est une capacité distincte

Untrusted hint — introspection MCP

La source mcp introspecte les serveurs MCP (stdio + Streamable HTTP) et émet des arêtes de capacité portant les hints R/RW déclarés par le serveur, plus des findings de révision de protocole, de surface de fonctionnalités et de provenance de registry. Selon la spécification MCP, une annotation d’outil est une déclaration non fiable — une revendication de capacité, corroborée contre une source observée, jamais accordée seule. (La source coopérative claude introspecte aussi MCP dans le cadre de son chemin OTLP ; mcp est l’introspecteur autonome que vous pointez vers une liste de serveurs ou un .mcp.json.)

Kind	Observe	Niveau
`mcp`	Outils/ressources/prompts de serveurs MCP → arêtes de capacité déclarée + findings de posture	untrusted hint

Observateurs de brokers et meshes hors processus

Ceux-ci portent des arbres de dépendances de protocole de transport lourds, chacun s’exécute donc hors processus (la dépendance ne s’édite jamais dans le cœur). Un connecteur atteint de nombreuses cibles.

Kind	Observe
`kafka`	Activité de topics Kafka / Event Hubs / Redpanda / MSK
`amqp`	Brokers AMQP (RabbitMQ, Azure Service Bus)
`nats` / `mqtt` / `cloudqueue`	Activité NATS, MQTT, cloud queue
`debezium`	Flux de change-data-capture Debezium
`envoy`	Services d’observation Envoy ALS / ext_authz / ext_proc
`hubble`	Données de flux Cilium Hubble

Fournisseurs de roster d’identités

Ceux-ci peuplent le roster d’identités non-humaines qui affine l’attribution (transformant les arêtes approximate en attributed). Chaque source avec une surface de grant émet aussi ses arêtes d’accès permis (SignalPolicy) depuis Gather — le côté PERMITTED du diff permitted-vs-observed :

Kind	Roster	Arêtes permises
`vault`	entités, groupes, politiques	grants de chemin par politique ACL (`vault.path`), étendus par entité liée
`ldap`	utilisateurs, comptes service/computer, groupes	appartenance à un groupe privilégié → grants d’annuaire (`ldap.directory`)
`idp` (Okta / Entra)	utilisateurs, apps/service principals, groupes	grants d’app-assignment / scope (`okta.app` / `entra.app`)
`infisical`	identités machine, membres d’org, projets	grants de projet (`infisical.project`)
`keycloak`	realms, clients, rôles, groupes, utilisateurs	roster uniquement (`Gather` no-op)
`pingone` / `forgerock`	Rosters d’annuaire PingOne / ForgeRock via le même lecteur multi-provider (le kind initialise le `provider` correspondant ; `ping` est un alias de `pingone`)	roster uniquement (`Gather` no-op)
`spiffe`	entrées d’enregistrement SPIRE	roster uniquement (`Gather` no-op)

Câblez as_source: true sur l’entrée identity pour une passe unique de grants permis par boot, ou une entrée sources séparée avec poll_seconds pour des re-scans périodiques. Chaque entrée s’enregistre sous son propre name, donc plusieurs entrées d’un même kind coexistent : okta et entra sont servis par le seul connecteur idp et restent deux sources distinctes, chacune avec sa configuration, son état et son cycle de vie. Ce qui doit être unique, c’est le nom, pas le connecteur. Les appartenances aux groupes/rôles ne voyagent que dans le snapshot typé du roster, jamais sous forme d’arêtes.

Fédération d’identité d’agents

Les registries d’agents des hyperscalers fédèrent en lecture seule contre le roster SPIFFE/WIF du plane. Leurs lignes per-agent (kinds agent_identity / workload_identity) sont des identités dédiées, non partagées, si bien que l’access map les traite comme une attribution per-agent ferme ; les lignes annexes des mêmes sources (principals de blueprint, fournisseurs de credentials, agents adossés à un service account) restent approximate. La fédération n’écrit jamais dans un registry ; l’export vers les control towers est une capacité distincte et ultérieure.

Kind	Fédère	Gather
`entra-agent`	Microsoft Entra Agent ID (identités d’agent, utilisateurs d’agent, blueprints, principals de blueprint, owners/sponsors, calcul des orphelins in-snapshot, soft-deleted opt-in) via Graph v1.0	findings de drift `nhi_longlived_credential`, findings de posture CA/agent risqué/gouvernance/sans sponsor et arêtes d’accès d’agents observées via `auditLogs/signIns` bêta opt-in — ajoutez une entrée `sources` avec `poll_seconds`
`agentcore`	AWS Bedrock AgentCore Identity (workload identities, fournisseurs de credentials token-vault) + moteurs AgentCore Policy/politiques Cedar comme collections	findings de drift `nhi_longlived_credential` (fournisseurs d’API-key statiques) — ajoutez une entrée `sources` avec `poll_seconds`
`google-agent`	Google Agent Identity (reasoning engines Agent Runtime ; identités d’agent basées sur SPIFFE), plus posture Agent Registry / Agent Gateway. Les lignes utilisent l’ID SPIFFE complet comme ref, convergeant avec le roster `spiffe` ; Gather détecte les agents de registry non attribués, les reasoning engines fantômes hors d’un registry lisible, les annotations risquées d’outils MCP et la posture du registry gateway	findings de posture registry/gateway et détection d’agents fantômes — ajoutez une entrée `sources` avec `poll_seconds`
`agent365`	Registry Microsoft Agent 365 (inventaire au niveau package, agents sans identité Entra inclus) via Graph v1.0, client credentials avec permissions d’application ou jeton délégué, détails de package opt-in	findings d’hygiène du registry (packages déployés bloqués ; packages externes/partagés déployés à tous les utilisateurs) — ajoutez une entrée `sources` avec `poll_seconds`
`foundry-agents`	Projets Microsoft Foundry, applications/déploiements d’agents et agents Agent Service actuels via ARM + Foundry Agent Service v1 ; corrèle les liens d’identité d’app avec `entra-agent`	findings de posture applicative dérivés d’ARM (identité d’agent Entra manquante ; déploiement en échec sur une app activée) — ajoutez une entrée `sources` avec `poll_seconds`
`ai-control-tower`	Inventaire d’actifs numériques ServiceNow AI Control Tower (Table API, lecture seule)	no-op (roster uniquement)
`oasf`	Descripteurs d’agent AGNTCY/OASF + vérification Agent Badge — EXPÉRIMENTAL jusqu’à ce que la spec d’identité soit conforme VCDM 2.0	findings de badge — ajoutez une entrée `sources` avec `poll_seconds`
`onepassword`	Compte 1Password comme custodian `secret_store`	arêtes d’accès-secret item-usage — ajoutez une entrée `sources` avec `poll_seconds`

Pour les sept kinds dotés d’un Gather re-pollable (entra-agent, agent365, agentcore, foundry-agents, google-agent, oasf, onepassword), câblez la moitié roster comme une entrée identity sans as_source et la moitié arêtes/findings comme une entrée sources séparée avec poll_seconds — pas les deux via as_source: true, qui n’exécute le scan qu’une seule fois par boot. (Deux entrées d’un même kind ne sont plus l’obstacle : chacune s’enregistre sous son propre name. La raison est la cadence — une passe par boot n’est pas un re-scan.)

Les owner/sponsor déclarés par le registry atterrissent sur les enregistrements de cycle de vie NHI pendant le sync du roster (la même sémantique que PUT /nhi/{ref}/ownership), et un orphelin asserté par le registry (un agent Entra dont le blueprint a disparu) atterrit sur le flag registry_orphaned du même enregistrement — le balayage de cycle de vie l’OR-e dans orphaned et émet le finding nhi_orphaned, si bien que la détection d’orphelins surveille les agents fédérés sans aucun câblage supplémentaire. La source vault-audit (sous sources, pas identity) suit le device d’audit fichier de Vault et émet la contrepartie OBSERVED des grants permis de vault pour les mêmes refs entity:<name>.

Sources de documents de connaissance (pas de couverture d’access-map)

Celles-ci alimentent le module knowledge (module VIII), pas l’access map : elles ingèrent du contenu de document pour une récupération gouvernée, n’émettent aucune arête R/RW et ne produisent aucune observation sur le bus. Le module les tire (List → Fetch) sur une requête d’ingest (POST /v1/m/knowledge/kbs/{id}/ingest {"source":"<name>"}), elles sont donc câblées dans ce module — nommez-les sous documents dans OLIVARES_SOURCES_CONFIG, pas sources. Chacune est en lecture seule et minimal-data : elle porte l’ACL et la provenance de la source (jamais un email personnel ; le module expurge le corps avant de persister).

Kind	Ingère
`gdrive`	Documents Google Drive (Docs/Sheets/Slides/fichiers)
`confluence`	Espaces et pages Atlassian Confluence
`notion`	Workspaces, bases de données et pages Notion
`sharepoint`	Sites et documents Microsoft SharePoint / OneDrive (Business)
`s3content`	Contenu d’object-storage (objets S3 / R2 / GCS)
`sap_odata`	Entités de service SAP OData sous forme de documents gouvernés (Business)
`salesforce`	Objets/enregistrements Salesforce sous forme de documents gouvernés (Business)
`snowflake`	Tables/lignes Snowflake sous forme de documents gouvernés (distinct de l’observateur R/RW `snowflake-audit`)
`azure_ai_search`	Documents d’index Azure AI Search
`postgres`	Lignes PostgreSQL sous forme de documents gouvernés — lecture seule par construction, ACL déclarée par ligne, classification par colonne (distinct de l’observateur R/RW `pgaudit` ; pas de NL-to-SQL). Voir Postgres comme source de contexte gouvernée.
`filesystem`	Contenu de serveur de fichiers (local / NFS / SMB) — lecture confinée à la racine par construction, propriétaire/groupe/ACL POSIX transposés vers les ACL de documents, classification xattr (distinct du sink de logs `filelog`). Voir Gouverner votre serveur de fichiers.

// OLIVARES_SOURCES_CONFIG — document sources live under "documents", never "sources"
{
  "documents": [
    { "name": "eng-wiki", "kind": "confluence",
      "config": { "export_path": "/var/lib/olivares/confluence" } }
  ]
}

Destinations de sortie (pas de couverture)

Les connecteurs de sortie livrent findings et notifications ; ils n’observent rien et n’ont pas de niveau de couverture. Ils sont câblés séparément des sources.

Kinds de destination in-process : 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) (le sink WORM S3 Object Lock — un objet immuable dont le verrou est vérifié par notification) et teamsbot (Business: Regulated Operations, le connecteur Teams à bot enregistré de la boucle d’incident ; un binaire Community ignore une destination de ce type avec une ligne de journal qui nomme Business).

Trois kinds d’egress vers des brokers s’exécutent hors processus sous forme de plugins embarqués (leurs arbres de dépendances de protocole wire ne se lient jamais au moteur, exactement comme les sources plugin) : kafka, amqp et cloudqueue — les mêmes noms de kind que leurs jumeaux sources ; comme destination, chacun livre la notification sous forme de CloudEvent au broker/à la file configuré. Un simple build de développement sans task build:connectors ignore une telle destination avec un avertissement honnête au boot, au lieu de prétendre qu’elle existe.

Exigences de déploiement et attribution honnête

Les connecteurs différentiels R/RW sont câblés dans le binaire par défaut, mais deux comportent une exigence de déploiement que les autres n’ont pas — le code du connecteur est agnostique vis-à-vis de l’hôte, les données qu’il consomme ne le sont pas :

ebpf consomme l’export d’events noyau de Tetragon. Le connecteur n’a besoin d’aucune capacité noyau — il lit un fichier/FIFO/stdin en 0600 que Tetragon possède (events_path, par défaut -). Tetragon lui-même est un DaemonSet séparé et durci détenant les CAP_BPF + CAP_PERFMON minimaux, s’exécutant non-root avec seccomp/AppArmor et sans listener entrant. Le déploiement est donc : exécuter Tetragon en privilégié (ses TracingPolicies file-access + TCP-connect intégrées), puis pointer ebpf vers son export. Tetragon minimum : v1.0.
runtime lit le procfs de l’hôte (proc_root, par défaut /proc), le socket du daemon Docker (docker_socket, off par défaut — l’accès en lecture à docker.sock est root-équivalent ; opt-in délibéré, idéalement via un socket proxy en allowlist GET) et/ou l’API Kubernetes (ServiceAccount in-cluster par défaut). Ne montez que ce que vous activez.
gcp-audit s’authentifie comme un service account GCP (key JSON ou un access_token émis par WIF/ADC) et n’a besoin que de rôles de management en lecture seule : roles/resourcemanager.organizationViewer + roles/iam.serviceAccountViewer + roles/logging.viewer — lire les entrées Data Access nécessite en plus roles/logging.privateLogViewer. Scopez organization_id (parcours d’org + audit org-scopé) et/ou projects. Les Data Access audit logs sont off par défaut dans GCP : activez-les via la config IAM/data-access, sinon le flux d’activité sous-rapporte honnêtement.
azure-activity s’authentifie comme un service principal Entra (client-credentials) ou un access_token managed-identity, et n’a besoin que du rôle Reader à la racine du tenant (ou par subscription) — ce seul rôle couvre Resource Graph, le listing des subscriptions et l’Activity Log. Les subscriptions sont auto-listées quand subscriptions n’est pas défini.

Les deux s’exécutent quand même in-process (transport A) ; les binaires go-plugin cmd/{pg-audit,s3-cloudtrail,ebpf-source} existent pour un déploiement collector hors processus près de l’hôte si vous préférez les isoler là.

Chaque source est opt-in, deny-closed : un log_path/path/events_path manquant est une erreur de configuration au démarrage (la source n’est pas câblée), jamais un no-op silencieux. L’estate de démo (quickstart) ensemence des observations synthétiques équivalentes à travers le vrai bus afin que vous puissiez voir le signal de niveau clean de bout en bout avant de câbler une source réelle.

Voir aussi

Connecter une source — le modèle de connecteur et comment en câbler un.
Connecter Claude Code — le chemin coopératif de bout en bout.
Module III — l’access map — ce que deviennent les arêtes.
Honnêteté & limites — le contrat d’honnêteté à l’échelle du produit.