32 lines
4.5 KiB
Markdown
32 lines
4.5 KiB
Markdown
---
|
|
title: AI Agent Telemetry Privacy
|
|
created: 2026-07-01
|
|
updated: 2026-07-16
|
|
type: concept
|
|
tags: [agent, privacy, security, data-protection, reliability]
|
|
sources: [raw/articles/claude-code-telemetry-audit-2026.md, raw/articles/openai-codex-agent-approvals-security-2026.md, raw/articles/theregister-claude-code-transcript-retention-2026.md, raw/articles/simon-grok-build-source-privacy-2026.md]
|
|
confidence: medium
|
|
---
|
|
|
|
# AI Agent Telemetry Privacy
|
|
|
|
AI agent telemetry privacy は、coding agent や CLI agent が利用状況、エラー、trace、repo 情報、transcript をどこへ送り、どの opt-out が何を止めるのかを扱う論点。[[ai-agent-identity-security]] が「agent が他サービスへ何の権限でアクセスするか」を扱うのに対し、こちらは agent 自体が operator や作業環境について何を観測・送信・保存するかに焦点を置く。
|
|
|
|
Adnane Khan の Claude Code 2.1.196 audit は、公開文書の「Statsig metrics + Sentry errors」という説明と実装がずれている可能性を示す。bundle 内では Statsig/Sentry SDK ではなく、Anthropic 1P OTLP event logging、Datadog logs、Datadog error tracking、ユーザー設定の 3P OTLP が見つかったとされる。特に、Datadog feature event path が server-side gate に依存し、`DISABLE_TELEMETRY` / `DO_NOT_TRACK` / `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` だけでは完全に止まらない可能性を指摘している。^[raw/articles/claude-code-telemetry-audit-2026.md]
|
|
|
|
## 見るべき軸
|
|
|
|
- **送信先の透明性**: agent の telemetry が vendor 直送、Datadog などの third-party、企業内 collector、local file のどれへ流れるかを区別する。公開文書の vendor 名や endpoint が古いと、利用者は実際の data processor を評価できない。
|
|
- **Opt-out の実効性**: 環境変数や設定が、metrics、error reporting、feature gate exposure、3P OTLP、update check をそれぞれ止めるかを pipeline ごとに見る。単一の `DISABLE_TELEMETRY` が「全部止まる」とは限らない。
|
|
- **Repo / CI identity**: audit は 1P event に git remote URL の 16 文字 SHA-256、GitHub Actions では actor や repository ID が載ると指摘している。source code 本文ではなくても、どの repo で agent を使ったかは強い作業文脈になる。
|
|
- **Error stack and local paths**: error tracking は prompt や file content を送らなくても、stack frame に file path や project layout が混ざる可能性がある。これは [[ai-agent-command-safety]] の command provenance と同じく、debuggability と漏えいリスクの境界になる。
|
|
- **Local transcript retention**: [[loop-engineering]] では transcript が検証・再開・説明責任の材料になるが、長期保存は credential や source code を抱える危険にもなる。保存期間、削除ログ、backup、export の仕様は privacy 機能でも reliability 機能でもある。
|
|
|
|
## 運用上の含意
|
|
|
|
Grok Build の初期 beta で directory 全体が xAI の Google Cloud bucket へ upload されうる挙動が批判され、保持 data 削除、retention default off、codebase の Apache 2.0 公開へつながった事例は、agent privacy を「telemetry」だけでなく作業 directory upload / session state upload / local-first fallback の問題として扱う必要を示す。Simon Willison の読解では、公開 codebase には GCS upload code の残骸や disabled `upload_session_state()` が残っており、agent の信頼回復には open source 化だけでなく、既定値・削除保証・実装上の upload path の検証が必要になる。^[raw/articles/simon-grok-build-source-privacy-2026.md]
|
|
|
|
Yuta の agent 運用では、telemetry は単純な「送る/送らない」ではなく、loop の観測性と privacy の交換条件として扱う必要がある。OpenAI Codex の approvals/security docs が示すように、OTel を自分の collector へ送れる設計は [[agent-harness-engineering]] の観測性を高める一方、collector 側の retention と access control を同時に決めなければならない。
|
|
|
|
この論点は [[data-protection-and-expression]] とも接続する。agent が開発者の作業文脈を観測するほど、利用者の control、説明、削除、第三者提供の透明性が重要になる。特に CLI agent は IDE より権限が広く、shell、repo、CI、browser-use、MCP server へまたがるため、telemetry 設計を product quality と security boundary の一部として読むべきである。
|