连接器目录与覆盖层级
本页是第一方连接器的目录，并为每个连接器列出它所能诚实支持的覆盖层级。它是 connect a source 的配套页面，后者解释连接器模型 （observe-only、minimal-data、三种观测类型）——请先阅读那篇。本页回答下一个问题： 存在哪些 source，每一个的信号有多好？
覆盖层级取决于一个系统的审计面能够诚实告诉你什么，绝不取决于我们希望它能告诉我们什么。 贯穿全部文档所使用的层级如下：
- Cooperative（协作式）——报告自身行为的 agent 或平台（OpenTelemetry、厂商 admin API）。 存在时保真度最高；依赖 source 的协作。
- Clean（干净）——原生区分读与写的存储，逐字取自其自身的审计轨迹（SQL audit、 对象存储 / 数仓的数据访问日志）。
- Lossy（有损）——其审计无法干净区分读写、或无法区分调用方与调用方的存储（文档存储、
lineage）。edge 仍会落地，但往往是
approximate。 - Impossible passively（被动不可行）——没有可用被动审计面的系统（内存缓存、嵌入式单文件 数据库）。不存在诚实的读优先信号；本产品也不假装如此。
- Approximate-by-attribution（按归因近似）——访问真实存在，但归因落到某个角色、进程或共享
凭据，而非一个已解析的 agent，因此该 edge 为
approximate。 - Untrusted hint（不可信提示）——一项声明的能力（一个 MCP 工具标注），需经佐证，绝不单独信任。
各种类的进程模式
Section titled “各种类的进程模式”每种类型只使用一种进程模式，由引擎固定：
- 进程外插件。 引擎将连接器嵌入为独立程序，以受限子进程启动（限定作用域的环境；主机允许时使用专用用户和 cgroup），通过带 AutoMTLS 的 gRPC 通信。依赖树不链接进引擎。源类型：
claude、cowork、kafka、amqp、nats、mqtt、cloudqueue、debezium、envoy、hubble。目的地类型：kafka、amqp、cloudqueue。未执行task build:connectors的构建不嵌入这些程序，并在启动时为每个已配置项告警。 - 进程内。 本页其余所有类型。连接器链接到引擎二进制中，在引擎进程内运行；panic 被隔离，源被标记为
failed。 - 外部插件。 通过
plugin（二进制路径、固定摘要、针对connector_trust验证的签名）配置的源或目的地始终以相同的受限方式在进程外运行。仓库中进程内类型的connectors/<kind>/cmd/程序不随发行版提供；构建它并以此方式准入（运维插件），即可让连接器独立运行。
源插件进程退出时，引擎重新启动同一二进制，再次检查外部插件的固定摘要，使用源设置重新打开并恢复采集。首次重启等待约一秒，之后每次翻倍，最多五分钟；插件运行五分钟后回到一秒。从发现进程退出到新进程启动期间，源报告 failed；重启尝试失败时显示重启错误。
目的地插件在投递失败且发现进程已退出时，以相同方式重启：引擎重新启动二进制（外部插件再次检查固定摘要），并使用目的地设置打开。发现插件已退出的那次投递仍报告失败；重启被拒绝时附带重启错误。通知重试阶梯会重试并抵达新进程。首次立即重启；之后从一秒开始翻倍，最多五分钟，距最后尝试超过五分钟后重新开始。未收到投递的目的地会等到下一次投递才重启。
重启的插件以最初打开连接器时的设置打开，因此修改或轮换后的密钥在配置重载或引擎重启时才传入，与未退出的插件相同。
进程仍存活但采集或投递失败的插件不会重启：该故障属于连接器自身。
Cooperative —— Claude 与厂商遥测
Section titled “Cooperative —— Claude 与厂商遥测”存在时保真度最高的 source。Claude Code 运行时 source 作为内嵌插件在进程外运行 （普通的 dev 构建会省略它，引导日志会诚实地告警，而不是表现得健康）。
| Kind | 观测内容 | 备注 |
|---|---|---|
claude |
Claude Code OTLP 工具遥测 + MCP 自省 → edges / cost / findings | 进程外插件；存在每个 agent 身份时为 attributed，否则为 approximate |
claude-api |
Claude Admin-API 成本采样 + 治理态势 findings | 进程内；离线（无 admin key）时为空操作 |
claude-compliance |
Claude Compliance 活动流证据 → findings | 构造上仅 GET；离线时为空操作 (Business) |
claude-config |
静态 Claude config 树（subagents / Skills / plugins）→ 声明能力 edges | 仅元数据——一个能力面，而非已观测的访问 |
claude-console |
Claude 组织 IAM → SSO/SCIM 态势 findings（身份名册 + source） | Business: Identity & Scale; |
claude-wif |
Anthropic 非人类身份 / 工作负载身份名册 + 允许范围 edges | Business: Identity & Scale; 建模运营方声明的 federation；标记静态 key 隐患 |
claude-managed-agents |
Claude managed-agents 清单 + thread event（webhook receiver + GET poller） | 流式 source（poll_seconds: 0）；离线时为空操作 |
claude-projects |
Claude Organization Projects 清单（membership / API key）+ 运维方声明的 project policy | Admin API 只读；离线时为空操作 |
claude-apps-gateway |
Claude apps-gateway 态势、声明的 model grant 与审计事件 ingest → topology + finding | 读取既有 gateway.yaml 与可选 JSONL 审计导出 |
claude-batch |
Anthropic Message Batches + Files API 清单、batch policy 执行、upload retention expiry | 绝不读取 payload 或文件内容；无 admin key 时给出诚实的 offline finding |
claude-routines |
Claude Code Routines（scheduled trigger）清单 → edge + cadence/review finding | 仅 GET；prompt 内容只做哈希；流式（poll_seconds: 0） |
cowork |
Claude Cowork OTLP/HTTP 日志 receiver → activity evidence | 进程外插件（隔离 OTel-proto 依赖） |
cowork-analytics |
Claude Cowork engagement analytics | 进程内（仅 modelprovider client） |
codex |
OpenAI Codex 成本样本、usage/auth/admin-audit 证据、adoption finding | Admin API 只读；销售门控表面降级为态势 finding |
cursor |
Cursor Admin API 计费成本、team audit log、member inventory、budget posture | 套餐门控的 403/404 降级为 finding，绝不导致失败 |
厂商无关的 GenAI 框架 profile（gen_ai.*）—— 选择性启用
Section titled “厂商无关的 GenAI 框架 profile（gen_ai.*）—— 选择性启用”本目录承诺的 agent 框架——LangGraph / LangChain、CrewAI、AutoGen / Microsoft Agent
Framework、Google ADK（以及 OpenAI SDK、LlamaIndex、Pydantic-AI、Strands……）——不
发出 Claude 的 claude_code.* schema。它们汇聚到
OpenTelemetry GenAI 语义约定
（gen_ai.*）。同一个 claude source 也会摄取该 profile，因此一支经 OTel 插桩的舰队可以通过
单次摄取喂给 access map 与 FinOps，而无需为每个框架定制连接器——这是杠杆率最高的集成。
**该 profile 为选择性启用，并被诚实标记为实验性。**整个 gen_ai 领域处于 OpenTelemetry
Development 状态（非 Stable，2026 年 6 月），因此它只有在你按规范自身的门控镜像启用时才激活。
将连接器的 semconv_opt_in 设为一个包含 token gen_ai_latest_experimental 的逗号分隔列表
（镜像 OTEL_SEMCONV_STABILITY_OPT_IN）。默认关闭时，gen_ai.* 信号仍会喂给静默看门狗，但
不映射任何 edge/cost——我们绝不声称约定本身并不具备的稳定性。
由于这些约定正处于变动期，本摄取是双名的（它同时读取当前 key 与仍在野外发出的已弃用前身）
且多信号的（它映射 trace span、gen_ai.client.inference.operation.details 日志
事件，并识别客户端 metrics）：
| 它读取什么 | 当前 key | 同时接受（已弃用，仍由其发出） |
|---|---|---|
| Provider | gen_ai.provider.name |
gen_ai.system（v1.36.0 及更早的默认值；Google ADK，例如 gcp.gemini） |
| 输入 token | gen_ai.usage.input_tokens |
gen_ai.usage.prompt_tokens（OpenLLMetry/Traceloop → LangChain/LangGraph/CrewAI） |
| 输出 token | gen_ai.usage.output_tokens |
gen_ai.usage.completion_tokens（同上） |
| gen_ai 属性 | 映射到 | 置信度 |
|---|---|---|
gen_ai.usage.*（tokens） |
CostSample（来源为 estimated——token 而非已计费成本） |
— |
gen_ai.provider.name / request.model / response.model |
成本 provider + model（优先 response） | — |
gen_ai.operation.name = execute_tool + gen_ai.tool.name |
agent→tool 访问 edge（mode 为 unknown） |
attributed |
gen_ai.conversation.id + gen_ai.agent.{name,id} |
conversation→agent 归因 edge + session ref | attributed |
支持的方言矩阵（多代规整器）
Section titled “支持的方言矩阵（多代规整器）”GenAI 约定经历了三代共存于真实 2026 年舰队中的演变。本摄取从各代特有的标记中逐信号
检测代际，并用对应的 semconv 锁定值给规整后的事件打戳（genai.semconv 态势 finding 记录每次
运行的活动集合；每次运行会有一条 info 级 drift finding 标记所见的每个已弃用方言，让你
知道哪些舰队需要升级插桩）。任何一代都绝不读取消息内容——内容 key 仅作为方言标记
（minimal-data 态势）。
| 检测到的方言 | 打上的锁定值 | 独占标记（已验证） | 发出方（已验证 2026 年 6 月） |
|---|---|---|---|
| 旧版 OpenLLMetry/Traceloop（semconv 之前） | openllmetry |
索引化 gen_ai.prompt.{i}.* / gen_ai.completion.{i}.*、gen_ai.usage.prompt_tokens/completion_tokens、llm.usage.total_tokens、llm.request.type、llm.vendor、traceloop.span.kind |
经 Traceloop 插桩、锁定 < openllmetry v0.55.0（发布于 2026-03-29）的 LangChain / LangGraph / CrewAI。首字母大写的 provider（OpenAI、Langchain）会被转为小写，使 FinOps 不会因大小写而拆分 |
| v1.36 及更早事件（规范自身的命名） | 1.36.0 |
gen_ai.system；五个 per-message 日志事件 gen_ai.{system,user,assistant,tool}.message、gen_ai.choice（按名识别——其唯一属性是可选的） |
Google ADK LLM span（gcp.vertex.agent）、AutoGen（autogen）、Microsoft Agent Framework——它们仍全部发出 gen_ai.system |
| v1.37+ messages（当前） | 1.41.1 |
gen_ai.provider.name、gen_ai.input.messages / gen_ai.output.messages / gen_ai.system_instructions、gen_ai.client.inference.operation.details 事件、gen_ai.workflow.name |
OTel 官方插桩；openllmetry ≥ v0.55.0 |
一个仅携带跨代名称完全相同的 key 的信号（例如一个 ADK invoke_agent span：operation + agent +
conversation，完全没有 provider key）会在当前锁定值下规整——所应用的映射逐字节相同，且生产者的
真实版本无法从传输协议得知。
MCP 约定（mcp.*，semconv v1.39 —— Development）
Section titled “MCP 约定（mcp.*，semconv v1.39 —— Development）”上游恰好存在四个 mcp.* 属性（mcp.method.name、mcp.protocol.version、mcp.resource.uri、
mcp.session.id）；tool 搭载于 gen_ai.tool.name，prompt 搭载于 gen_ai.prompt.name。本摄取
通过复用 Claude 路径所发出的相同 resource kind，将这些 trace 与产品自身的 MCP 治理事实连接起来：
| MCP 信号 | 映射到 |
|---|---|
任意带 server.address 的客户端侧 mcp.* span |
session→mcp.server edge（与 claude_code.mcp_server_connection 的 edge 连接） |
tools/call + gen_ai.tool.name |
mcp.tool 访问 edge（端点已知时为 server.address/tool）——与 Claude 的 mcp__server__tool 调用同一 kind |
resources/read / resources/subscribe + mcp.resource.uri |
read 模式 mcp.resource edge（URI 已脱敏：凭据/查询被剥离） |
prompts/get + gen_ai.prompt.name |
read 模式 mcp.prompt edge（prompt 面） |
| SERVER 类 span / `mcp.client | server.*.duration` metrics |
Agent span（invoke_agent client/internal 拆分 + invoke_workflow，semconv v1.41 —— Development）
Section titled “Agent span（invoke_agent client/internal 拆分 + invoke_workflow，semconv v1.41 —— Development）”v1.41.0 将 invoke_agent 拆分为 CLIENT 变体（远端 agent 服务）与 INTERNAL 变体（进程内）。
真实框架今天违反该 kind（AutoGen 与 Microsoft Agent Framework 对进程内 agent 硬编码 CLIENT；
Google ADK 使用 INTERNAL），因此本摄取仅当一个 span 为 CLIENT 且携带 server.address 时才
将一次调用分类为远端——这会产生一条 conversation→genai.agent.remote 委派 edge。其余一切
均保持为由 conversation→genai.agent 归因 edge 所覆盖的进程内调用：干净降级，绝不编造
“remote”。invoke_workflow（v1.41 新增；CrewAI 式 crew）映射一条 conversation→genai.workflow
edge。Agent span 在上游仍为 Development（实验性）——不声称任何稳定性。
稳定 vs 实验，诚实地说：机制（选择性启用门控、方言检测 + 双名读取、span/event/metric
映射、已封存的 CostSample/EdgeObservation 形状）在本产品中是稳定的。它所映射的词汇表
（gen_ai.*/mcp.* key、operation 枚举）在上游为 Development，可能再次重命名；这正是本摄取
规整每一代而非锁定某一代的原因。v1.41.1 是 gen-ai 约定最后一个带版本号的发布（它们迁移到了
open-telemetry/semantic-conventions-genai，截至 2026 年 6 月该仓库无任何发布）。注意：
- **成本按 W3C span id 去重。**当一次 operation 在其 span 与其
operation.details事件上 （它们共享一个 span id）同时报告用量时，只计一次成本，而非两次。 - Metrics 喂存活性，绝不喂成本。
gen_ai.client.token.usage是聚合值；span/event 才是每次 operation 的权威用量，因此对 metric 也计费会重复计数。v1.39 的mcp.*时长直方图以相同方式识别。 - **Provider 可能为
unknown。**若某个 span 携带 model 但无 provider/system，成本归因到unknown，而非从 model id 猜测。 - **仅有总量的 token 计数不拆分。**没有 prompt/completion 拆分的旧版
llm.usage.total_tokens绝不被猜测为输入/输出（不编造成本）。 - OpenInference（Arize/Phoenix）是另一套约定，本 profile 不摄取它——此处读取的
llm.*key （llm.request.type、llm.usage.total_tokens、llm.vendor）是 OpenLLMetry 旧版标记， 而非 OpenInference 的llm.*命名空间。
Cooperative——本地 agent-surface 配置
Section titled “Cooperative——本地 agent-surface 配置”这些 source 读取本地 agent 声明的配置，并发出 permitted edge 与 posture finding。
它们不是实时执行 trace；框架若有原生 OTEL，实时使用仍经由上文的 gen_ai.* ingest。
| Kind | 观测内容 | 诚实覆盖 |
|---|---|---|
opencode |
本地 opencode.json / opencode.jsonc JSONC 层 → permission、managed/admin-override posture，MCP/tool/custom-agent permitted edge，credential-in-config/share/autoupdate/OTEL finding，以及 authoring fragment |
仅配置声明。managed 层可在本地检测，但并非 immutable lock：runtime OPENCODE_PERMISSION、test-dir 重定向和远程组织配置均不在此 reader 范围内。原生 OTEL 启用后可通过 out-of-band OTEL_* exporter 提供实时 gen_ai.* 使用 |
gemini-cli |
Gemini CLI settings.json 层（system/user/workspace）→ permitted MCP/tool edge、enforcement-gap posture、effective-config inventory |
仅配置声明；实时使用经由 gen_ai.* ingest（CLI 原生发出）。不是 Gemini API（后者为 hosted-provider 表面） |
openhands |
OpenHands config.toml + env → sandbox/model-pinning/credential/telemetry posture、permitted MCP/action edge |
仅配置声明；实时使用经原生 OTEL gen_ai.* |
goose |
Goose（Block）profiles.yaml + env → admin-settings/model-pinning/extension/tool-approval posture、permitted extension edge |
仅配置声明 |
cline |
Cline / Kilo Code VSCode settings.json namespace → auto-approve/MCP-allowlist/credential/model-pinning posture |
仅配置声明；upstream 无原生 OTEL |
grok |
Grok Build（xAI）终端编码 agent：本地配置、hook 接线、具有已记录否决支持的事件，以及声明的治理姿态 | 配置声明的 agent 姿态。xai API 连接器读取模型目录和成本，其中 grok-build-0.1 是一个模型；此连接器读取 agent。实时观测使用 Grok Build 发出的 OTLP ingest。PostureEnforced 仅适用于唯一具有已记录否决支持的事件 PreToolUse；其他事件是 observed |
openclaw |
OpenClaw openclaw.json（JSON5 discovery、受限 $include）→ 每 agent 的 gateway/channel/tool/sandbox/skill/model posture，声明的 channel/skill/model edge |
仅配置声明；upstream 未验证 inline PEP hook |
hermes |
Hermes Agent config.yaml + profile tree + managed scope → terminal/channel/skill/security/model/MCP posture、声明的 edge |
仅配置声明；upstream 未验证 inline PEP hook 或原生 OTEL |
paperclip |
Paperclip REST API（board API 密钥，仅 GET）→ 公司作为组集合、agent 作为 NHI 名册行（paperclip/<adapterType>、role、title、reports_to），已结束日期的运行计数，以及参考成本样本（cost_type=paperclip） |
仅观测：不启动或限制 Paperclip 的 agent。Paperclip 没有原始成本事件列表，因此成本为日聚合；被拒绝的数据获取环节报告为覆盖度 finding |
google-adk |
导出的 Google ADK 2.0 Session JSON → agent/app 清单、sub-agent、tool function-call、transfer、approved-tool drift、Vertex reasoningEngine correlation | 只读导出；绝不读取消息内容。不同于 google-agent 平台表面 |
agents-md |
遍历 repo 中的 agent instruction 文件（AGENTS.md 与每 agent memory/instruction 文件）→ SHA-256 baseline drift + instruction-injection / hidden-Unicode / secret scan | minimal-data：净化后的 path + hashed detail，绝不读取内容 |
mcpb |
已安装 / 已分发的 .mcpb desktop extension → manifest posture scan、enterprise-allowlist drift、PKCS#7 signature verification |
extension 表面上的 PERMITTED-vs-OBSERVED |
codex-managed-config |
OpenAI Codex managed-config 文件 → enforcement posture + 与 authored baseline 的 drift | 仅观测：无法阻止 developer 绕过 managed 层（Codex 的 managed-settings 镜像） |
Clean —— 原生存储审计（逐字读/写）
Section titled “Clean —— 原生存储审计（逐字读/写）”这些 source 读取存储的自有审计轨迹，并逐字采用其读/写分类——绝不从查询文本推断。pgaudit
与 s3cloudtrail 是 access map 所围绕构建的规范 R/RW
source（它们带连字符的 pg-audit / s3-cloudtrail 别名也可解析）。
| Kind | 观测内容 |
|---|---|
pgaudit |
PostgreSQL pgAudit 轨迹（csvlog/jsonlog）→ R/RW 表访问，READ/WRITE 逐字取自 pgAudit 的 CLASS |
s3cloudtrail |
AWS CloudTrail S3 事件 → 对象 R/RW，读/写取自 CloudTrail 的 readOnly 标志（同时浮现 Claude-on-Bedrock 模型调用） |
snowflake-audit |
Snowflake 原生访问历史 |
databricks-uc |
Databricks Unity Catalog 审计 |
bigquery-audit |
BigQuery 数据访问审计 |
redshift-audit |
Amazon Redshift 审计 |
mssql-audit |
SQL Server 审计 |
oracle-audit |
Oracle 统一审计 (Business) |
gcs-audit |
Google Cloud Storage 数据访问审计 |
azure-blob-audit |
Azure Blob Storage 审计 |
云管理平面 —— org/tenant 清点 + 控制平面活动
Section titled “云管理平面 —— org/tenant 清点 + 控制平面活动”管理平面的三云对等——区别于上文存储审计连接器所覆盖的每个资源的数据平面。每一个都是
某云 org/tenant 控制平面的实时、只读 API 客户端：它发现资源的拓扑（清点 edge，
mode=unknown，attributed）并读取该云原生的审计流以获取控制平面活动
（identity→…api edges，已分类读/写）。它们补全了 AWS 已用 s3cloudtrail（数据平面）加上
账户级 IAM/CloudTrail aws 连接器所锚定的矩阵。两者均在进程内运行且离线安全
（无凭据 ⇒ Gather 为空操作）；两者都只观测控制平面——绝不观测任何 payload、secret、key 或
资源属性。
| Kind | 观测内容 | 诚实覆盖 |
|---|---|---|
gcp-audit |
GCP Resource Manager / IAM（org→folder→project→service-account 拓扑）+ Cloud Audit Logs（Admin Activity + Data Access）→ identity→gcp.api |
有日志处为 Clean：按日志类型定义 Admin Activity 为写，Data Access 由标准方法动词判定读/写。Data Access 日志被禁用处（GCP 默认关闭）或方法动词非标准处为 Lossy（unknown，绝不猜测）。声明的共享 principal 为 approximate；principalEmail 与 SPIFFE/SA 名册收敛 |
azure-activity |
Azure Resource Graph（tenant→subscription→resource 拓扑）+ Azure Monitor Activity Log（控制平面操作）→ identity→azure.api |
控制平面写/删为 Clean（逐字取自 RBAC action）。通用 action 后缀为 Lossy（unknown——可能读或写）。数据平面读不在 Activity Log 中（由 azure-blob-audit / azurekeyvault 数据平面覆盖）。共享调用方为 approximate；调用方 objectId/appId 与 Entra 名册收敛 |
cloudflare |
经 REST API v4 获取 Cloudflare edge estate——Worker、R2 bucket、Logpush job→ topology edge | 仅清单（本 connector 无 audit feed）；受限只读 token。不同于 cloudflare-ai-gateway / MCP portal AI 表面 |
GCP Data Access 的选择性启用与 Azure 读不入日志的缺口是本平面诚实的不透明 edge：
在那些日志关闭处，缺少一条活动 edge 并不能证明没有访问。完整的每云层级表见随附源码树中的
docs/contracts/S165-connectors-cloud-management.md。
托管模型提供商——目录、态势与计量
Section titled “托管模型提供商——目录、态势与计量”这些 source 治理托管模型提供商账户和目录。它们不代理 inference；当提供商没有可用 usage API 时，费用由 connector 在 inference path 周围的 Meter 估算，而不是从汇总 billing feed 拉取。
| Kind | 观测内容 | 诚实覆盖 |
|---|---|---|
openai |
OpenAI platform usage 与 cost（org API），以及 model 与 API-key catalog | 只读 org/admin key；无 data-plane payload。不同于 azure-openai，后者访问真实 Azure 表面而非 OpenAI-org path |
gemini |
Gemini（Google）hosted model catalog 与运维方接入的 usage export | hosted-provider 表面。不同于读取本地 CLI settings 的 gemini-cli 和覆盖 enterprise Vertex 表面的 vertex。Google 在此路径没有 aggregate usage API，因此 usage 仅为运维方所接入内容 |
deepseek |
DeepSeek hosted catalog、account balance availability、PRC sovereignty posture | 无 aggregate usage API；cost 从声明定价在 inference 周围计量 |
mistral |
Mistral catalog 与 governance posture | 无公开 usage/billing/spending-cap API；cost 从 list pricing 在 inference 周围计量 |
xai |
xAI/Grok live catalog、billing endpoint、key/ACL inventory、credit 与 spending-limit posture | cost 使用只读 management billing endpoint；management 与 inference credential 分离 |
glm |
Zhipu GLM / Z.ai 声明 catalog、USD list-pricing Meter、entitlement probe、sovereignty posture | 仅 catalog + Meter：GLM 没有已验证的 usage、billing、balance、admin、key 或 organization API。PRC nexus / Entity List 警示同时适用于 z.ai 与 bigmodel.cn 表面 |
vertex |
Google Vertex AI catalog、per-model token usage（Cloud Monitoring）、opt-in billed cost（billing export）、opt-in Model Armor safety posture | AI Studio path 不覆盖的 enterprise Google 表面；GCP 无实时 cost API |
azure-openai |
Azure OpenAI / AI Foundry deployment + model（ARM）、Azure Monitor token usage 与 cost 表面 | 只读 management-plane client；无 data-plane payload |
openrouter |
OpenRouter live catalog（USD/MTok pricing）、account usage/limit posture、approved-model policy drift | billed cost 经导出的 MeterCall；离线时为空操作 |
cohere |
Cohere live model catalog（cursor-paginated Models API） | 无公开 usage/billing/org API（仅 dashboard）——诚实 coverage caveat；cost 从 list pricing 在 inference 周围计量 |
fal |
fal.ai API-key lifecycle inventory + rotation posture；cost 在 queue API 周围计量 | 无公开 usage/audit API——按 key lifecycle 治理；深层表面受销售门控并标为 UNVERIFIED |
自托管 inference——本地 catalog 与 usage
Section titled “自托管 inference——本地 catalog 与 usage”自托管 inference 始终在范围内，因此它是一等 source，而非 gateway 的附带项。 此层观测本地 runtime 实际正在服务的内容。
| Kind | 观测内容 | 诚实覆盖 |
|---|---|---|
local |
Ollama model catalog（/api/tags）、Ollama residency（/api/ps）——当前已加载 model、GPU/CPU 分布与 unload deadline——以及经 OpenAI-compatible 表面的 vLLM token usage |
residency 作为 posture 上报，其 severity 即 PLACEMENT：完全位于 VRAM 的 model 为 informational；位于 CPU 或在 CPU/GPU 间 SPLIT 的 model 会被标记，因为 operator 会承受 latency 却未获告知。Ollama 无 aggregate token metric，因此不贡献 metering。本 source 仍不提供 local inference 的 per-call identity 或 policy；治理它们需要 gateway 或 OTel path。localhost 上的 Ollama 无需 credential，因此空 config 是可工作的只读默认值；禁用 server 需显式空 URL，两者均空则为空操作 |
内核后备 —— eBPF / Tetragon（信号干净，归因近似）
Section titled “内核后备 —— eBPF / Tetragon（信号干净，归因近似）”护城河中非协作的那一半：协作路径看到 agent 报告的内容，而此处看到内核实际做了什么
——文件读/写与出站连接——即便一个 agent 关闭了自身遥测。访问是内核的地面真相（关于
发生了什么的 clean 层级信号）；归因则刻意地诚实面对其极限——内核归因到一个运行时身份
（process/cgroup/container），绝不归因到已解析的 agent，因此每条 eBPF edge 都是 approximate。
它绝不解密或检查 payload（它对 TLS 主体视而不见）。
| Kind | 观测内容 | 诚实极限 |
|---|---|---|
ebpf |
Tetragon 内核事件 → 文件 R/RW（MAY_* 掩码）与网络 edge；当某 agent 在内核层行动却无协作遥测时，可选的反规避 finding |
agent 匿名 → 始终 approximate；一个流式后备，而非每个 agent 的台账 |
它不自行加载 eBPF 程序：内核捕获由 Tetragon （一个独立、加固的 DaemonSet）完成。见 部署要求。
Lossy —— edge 落地，但常为近似
Section titled “Lossy —— edge 落地，但常为近似”| Kind | 观测内容 | 为何有损 |
|---|---|---|
mongo-audit |
MongoDB 审计 | 文档存储；调用方区分弱 |
openlineage |
OpenLineage run 事件 → 数据集 lineage | lineage 不是每次调用的审计 |
delta-sharing |
Delta Sharing 接收方活动 | 共享接收方归因 |
按归因近似 & permitted 侧 source
Section titled “按归因近似 & permitted 侧 source”这些发出 permitted 侧（声明的 grant），或发出归因到角色 / 进程 / 共享凭据而非已解析 agent 的访问。
| Kind | 观测内容 | 层级 |
|---|---|---|
iceberg-catalog |
Iceberg REST catalog → permitted grant + 下发凭据身份 | permitted |
inference-gateway |
K8s Gateway API Inference-Extension 路由 → permitted 推理路由 | permitted |
aws-kms / gcp-kms / azure-key-vault |
云 KMS 审计 → key 访问 edge（绝不含 key 材料） | approximate |
external-secrets / sops / kmip |
密钥管理清单 / KMIP locate → 预配/托管 edge | approximate（存在性，非使用）; kmip: Business |
istio-telemetry |
Istio Telemetry CRD → L7 mesh edge | approximate（解析的 CRD，非实时流） |
egress-proxy |
Egress-proxy 裁决日志 → L7 出站 edge | approximate |
kong-audit |
Kong 审计日志 → 配置变更 finding | approximate |
ai-gateway |
Envoy AI Gateway 用量记录 → 成本采样（FinOps） | 成本流 |
git |
普通 git 发布绑定：为 gitpublish 推送批准一个 SSH 或 HTTPS git 远程的名册行 | 不观测任何内容；仅推送（普通远程没有拉取请求或合并 API） |
github |
将 GitHub repository 作为 agent data source → observed R/RW access edge（webhook-first、API poll reconciliation）+ permitted ACL edge | observed + permitted；流式（poll_seconds: 0） |
gitlab |
GitLab repository → observed R/RW access edge + permitted ACL edge | observed + permitted；流式（poll_seconds: 0） |
态势观测者 —— findings，而非访问 edge
Section titled “态势观测者 —— findings，而非访问 edge”读优先的观测者，将态势（sync/health/drift、认证异常）浮现为 finding；它们绝不改动 estate。
| Kind | 观测内容 |
|---|---|
runtime |
AI 工作负载运行于何处（Linux procfs、Docker daemon、Kubernetes API）→ 容纳 edge + 健康 finding（需要 host 访问——见 部署要求） |
argocd / flux / crossplane |
GitOps / 控制平面 CRD → sync、health、drift、composition 态势 |
kerberos |
KDC 认证遥测 → Kerberoasting finding |
aaa |
RADIUS / TACACS+ AAA 观测 |
ssf |
Shared-Signals / CAEP 接收器（agent kill-switch） |
edugain / openidfed |
Federation 聚合 / OpenID-Federation 信任链 → federation 态势 |
managed-settings |
Claude managed-settings 策略 → permitted edge + drift finding |
envoy-ai-gateway |
Envoy AI Gateway 声明配置导出 → gateway posture + gateway-vs-Olivares policy drift（ai-gateway usage stream 的 config sibling） |
kong-agent-gateway |
Kong agent-gateway 声明配置导出 → posture + policy drift |
litellm |
LiteLLM proxy 声明配置导出 → posture + policy drift |
bedrock-kb |
Amazon Bedrock Knowledge Bases retrieval health/config（Agent Runtime Retrieve health-check）→ per-KB posture finding + KB→data-source edge。绝不 RetrieveAndGenerate（无 billable inference），绝不读取完整 document content |
tak |
TAK Server CoreConfig.xml posture（+ 可选 mTLS probe）和受治理、minimal-data 的 Cursor-on-Target ingest（position digest、uid hashed） |
a2a |
Agent2Agent（A2A）v1.0 peer → Agent Card discovery + JWS/JCS signature verification（peer trust level），以及 observed task/message interaction 作为 agent↔agent edge。仅观测——绝不 dispatch task；发出 signed card 是另一项能力 |
Untrusted hint —— MCP 自省
Section titled “Untrusted hint —— MCP 自省”mcp source 对 MCP server（stdio + Streamable HTTP）进行自省，并发出携带 server 声明的
R/RW 提示的能力 edge，外加协议修订、特性面与注册来源的 finding。按 MCP 规范，一个工具标注
是不可信声明——一项能力主张，需对照已观测 source 加以佐证，绝不单独信任。（协作式
claude source 也会将 MCP 自省作为其 OTLP 路径的一部分；mcp 是你指向某个 server 列表或某个
.mcp.json 的独立自省器。）
| Kind | 观测内容 | 层级 |
|---|---|---|
mcp |
MCP server 的 tools/resources/prompts → 声明能力 edge + 态势 finding | untrusted hint |
进程外 broker 与 mesh 观测者
Section titled “进程外 broker 与 mesh 观测者”这些携带庞大的网络协议依赖树，因此每一个都在进程外运行（依赖绝不链接进核心）。 一个连接器可触达多个目标。
| Kind | 观测内容 |
|---|---|
kafka |
Kafka / Event Hubs / Redpanda / MSK topic 活动 |
amqp |
AMQP broker（RabbitMQ、Azure Service Bus） |
nats / mqtt / cloudqueue |
NATS、MQTT、云队列活动 |
debezium |
Debezium 变更数据捕获流 |
envoy |
Envoy ALS / ext_authz / ext_proc 观测服务 |
hubble |
Cilium Hubble 流数据 |
身份名册 provider
Section titled “身份名册 provider”这些填充非人类身份名册，以锐化归因（把 approximate edge 变成 attributed）。每个带 grant
面的 source 也会从 Gather 发出其permitted-access（SignalPolicy）edge——即
permitted-vs-observed 差异中的 PERMITTED 侧：
| Kind | 名册 | Permitted edge |
|---|---|---|
vault |
entity、group、policy | ACL policy path grant（vault.path），按每个绑定 entity 展开 |
ldap |
user、service/computer 账户、group | 特权组成员 → 目录 grant（ldap.directory） |
idp（Okta / Entra） |
user、app/service principal、group | app 分配 / scope grant（okta.app / entra.app） |
infisical |
machine identity、org member、project | project grant（infisical.project） |
keycloak |
realm、client、role、group、user | 仅名册（空操作 Gather） |
pingone / forgerock |
通过同一个 multi-provider reader 获取 PingOne / ForgeRock directory roster（kind 会预设对应 provider；ping 是 pingone alias） |
仅名册（空操作 Gather） |
spiffe |
SPIRE 注册条目 | 仅名册（空操作 Gather） |
在 identity 条目上接入 as_source: true 可在每次引导时执行一次性的 permitted-grant 扫描，
或用一个带 poll_seconds 的单独 sources 条目进行周期性重扫。每个条目都以它自己的 name
注册，因此同一 kind 的多个条目可以并存：okta 与 entra 由同一个 idp 连接器提供服务，但它们
仍是两个各自独立的 source，各有自己的配置、状态与生命周期。必须唯一的是名称，而不是连接器。
组/角色成员关系仅随类型化的名册快照传递，绝不作为 edge。
Agent 身份 federation
Section titled “Agent 身份 federation”超大规模厂商的 agent registry 针对本平面的 SPIFFE/WIF 名册进行只读 federation。它们每个
agent 的行（agent_identity / workload_identity kind）是专用、非共享的身份，因此 access map
将它们视为确凿的每个 agent 归因；来自同一 source 的辅助行（blueprint principal、凭据
provider、由 service-account 支撑的 agent）保持近似。Federation 绝不写入 registry；向 control
tower 的导出是一项独立的、后续的能力。
| Kind | Federate | Gather |
|---|---|---|
entra-agent |
经 Graph v1.0 的 Microsoft Entra Agent ID（agent identity、agent user、blueprint、blueprint principal、owner/sponsor、快照内 orphan 计算、opt-in soft-deleted） | nhi_longlived_credential drift finding、CA/risky-agent/governance/sponsorless posture finding，以及 opt-in beta auditLogs/signIns observed agent access edge——添加带 poll_seconds 的 sources 条目 |
agentcore |
AWS Bedrock AgentCore Identity（workload identity、token-vault 凭据 provider）+ 作为集合的 AgentCore Policy 引擎/Cedar policy | nhi_longlived_credential drift finding（静态 API-key provider）——添加一个带 poll_seconds 的 sources 条目 |
google-agent |
Google Agent Identity（Agent Runtime reasoning engine；基于 SPIFFE 的 agent identity）加 Agent Registry / Agent Gateway posture。row 使用完整 SPIFFE ID 作 ref，与 spiffe roster 收敛；Gather 检测 unattributed registry agent、可读 registry 之外的 shadow reasoning engine、risky MCP tool annotation 与 gateway registry posture |
registry/gateway posture finding 与 shadow-agent detection——添加带 poll_seconds 的 sources 条目 |
agent365 |
经 Graph v1.0 的 Microsoft Agent 365 registry（package-level inventory，含没有 Entra identity 的 agent），支持 app-permission client credential 或 delegated token、opt-in package detail | registry-hygiene finding（已部署但 blocked 的 package；向所有 user 部署的 external/shared package）——添加带 poll_seconds 的 sources 条目 |
foundry-agents |
经 ARM + Foundry Agent Service v1 获取 Microsoft Foundry project、agent application/deployment 与当前 Agent Service agent；将 app identity link 与 entra-agent 关联 |
ARM-derived application posture finding（缺少 Entra agent identity；已启用 app 的 deployment failed）——添加带 poll_seconds 的 sources 条目 |
ai-control-tower |
ServiceNow AI Control Tower 数字资产清点（Table API，只读） | 空操作（仅名册） |
oasf |
AGNTCY/OASF agent 描述符 + Agent Badge 验证——在身份规范符合 VCDM 2.0 之前为 EXPERIMENTAL | badge finding——添加一个带 poll_seconds 的 sources 条目 |
onepassword |
1Password 账户作为 secret_store 托管者 |
item 使用密钥访问 edge——添加一个带 poll_seconds 的 sources 条目 |
对于带可重轮询 Gather 的七个 kind（entra-agent、agent365、agentcore、
foundry-agents、google-agent、oasf、onepassword），将
名册那半作为一个不带 as_source 的 identity 条目接入，将 edge/finding 那半作为一个
带 poll_seconds 的单独 sources 条目接入——不要两者皆用 as_source: true，那只会每次引导
扫描一次。（同一 kind 的两个条目已不再是障碍：各自以自己的 name 注册。原因在于频率——每次引导
一次的扫描并不是重扫。）
registry 声明的 owner/sponsor 会在名册同步期间落到 NHI 生命周期记录上（与
PUT /nhi/{ref}/ownership 同语义），而 registry 断言的孤儿（一个 blueprint 已不存在的 Entra
agent）落到同一记录的 registry_orphaned 标志上——生命周期扫描将其 OR 进 orphaned 并发出
nhi_orphaned finding，因此孤儿检测无需任何额外配置即可监视 federation 的 agent。vault-audit
source（位于 sources 之下，而非 identity）跟踪 Vault 文件审计设备，并为相同的
entity:<name> ref 发出 vault permitted grant 的 OBSERVED 对应物。
知识文档 source（非 access-map 覆盖）
Section titled “知识文档 source（非 access-map 覆盖）”这些喂给知识模块（模块 VIII），而非 access map：它们摄取文档内容以供受治理检索，
发出无 R/RW edge，且在总线上产生无观测。模块在收到摄取请求时拉取它们（List → Fetch）
（POST /v1/m/knowledge/kbs/{id}/ingest {"source":"<name>"}），因此它们接入该模块——在
OLIVARES_SOURCES_CONFIG 中将它们命名于 documents 之下，而非 sources。每一个都是只读且
minimal-data：它携带 source 的 ACL 与来源（绝不含个人邮箱；模块在持久化前会脱敏正文）。
| Kind | 摄取内容 |
|---|---|
gdrive |
Google Drive 文档（Docs/Sheets/Slides/文件） |
confluence |
Atlassian Confluence 空间与页面 |
notion |
Notion 工作区、数据库与页面 |
sharepoint |
Microsoft SharePoint / OneDrive 站点与文档 (Business) |
s3content |
对象存储内容（S3 / R2 / GCS 对象） |
sap_odata |
SAP OData service entity，作为 governed document (Business) |
salesforce |
Salesforce object/record，作为 governed document (Business) |
snowflake |
Snowflake table/row，作为 governed document（不同于 snowflake-audit R/RW observer） |
azure_ai_search |
Azure AI Search index document |
postgres |
PostgreSQL row，作为 governed document——构造上只读、声明 per-row ACL、per-column classification（不同于 pgaudit R/RW observer；不是 NL-to-SQL）。见将 Postgres 用作受治理上下文源。 |
filesystem |
文件服务器内容（local / NFS / SMB）——构造上将读取限制在 root，POSIX owner/group/ACL 映射为 Document ACL，使用 xattr classification（不同于 filelog log sink）。见治理文件服务器。 |
// OLIVARES_SOURCES_CONFIG —— 文档 source 位于 "documents" 之下，绝不在 "sources"{ "documents": [ { "name": "eng-wiki", "kind": "confluence", "config": { "export_path": "/var/lib/olivares/confluence" } } ]}输出目的地（非覆盖）
Section titled “输出目的地（非覆盖）”输出连接器投递 finding 与通知；它们什么都不观测，也没有覆盖层级。它们与 source 分开配置。
进程内 destination kind：slack、teams、pagerduty、opsgenie、webhook、
siem、splunkhec、syslog、servicenow、jira、email、twilio、
chronicle、datadog、elastic、snmp、filelog、otlplog（OTLP/HTTP log）、
s3archive (Business: Regulated Operations)（S3 Object Lock WORM sink——每条通知生成一个 immutable、lock-verified object）
与 teamsbot (Business: Regulated Operations)（事件闭环中以注册机器人接入的 Teams connector；Community 二进制会跳过
此类目标，并记录一行注明 Business 的日志）。
三种 broker egress kind 作为内嵌插件在进程外运行（其网络协议 dependency tree
绝不链接进 engine，与 plugin source 完全相同）：kafka、amqp 和 cloudqueue——
kind name 与其 source twin 相同；作为 destination 时，各自将通知以 CloudEvent 投递至配置的
broker/queue。未执行 task build:connectors 的普通 dev build 会在启动时诚实告警并跳过该
destination，而不会假装它存在。
部署要求与诚实归因
Section titled “部署要求与诚实归因”R/RW 差异连接器已接入默认二进制，但其中两个带有其余连接器没有的部署要求——连接器代码与 host 无关，它所消费的数据则不然：
ebpf消费 Tetragon 的内核事件导出。该连接器不需要任何内核能力 ——它读取一个由 Tetragon 拥有的0600文件/FIFO/stdin（events_path，默认-）。Tetragon 本身是一个独立、加固的 DaemonSet，持有最小的CAP_BPF+CAP_PERFMON，以非 root 运行， 带 seccomp/AppArmor 且无入站监听器。因此部署是：以特权运行 Tetragon（其捆绑的文件访问 + TCP-connect TracingPolicy），然后将ebpf指向其导出。Tetragon 最低版本：v1.0。runtime读取 host 的 procfs（proc_root，默认/proc）、Docker daemon socket （docker_socket，默认关闭——对docker.sock的读访问等同于 root；请刻意选择性启用， 理想做法是经一个 GET 白名单的 socket 代理）和/或 Kubernetes API（默认为集群内 ServiceAccount）。 只挂载你启用的内容。gcp-audit以一个 GCP service account（key JSON 或 WIF/ADC 签发的access_token）认证， 且仅需只读管理角色：roles/resourcemanager.organizationViewer+roles/iam.serviceAccountViewer+roles/logging.viewer——读取 Data Access 条目额外需要roles/logging.privateLogViewer。设定organization_id（org 遍历 + org 范围审计）和/或projects。Data Access 审计日志在 GCP 中默认关闭：按 IAM/data-access 配置启用，否则活动流 会诚实地少报。azure-activity以一个 Entra service principal（client-credentials）或一个托管身份的access_token认证，且仅需 tenant root（或每个 subscription）上的 Reader 角色——该单一角色 即可覆盖 Resource Graph、subscription 列举与 Activity Log。subscriptions未设置时会自动列举 subscription。
两者均在进程内运行，与各种类的进程模式下未列为插件的其他类型相同。若要独立运行，请构建其 connectors/<kind>/cmd/ 程序并作为外部插件准入。
每个 source 都是选择性启用、deny-closed 的：缺失的 log_path/path/events_path 在启动时
是一个配置错误（该 source 未接入），绝不是静默的空操作。演示 estate（quickstart）
通过真实总线播下等价的合成观测，让你在接入一个实时 source 之前即可端到端看到 clean 层级的信号。
- Connect a source —— 连接器模型及如何接入一个。
- Connect Claude Code —— 端到端的协作路径。
- Module III — the access map —— edge 最终变成什么。
- Honesty & limits —— 贯穿全产品的诚实契约。