読み取り/書き込みアクセスマップは、他のすべての機能の基盤となるデータ構造です。これを理解すれば、製品全体を理解できます。
ノードと型付きエッジ
マップはグラフです。エージェントがノードです。エージェントがアクセスできるリソース — データベース、オブジェクトストア、MCP サーバー、API、キュー — もノードです。すべてのエッジは型付きアクセス関係を表します: R（エージェントがリソースを読み取れる）または RW（エージェントがリソースを読み書きできる）。
各エッジを読み取りと書き込みで型付けするのは意図的な設計です。最小権限の原則とインシデント影響範囲は、単なる接続性ではなく書き込みアクセスの関数です。ウェアハウスを読み取りのみできるレポーティングエージェントと、それを書き換えできるデプロイメントエージェントは同じリスクではありません。フラットな「アクセスあり」リストはまさにその違いを隠してしまいます。
許可と観測
マップは2つのレイヤーを保持し、継続的にその差分を取ります:
- 許可（Permitted） — エージェントが許可されている操作。付与とポリシーから導出されます。
- 観測（Observed） — エージェントが実際に行っていると観測された操作。テレメトリとネイティブ監査証跡から導出されます。
差分こそが価値の源泉です:
- 予期しないアクセス — 観測されたが許可されていないエッジ。セキュリティチームが実際に検出したいものです。
- 未使用の付与 — 許可されているが一度も行使されていないエッジ。曖昧な「IAMを見直してください」という忠告ではなく、具体的な最小権限クリーンアップリストです。
ライブ製品ツアーでは、実際のキャプチャ上でこのオーバーレイを確認できます。
忠実度は段階的 — そして表示される
マップはソースが証明できる範囲でのみ正確であり、はったりをかけるのではなくそれを明示します。各エッジには2つの独立した軸が表示されます:
- 読み取り/書き込みのカバレッジ:
clean— ネイティブ監査によりR/RWが明確に判別可能（pgAudit 経由の PostgreSQL、CloudTrail 経由のオブジェクトストレージ、ウェアハウスやデータレイク）。lossy— 部分的なシグナル。例: 一部のドキュメントストアやベクターストア。opaque— パッシブに再構築できない（Redis、SQLite、D1）。エッジは推測ではなくunknownとしてマークされます。
- 帰属（Attribution）:
firm— ソースがエージェントごとの識別情報を持っている。approximate— 共有サービスアカウントにより、どのエージェントが操作したかが不明確。
両方の軸がエッジに付随するため、確実に判明している関係とかろうじて観測された関係が、同等の確実性であるかのように表示されることはありません。
設計上の読み取り優先
このマップの構築は観測活動であり、傍受活動ではありません。Olivares AI はエージェントとそのリソース間のリクエストパスに介在しません。テレメトリとネイティブ監査をアウトオブバンドで取り込みます。マップの閲覧自体が、特権的でテナントスコープの完全に監査された操作です。製品はまず観測しガバナンスを行い、アクションを取れる場合は deny-closed（デフォルト拒否）で実行します — 無差別なエグゼキューターとしては動作しません。
関連
- Olivares AI とは? — 製品を1ページで説明。
- クイックスタート — デモ環境でマップを確認。
- アーキテクチャ — 各要素の構成、セルフホストおよびエアギャップ対応。