一个夸大自身能力的安全工具比没有工具更糟糕：它给你带来虚假的安全感。因此，访问映射中的每条边都携带两个独立的保真度标签，产品会如实呈现它们——绝不将一条勉强已知的边伪装成一条已证实的边。
这两个轴回答两个不同的问题：
- 覆盖范围 ——数据源能在多大程度上证明这次访问是读还是写。
- 归因 ——这次访问与单个代理的关联有多牢固，而非共享身份。
它们独立变化。一个带有原生审计的数据仓库提供清晰的覆盖范围；如果每个代理共用一个服务账户来访问它，归因仍然只是近似的。两个轴都不从另一个推断而来。
覆盖范围：读与写
覆盖范围描述底层存储能告诉我们关于访问读/写性质的程度。它是数据源的属性，而非代理的属性。
clean——存储发出原生、权威的审计，因此读写分类是逐字记录的。包括通过 pgAudit 的 Postgres、通过 CloudTrail（s3.readOnly）的对象存储，以及数据仓库和数据湖（Snowflake、BigQuery、Redshift、Databricks、MSSQL、Oracle），加上内核级 eBPF 的真实数据。lossy——存储产生边，但较为粗略。文档存储（例如 MongoDB）属于此类：边存在，但读/写区分是近似的。opaque——存储完全不提供被动的读/写信号。Redis、SQLite 和 D1 无法通过观测来重建，因此边的mode标记为unknown而非猜测。
还有一个 mixed 层级，用于协作或工具级信号——MCP 工具、HTTP API、代理任务——这些不与某一类存储绑定。
核心规则是：当存储为 opaque 时，读/写分类为 unknown，绝不凭空捏造。而在 lossy 或 opaque 数据源上缺失的边并非证明访问未发生——只是数据源无法证明它发生了。这就是允许与观测的区别。
归因：哪个代理
归因描述观测到的访问与一个具体代理的关联有多牢固。审计日志将活动归因于凭证或角色，而非天然地归因于代理——因此这个轴比单纯的信号信任更严格，且采用默认拒绝：没有确定的按代理信号，它就保持低级别。
firm——访问明确解析到一个代理。这需要真正的按代理身份信号：一个 SPIFFE 工作负载 SVID、一个工作负载身份联合的服务账户、一个治理铸造的专用非人类身份，或一个只绑定到一个代理的凭证。approximate——身份已知，但无法确定单个代理。连接池后面的共享或池化服务账户、模糊的凭证，或仍在等待的按代理关联都属于此类。unknown——完全无法进行按身份归因。这是非协作后备观测到的opaque存储的底线，或者无法与任何身份关联的访问。绝不伪造代理。
因为归因采用默认拒绝，后续更弱的信号永远不能降级一条已确定归因的边——但强信号可以提升弱信号。两个轴也恰好在一个方向上交互：在 opaque 存储上，任何低于 firm 的归因都被拉低到 unknown，而不是将共享账户的猜测伪装成 approximate。
因此，按代理身份是高保真映射的硬性依赖。良好的治理意味着为每个代理分发身份——参见身份和治理模型。
为什么这很重要
标注两个轴的目的是克制。产品不会像对待 clean/firm 边那样，将 lossy/approximate 边标为违规，并且它公开展示 unknown 和 approximate，而非隐藏它们。一个系统尚无法确定归因的漂移发现会被标记为待调和，而非渲染为已确认的违规。
这就是为什么访问映射可以作为证据而非猜测来信任：每条边在两个维度上准确说明它知道多少。知道得少的地方，它如实说明。
这些标签出现在哪里
两个标签跟随图 API 和 UI 覆盖层中的每条边传递，同时附带产生该边的信号源。读取访问图是一项特权操作，限定于租户范围，并完全受审计。
访问映射图和漂移的确切字段级结构位于产品的类型化接口中，故意不作为 OpenAPI 合约的一部分提供——参见参考模块和诚实与局限页面，了解已证明与推断的完整边界。