커버리지 & 귀속 충실도

Olivares AI가 접근 맵 에지에 소스의 읽기·쓰기 증명력과 에이전트 귀속 확실성이라는 두 축을 표시하는 방법을 설명합니다.

자신이 아는 것을 과장하는 보안 도구는 도구가 없는 것보다 나쁩니다: 그것은 거짓 안전감을 줍니다. 따라서 접근 맵의 모든 에지는 두 개의 독립적인 충실도 레이블을 가지며, 제품은 이를 정직하게 렌더링합니다 — 겨우 알려진 에지를 증명된 것처럼 꾸미지 않습니다.

두 축은 두 가지 다른 질문에 답합니다:

커버리지 — 이 접근이 읽기인지 쓰기인지 소스가 얼마나 잘 증명할 수 있는가.
귀속 — 접근이 공유 신원이 아닌 단일 에이전트에 얼마나 확실하게 연결되는가.

이들은 독립적으로 변합니다. 네이티브 감사가 있는 웨어하우스는 깨끗한 커버리지를 제공합니다; 모든 에이전트가 하나의 서비스 계정을 공유하면 귀속은 여전히 approximate에 불과합니다. 어느 축도 다른 축에서 추론되지 않습니다.

커버리지: 읽기 vs 쓰기

커버리지는 기본 스토어가 접근의 읽기/쓰기 성질에 대해 무엇을 알려줄 수 있는지를 설명합니다. 이것은 에이전트가 아닌 소스의 속성입니다.

clean — 스토어가 네이티브의 권위 있는 감사를 출력하므로 읽기 vs 쓰기가 그대로 분류됩니다. 이것은 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 계층도 있습니다.

핵심 규칙: 스토어가 opaque인 경우 읽기/쓰기 분류는 unknown이며, 절대 만들어내지 않습니다. 그리고 lossy나 opaque 소스에서 에지가 없다는 것은 접근이 발생하지 않았다는 증거가 아닙니다 — 단지 소스가 발생했음을 증명할 수 없었다는 것입니다. 이것이 허용된 것과 관찰된 것의 차이입니다.

귀속: 어떤 에이전트

귀속은 관찰된 접근이 하나의 구체적인 에이전트에 얼마나 확실하게 연결되는지를 설명합니다. 감사 로그는 활동을 자격증명 또는 역할에 귀속시키며 본질적으로 에이전트에 귀속시키지 않으므로, 이 축은 단순한 신호 신뢰보다 엄격하며 기본 거부(deny-closed)입니다: 확실한 에이전트별 신호 없이는 낮게 유지됩니다.

firm — 접근이 하나의 에이전트에 명확하게 해결됩니다. 이를 위해서는 실제 에이전트별 신원 신호가 필요합니다: SPIFFE 워크로드 SVID, 워크로드-신원-페더레이션 서비스 계정, 거버넌스에서 발급한 전용 비인간 신원, 또는 정확히 하나의 에이전트에 바인딩된 자격증명.
approximate — 신원은 알려져 있지만 단일 에이전트를 특정할 수 없습니다. 커넥션 풀 뒤의 공유 또는 풀링된 서비스 계정, 모호한 자격증명, 또는 아직 보류 중인 에이전트별 링크가 여기에 해당합니다.
unknown — 신원별 귀속이 전혀 불가능합니다. 이것은 비협력적 백스톱이 본 opaque 스토어의 최저 수준이거나 신원에 연결되지 않는 접근입니다. 절대 조작된 에이전트가 아닙니다.

귀속은 기본 거부이므로, 이후의 약한 신호는 확실하게 귀속된 에지를 다운그레이드할 수 없습니다 — 그러나 강한 신호는 약한 것을 올릴 수 있습니다. 두 축은 정확히 한 방향으로만 상호작용합니다: opaque 스토어에서 firm 이하의 모든 귀속은 공유 계정 추측을 approximate으로 포장하는 대신 unknown으로 최저 수준이 됩니다.

따라서 에이전트별 신원은 고충실도 맵의 필수 의존성입니다. 잘 거버넌스하려면 에이전트별로 신원을 발급해야 합니다 — 신원과 거버넌스 모델을 참조하세요.

이것이 중요한 이유

두 축에 모두 레이블을 붙이는 요점은 자제입니다. 제품은 clean/firm 에지에서 위반으로 표시하는 방식으로 lossy/approximate 에지를 표제로 내세우지 않으며, unknown과 approximate를 숨기지 않고 공개적으로 표시합니다. 시스템이 아직 확실하게 귀속할 수 없는 드리프트 발견은 확인된 침해로 렌더링되지 않고 조정 보류(reconciliation-pending)로 표시됩니다.

이것이 접근 맵이 추측이 아닌 증거로 신뢰받을 수 있는 이유입니다: 각 에지가 두 차원에서 정확히 얼마나 알고 있는지 말합니다. 아는 것이 적은 곳에서는 그렇게 말합니다.

이 레이블이 표시되는 곳

두 레이블 모두 그래프 API와 UI 오버레이의 모든 에지에, 에지를 생성한 신호 소스와 함께 전달됩니다. 접근 그래프를 읽는 것은 권한이 필요한, 테넌트 범위의, 완전히 감사되는 작업입니다.

접근 맵 그래프와 드리프트에 대한 정확한 필드 수준 형태는 제품의 타입화된 인터페이스에 있으며 제공되는 OpenAPI 계약의 일부가 아닙니다 — 증명된 것과 추론된 것의 전체 경계에 대해서는 참조 모듈과 정직함과 한계 페이지를 참조하세요.