Skip to content

Core concepts

Coverage & attribution fidelity

How Olivares AI labels every access-map edge with two honest axes — how well a source proves read vs write, and how firmly the access ties to one agent

A security tool that overstates what it knows is worse than no tool: it hands you a false sense of safety. So every edge in the access map carries two independent fidelity labels, and the product renders them honestly — it never dresses a barely-known edge up as a proven one.

The two axes answer two different questions:

  • Coverage — how well the source can prove whether this access was a read or a write.
  • Attribution — how firmly the access ties to a single agent, versus a shared identity.

They move independently. A warehouse with native audit gives clean coverage; if every agent shares one service account against it, attribution is still only approximate. Neither axis is inferred from the other.

Coverage: read vs write

Coverage describes what the underlying store can tell us about the read/write nature of an access. It is a property of the source, not of the agent.

  • clean — the store emits native, authoritative audit, so read vs write is classified verbatim. This is Postgres via pgAudit, object storage via CloudTrail (s3.readOnly), and the warehouses and lakes (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), plus the kernel-level eBPF ground truth.
  • lossy — the store yields edges, but coarse ones. Document stores (for example MongoDB) fall here: an edge exists, but the read/write split is approximate.
  • opaque — the store gives no passive read/write signal at all. Redis, SQLite, and D1 cannot be reconstructed by observing them, so the edge’s mode is marked unknown rather than guessed.

There is also a mixed tier for cooperative or tool-level signals — MCP tools, HTTP APIs, agent tasks — that are not tied to one store class.

The cardinal rule: where a store is opaque, the read/write classification is unknown, never invented. And an absent edge on a lossy or opaque source is not proof that an access did not happen — only that the source could not prove it did. That is the difference between permitted and observed.

Attribution: which agent

Attribution describes how firmly an observed access ties back to one concrete agent. Audit logs attribute activity to a credential or a role, not inherently to an agent — so this axis is stricter than mere signal trust, and it is deny-closed: without a firm per-agent signal, it stays low.

  • firm — the access resolves unambiguously to one agent. This requires a real per-agent identity signal: a SPIFFE workload SVID, a workload-identity-federated service account, a governance-minted dedicated non-human identity, or a credential bound to exactly one agent.
  • approximate — an identity is known, but a single agent cannot be pinned. A shared or pooled service account behind a connection pool, an ambiguous credential, or a per-agent link that is still pending all land here.
  • unknown — no per-identity attribution is possible at all. This is the floor for an opaque store seen by a non-cooperative backstop, or an access that ties to no identity. Never a fabricated agent.

Because attribution is deny-closed, a later, weaker signal can never downgrade a firmly attributed edge — but a strong signal can raise a weak one. The two axes also interact in exactly one direction: on an opaque store, any attribution short of firm is floored to unknown, rather than being passed off as a shared-account guess dressed up as approximate.

Per-agent identity is therefore a hard dependency for the high-fidelity map. Governing well means issuing identity per agent — see Identity and the governance model.

Why this matters

The point of labelling both axes is restraint. The product will not headline a lossy/approximate edge as a violation the way it would a clean/firm one, and it surfaces unknown and approximate openly instead of hiding them. A drift finding the system cannot yet firmly attribute is marked reconciliation-pending, not rendered as a confirmed breach.

This is why the access map can be trusted as evidence rather than as a guess: each edge says, in two dimensions, exactly how much it knows. Where it knows little, it says so.

Where these labels show up

Both labels travel on every edge in the graph API and the UI overlay, alongside the signal source that produced the edge. Reading the access graph is a privileged, tenant-scoped, fully audited action.

The exact field-level shapes for the access-map graph and drift live in the product’s typed interfaces and are deliberately not part of the served OpenAPI contract — see the reference modules and the honesty and limits page for the full boundary of what is proven versus inferred.