自身の知識を過大評価するセキュリティツールは、ツールがないよりも悪い結果をもたらします。誤った安心感を与えるからです。そのため、アクセスマップのすべてのエッジには2つの独立した忠実度ラベルが付随し、製品はそれらを正直に表示します — かろうじて判明しているエッジを証明済みのエッジとして装飾することはありません。
2つの軸は、それぞれ異なる問いに答えます:
- カバレッジ — ソースがこのアクセスが読み取りなのか書き込みなのかをどれだけ証明できるか。
- 帰属（Attribution） — アクセスが単一のエージェントにどれだけ確実に紐づくか、共有IDとの対比。
これらは独立して変動します。ネイティブ監査を持つウェアハウスはクリーンなカバレッジを提供しますが、すべてのエージェントが1つのサービスアカウントを共有している場合、帰属は依然としてapproximateです。どちらの軸も他方から推論されることはありません。
カバレッジ: 読み取りと書き込み
カバレッジは、基盤となるストアがアクセスの読み取り/書き込みの性質について何を教えてくれるかを記述します。これはエージェントではなくソースの属性です。
clean— ストアがネイティブで権威ある監査を出力するため、読み取りと書き込みがそのまま分類されます。pgAudit 経由の Postgres、CloudTrail 経由のオブジェクトストレージ（s3.readOnly）、ウェアハウスおよびデータレイク（Snowflake、BigQuery、Redshift、Databricks、MSSQL、Oracle）、そしてカーネルレベルの eBPF グラウンドトゥルースが該当します。lossy— ストアはエッジを生成しますが、粗いものです。ドキュメントストア（例えば MongoDB）がここに該当します: エッジは存在しますが、読み取り/書き込みの分割はapproximateです。opaque— ストアがパッシブな読み取り/書き込みシグナルを一切提供しません。Redis、SQLite、D1 は観測によって再構築できないため、エッジのmodeは推測ではなくunknownとしてマークされます。
協調的またはツールレベルのシグナル（MCP ツール、HTTP API、エージェントタスク）には mixed ティアもあり、1つのストアクラスに紐づきません。
基本原則: ストアが opaque の場合、読み取り/書き込み分類は unknown であり、決して捏造されません。また、lossy や opaque なソースにおける観測エッジの不在は、アクセスが発生しなかった証明ではありません — ソースがそれを証明できなかっただけです。これが許可と観測の違いです。
帰属: どのエージェントか
帰属は、観測されたアクセスが1つの具体的なエージェントにどれだけ確実に紐づくかを記述します。監査ログは活動をクレデンシャルやロールに帰属させるものであり、本質的にエージェントに帰属させるものではないため、この軸は単なるシグナルの信頼性よりも厳格であり、deny-closed です: 確実なエージェントごとのシグナルがなければ、低い状態のままです。
firm— アクセスが1つのエージェントに明確に解決されます。これには実際のエージェントごとの識別シグナルが必要です: SPIFFE ワークロード SVID、ワークロードID連携されたサービスアカウント、ガバナンスが発行した専用の非人間ID、または1つのエージェントにのみバインドされたクレデンシャルです。approximate— IDは判明していますが、単一のエージェントを特定できません。コネクションプール背後の共有またはプールされたサービスアカウント、曖昧なクレデンシャル、またはまだ保留中のエージェントごとのリンクがここに該当します。unknown— IDごとの帰属が一切不可能です。非協調バックストップが観測したopaqueストア、またはIDに紐づかないアクセスの最低レベルです。捏造されたエージェントは決して生成されません。
帰属は deny-closed であるため、後からの弱いシグナルが確実に帰属されたエッジをダウングレードすることはありません — しかし、強いシグナルは弱いものを引き上げることができます。また、2つの軸は正確に1つの方向でのみ相互作用します: opaque なストアでは、firm に満たない帰属はすべて unknown にフロア設定され、共有アカウントの推測を approximate として装飾することはありません。
したがって、エージェントごとのIDは高忠実度マップのハードな依存関係です。適切なガバナンスとは、エージェントごとにIDを発行することを意味します — IDとガバナンスモデルを参照してください。
なぜこれが重要なのか
両方の軸をラベル付けする目的は節制です。製品は lossy/approximate なエッジを clean/firm なエッジと同じように違反としてヘッドラインにしません。unknown と approximate を隠すのではなく公開します。システムがまだ確実に帰属できないドリフトの発見は、確認されたブリーチとしてではなく、reconciliation-pending（照合保留中）としてマークされます。
アクセスマップが推測ではなくエビデンスとして信頼できるのはこのためです: 各エッジが2つの次元で、自身がどれだけ知っているかを正確に示します。知識が少ない場合は、そう表明します。
これらのラベルが表示される場所
両方のラベルは、グラフ API と UI オーバーレイのすべてのエッジに、エッジを生成したシグナルソースとともに付随します。アクセスグラフの閲覧は、特権的でテナントスコープの完全に監査された操作です。
アクセスマップグラフとドリフトの正確なフィールドレベルの形状は、製品の型付きインターフェースに存在し、意図的に提供される OpenAPI コントラクトの一部ではありません — リファレンスモジュールと正直さと制限事項ページで、証明されたものと推論されたものの完全な境界を確認してください。