Product · Access map
See what every agent can reach — read versus write
For every agent, session and identity, the access map shows the resources it touches, separates reads from writes, and flags the moment observed access diverges from what you permitted. Discovered passively from signals you already have — no proxy in the data path.
In the product
The map, from the actual console
A genuine screenshot of the Olivares console, populated with example data. Origins on the left, the resources they touch on the right, coloured by read, write/RW, unknown and approximate. Opening the map is a privileged, audited action — it shows relationships, never SQL, payloads or secrets.
The model
Read, write, and the honest unknown
Olivares classifies each access at the connector, from the statement or verb itself — the SQL kind, the HTTP method, the MCP tool’s semantics, the file open mode. It records the relationship, never the statement: no SQL text, no parameters, no payloads, no secrets.
Read
An agent that only reads a resource — a SELECT, a GET, a read-only tool call. Drawn calm, in neutral.
Read / Write
An agent that can modify a resource — an INSERT or UPDATE, a writing tool, a mutating call. The edges that decide your blast radius.
Unknown · approximate
Where a store offers no per-identity audit, or the signal is weak, Olivares says so — a dotted, de-emphasised edge — instead of inventing certainty.
Least-privilege drift
Permitted versus observed — the finding that matters
Drift is the gap between the access you granted and the access actually happening. Olivares reconciles an observation attributed to an agent against the identity that agent really uses, and surfaces three honest states.
- Unexpected access
Observed, but never permitted. The highest-priority finding — access that is happening with no grant behind it.
- Pending reconciliation
Observed without a matching grant, but the agent-to-identity link is still unresolved. Surfaced as pending, not as a firm violation — honest uncertainty, not a fabricated alarm.
- Unused grants
Permitted, but never observed. Over-provisioning to tighten — least privilege, the other way round.
How it works
From grants and observations to a single verdict
Olivares takes what you permitted and what it observed, reconciles them across origins, and renders the result: a match, a drift, or a relationship it can only declare — never one it pretends to have seen.
Coverage, stated honestly
Two fidelity axes — and we fake neither
How well a resource can be audited, and how firmly an access ties to a specific agent, are two different things. Olivares shows both, per node, and degrades gracefully instead of guessing.
Resource coverage
How completely the resource itself can be audited.
- Clean
- Native audit — Postgres pgAudit, AWS CloudTrail and similar. Full per-access fidelity.
- Lossy
- Document and vector stores: partial signal, shown as partial — not rounded up.
- Opaque
- Redis, SQLite, D1 and the like offer no per-identity audit. Marked opaque, never silently upgraded.
Origin attribution
How firmly an access ties back to a specific agent.
- Firm
- A dedicated non-human identity — a SPIFFE/WIF credential minted per agent. Drawn solid.
- Approximate
- A shared or pooled account: the access is real, the agent is ambiguous. Drawn dotted, labelled approximate.
- Unknown
- No identity signal at all. De-emphasised — and never promoted to a named agent.
The two axes are independent: an access to an opaque store can still be firmly attributed if a cooperating signal named the agent. What Olivares will not do is render approximate or unknown as if it were firm.
What’s real
Built and verified — and honest about the edges
The access map has passed its technical proof-of-concept gate and is the writer of the graph. Two honest notes:
- Opening the map is a privileged, audited action: every query seals an entry in the append-only ledger. It is for defensive review — relationships, not contents.
- Fidelity depends on your sources. Wire native audit (pgAudit, CloudTrail) and per-agent identities and the map is at its sharpest; without them, Olivares shows the lower-fidelity tier rather than a confident fiction.
Access map — questions
Does it need a proxy or an inline agent?
No. Olivares discovers access passively from signals you already have — native database audit, cloud audit logs, OpenTelemetry, eBPF and MCP introspection. There is no mandatory proxy in the data path and nothing to babysit.
Does the map store my SQL, payloads or secrets?
No. Each access is classified from the verb — the SQL kind, the HTTP method, the tool’s semantics — and recorded as a relationship: origin, resource, read or write. The statement text, parameters, payloads and secrets are never captured.
What about stores with no per-identity audit, like Redis?
They are marked as opaque coverage. Olivares shows the relationship at the fidelity it can actually prove and labels the limit, rather than inventing a per-identity attribution the store cannot support.
How does it tell read from read/write?
From the statement or verb itself, classified at the connector — a SELECT versus an INSERT or UPDATE, a GET versus a mutating method, a read-only versus a writing tool call. Edge colour follows: read, write/RW, or unknown when the signal is weak.
See your own access map
Deploy Olivares on your own infrastructure, point it at your audit sources, and get the read/write map your platform and security teams have been asking for.