Skip to content

Core concepts

Permitted vs Observed

The diff at the heart of the access map — what an agent is granted versus what it is seen doing — surfacing unexpected access and unused grants

Every edge in the access map carries two independent facts: whether the access is permitted and whether it has been observed. The diff between those two layers is the differentiator — it is what turns a static graph into a finding.

Two layers on one edge

The map does not keep a separate “policy graph” and “telemetry graph”. Each edge is a single relationship (origin to resource, typed read or read-write) that carries both flags:

  • Permitted — a grant or policy allows this access. The signal source is the declared policy itself.
  • Observed — the access was actually seen happening, derived from telemetry and native audit (OpenTelemetry from cooperative agents, PostgreSQL pgAudit, cloud audit logs, a kernel-level eBPF backstop).

One nuance that matters for honesty: not permitted means “not known to be permitted”, not “forbidden”. The map records what it can prove from declared grants; the absence of a grant is a gap to investigate, not an enforcement verdict.

The diff: where the value is

Least-privilege drift is simply the set of edges where the two flags disagree. It splits into two operationally distinct findings:

  • Unexpected access — observed but not permitted. An agent touched a resource no grant covers. This is the security-relevant half, surfaced as the headline finding.
  • Unused grants — permitted but never observed. A grant nobody ever exercised. This is your concrete least-privilege cleanup list, not a vague “review your IAM” reminder.

The edges where both flags agree — permitted and used, or neither — are the boring, expected steady state. The diff is the small, actionable slice in between.

Honesty inside the diff

A naive diff produces false findings, so the reconciliation is deliberately conservative.

Reconciliation pending

Audit attributes an access to a credential or role; a grant is written against an identity; a cooperative signal names an agent or session. When the access map cannot yet firmly link the acting agent to the identity its grant was written for, it cannot prove the access is permitted — but it must not headline it as a violation either. Such edges are flagged reconciliation_pending: honest uncertainty, not a fabricated finding. They resolve cleanly once per-agent identity links the credential to the agent.

Grants on resources nobody watches

Some grants live on resource kinds that have no observed-side collector — there is nothing watching who actually used an LDAP directory or an IdP app assignment. For those, “never observed” is the expected steady state, not evidence of over-provisioning. They are kept out of the headline unused-grants list rather than inflating it with noise.

Coverage and attribution still travel with the edge

The diff inherits the tiered fidelity of the underlying edges. On an opaque store (Redis, SQLite, D1) there is no passive read/write signal at all, so the absence of an observed edge is not proof the access did not happen — it is silence. Likewise a shared service account collapses attribution to approximate. The diff never presents a low-confidence finding as if it were firm.

When the diff is computed over a partial window (a very large estate exceeding the page bound), the result is explicitly marked as partial rather than presented as authoritative.

Detective, not in the path

Producing this diff is an out-of-band, detective activity. The control plane runs in your own infrastructure (and can be air-gapped); it observes through logs, OpenTelemetry and native audit, and it does not sit in the request path between an agent and its resources. A collector failing never breaks production traffic.

Two consequences follow. First, the diff is a report, not a gate: it surfaces what already happened. Where the product does act on a finding, it does so deny-closed and on demand — never as a blanket executor. Second, reading the diff is itself a privileged, tenant-scoped, fully-audited action: the act of inspecting who-can-reach-what is recon-relevant, and the read is recorded in the append-only audit ledger before any edge is returned.

This is also why the diff is safe to run on sensitive estates: the map stores the relationship — origin, resource, read/write, source, confidence, timestamps — never the payloads, SQL bodies, secrets or PII that flowed across the edge. What is not stored cannot leak.