Product · Access map
See access from your configured sources
Compare granted access with observations from your configured sources. The map shows resolved origins and resources, with read/write modes and identity attribution where the source supports them. Unresolved origins or resources do not appear. No mandatory proxy in the data path.
The model
Read/write modes
Each source supplies the access mode it can classify. The map records relationships and limited metadata, not SQL text, parameters, payloads or secrets.
Read
An access classified as read by its source. Drawn in neutral.
Read / Write
An access classified as write or read/write by its source. Highlighted for review.
Unknown mode
When the source cannot classify an access as read or write, its mode stays unknown. This is separate from how firmly the access can be attributed to an agent.
Least-privilege drift
Compare permitted and observed access
Compare supplied grants with observations, using the agent’s linked identity where available. Review unexpected access, pending comparisons and unused grants within the collection scope.
- Unexpected access
Observed without a covering grant in the supplied data. Review the collection scope before treating the finding as a violation.
- Pending reconciliation
The identity link or access mode does not yet allow a decision. Marked pending rather than presented as a confirmed violation.
- Unused grants
Not observed since the sources began collecting. Before reducing a grant, check the active sources, the stored observations and whether the result is truncated. Grants for LDAP directories, Okta/Entra apps and Infisical projects remain inventory.
How it works
Compare grants and observations
This diagram illustrates the comparison of grants and observations across linked origins: matching access, differences and declared relationships.
Coverage
Resource coverage and origin attribution
Resource coverage and the certainty of origin attribution are different. Each relationship carries both tiers; missing signals are not treated as proof.
Resource coverage
The level of audit signal supported for a resource kind.
- Clean
- Supported native audit sources, including pgAudit and CloudTrail. The graph depends on the signals you configure and collect.
- Lossy
- Document and vector stores: partial signal, shown as partial — not rounded up.
- Opaque
- The current map treats Redis, SQLite, D1 and memcached as opaque. It does not infer per-access evidence from an inventory record.
- Mixed
- Cooperative or tool signals for other resource kinds, including MCP tools, HTTP APIs and shell.
Origin attribution
How firmly an access ties back to a specific agent.
- Firm
- A supported identity or cooperative signal resolves one agent or a dedicated non-human identity. Drawn solid; the map does not issue credentials.
- Approximate
- An identity is known, but the evidence does not resolve one agent. Marked approximate.
- Unknown
- The available signals do not support per-agent attribution. Opaque resources also use this tier when attribution is not firm.
Coverage and attribution are independent. A cooperative signal can firmly identify an agent even when resource coverage is opaque.
What’s real
Configured sources, audited queries
The graph compares supplied observations and grants. Reading the graph requires authorization and an audit entry; if the audit append fails, the query is refused.
- Opening the map is a permission-gated, audited action: each successful query appends an audit entry. It shows relationships, not contents.
- Missing or ambiguous signals limit attribution. Bounded query results can be truncated; check the collection scope and stored observations before changing a grant.
Access map — questions
Does it need a proxy or an inline agent?
No mandatory proxy is required. Configure supported audit and observation sources; the graph contains only the signals they supply. Configuring a source does not make every agent or resource visible.
Does the map store my SQL, payloads or secrets?
The graph stores relationships and limited metadata. Its metadata allowlist excludes SQL text, parameters, payloads and secrets. Read/write modes come from the source where supported.
What about resources the map treats as opaque?
The current map marks these resource kinds as opaque. An inventory record is not per-access evidence. Origin attribution depends separately on the identity signals received.
How does it tell read from read/write?
The source supplies its classified mode, where supported. The graph preserves that mode; an unclassified access remains unknown.
See your own access map
The access map and the identity inventory are part of Community. Filling the inventory from a directory is Business (Identity & Scale).