Naar inhoud

Product · Toegangskaart

Zie wat elke agent kan bereiken — lezen versus schrijven

Voor elke agent, sessie en identiteit toont de toegangskaart de resources die zij raakt, scheidt zij lezen van schrijven en markeert zij het moment waarop waargenomen toegang afwijkt van wat u heeft toegestaan. Passief ontdekt op basis van signalen die u al heeft — geen proxy in het datapad.

In het product

De kaart, uit de echte console

Een echte schermafbeelding van de Olivares-console, gevuld met voorbeelddata. Oorsprongen aan de linkerkant, de resources die zij raken aan de rechterkant, ingekleurd naar lezen, schrijven/RW, onbekend en bij benadering. Het openen van de kaart is een geprivilegieerde, geaudite handeling — zij toont relaties, nooit SQL, payloads of secrets.

Echte screenshot
Agents en sessies aan de linkerkant bereiken databases, object stores, API's en integraties aan de rechterkant. De kleur van de verbinding codeert lezen versus lezen/schrijven; één verbinding is gemarkeerd als een onverwachte schrijfactie — least-privilege drift.
Echte screenshot
Schakel over naar “toegestaan vs waargenomen” en de kaart vergelijkt uw toekenningen met de werkelijke toegang: wat werd waargenomen maar nooit toegestaan, en wat werd toegestaan maar nooit gebruikt.

Het model

Lezen, schrijven en het eerlijke onbekend

Olivares classificeert elke toegang bij de connector, vanuit de statement of het werkwoord zelf — het soort SQL, de HTTP-methode, de semantiek van de MCP-tool, de modus waarmee een bestand wordt geopend. Zij legt de relatie vast, nooit de statement: geen SQL-tekst, geen parameters, geen payloads, geen secrets.

Lezen

Een agent die een resource uitsluitend leest — een SELECT, een GET, een alleen-lezen tool-aanroep. Rustig getekend, in neutraal.

Lezen / Schrijven

Een agent die een resource kan wijzigen — een INSERT of UPDATE, een schrijvende tool, een muterende aanroep. De verbindingen die uw blast radius bepalen.

Onbekend · bij benadering

Waar een store geen audit per identiteit biedt, of het signaal zwak is, zegt Olivares dat ook — een gestippelde, gedempte verbinding — in plaats van zekerheid te verzinnen.

Least-privilege drift

Toegestaan versus waargenomen — de bevinding die ertoe doet

Drift is het gat tussen de toegang die u heeft verleend en de toegang die daadwerkelijk plaatsvindt. Olivares verzoent een waarneming die aan een agent wordt toegeschreven met de identiteit die deze agent werkelijk gebruikt, en brengt drie eerlijke toestanden naar boven.

  • Onverwachte toegang

    Waargenomen, maar nooit toegestaan. De bevinding met de hoogste prioriteit — toegang die plaatsvindt zonder dat er een grant achter zit.

  • In afwachting van verzoening

    Waargenomen zonder bijbehorende grant, maar de koppeling tussen agent en identiteit is nog niet opgelost. Naar boven gebracht als in afwachting, niet als een vaststaande overtreding — eerlijke onzekerheid, geen verzonnen alarm.

  • Ongebruikte grants

    Toegestaan, maar nooit waargenomen. Te ruime provisioning om aan te scherpen — least privilege, andersom.

Hoe het werkt

Van grants en waarnemingen naar één oordeel

Olivares neemt wat u heeft toegestaan en wat zij heeft waargenomen, verzoent ze over oorsprongen heen en geeft het resultaat weer: een match, een drift, of een relatie die zij alleen kan verklaren — nooit een die zij voorwendt te hebben gezien.

Diagram: toegestane grants en waargenomen toegang worden vergeleken; matches worden bevestigd, afwijkingen in oranje gemarkeerd als drift, en verklaarde maar nooit waargenomen relaties gestippeld getekend.
Toegestaan vs waargenomen, verzoend over oorsprongen heen. Gestippeld betekent verklaard, nooit waargenomen — eerlijk getekend, niet verborgen.

Dekking, eerlijk vermeld

Twee fidelity-assen — en we faken er geen van

Hoe goed een resource kan worden geaudit, en hoe stevig een toegang gekoppeld is aan een specifieke agent, zijn twee verschillende dingen. Olivares toont beide, per node, en degradeert netjes in plaats van te gokken.

Resource-dekking

Hoe volledig de resource zelf kan worden geaudit.

Schoon
Native audit — Postgres pgAudit, AWS CloudTrail en vergelijkbaar. Volledige fidelity per toegang.
Met verlies
Document- en vector stores: gedeeltelijk signaal, getoond als gedeeltelijk — niet naar boven afgerond.
Ondoorzichtig
Redis, SQLite, D1 en dergelijke bieden geen audit per identiteit. Gemarkeerd als ondoorzichtig, nooit stilzwijgend opgewaardeerd.

Toeschrijving van oorsprong

Hoe stevig een toegang terug te koppelen is aan een specifieke agent.

Stevig
Een toegewijde niet-menselijke identiteit — een SPIFFE/WIF-credential die per agent wordt aangemaakt. Solide getekend.
Bij benadering
Een gedeeld of gepoold account: de toegang is reëel, de agent is dubbelzinnig. Gestippeld getekend, gelabeld als bij benadering.
Onbekend
Helemaal geen identiteitssignaal. Gedempt — en nooit gepromoveerd tot een benoemde agent.

De twee assen zijn onafhankelijk: een toegang tot een ondoorzichtige store kan nog steeds stevig worden toegeschreven als een meewerkend signaal de agent heeft benoemd. Wat Olivares niet zal doen, is bij benadering of onbekend weergeven alsof het stevig was.

Wat echt is

Gebouwd en geverifieerd — en eerlijk over de randen

De toegangskaart heeft haar technische proof-of-concept-gate doorstaan en is de schrijver van de graaf. Twee eerlijke kanttekeningen:

  • Het openen van de kaart is een geprivilegieerde, geaudite handeling: elke query verzegelt een vermelding in het append-only auditlogboek. Zij is bedoeld voor defensieve beoordeling — relaties, geen inhoud.
  • De fidelity hangt af van uw bronnen. Sluit native audit (pgAudit, CloudTrail) en identiteiten per agent aan en de kaart is op haar scherpst; zonder die toont Olivares de tier met lagere fidelity in plaats van een zelfverzekerd verzinsel.

Toegangskaart — vragen

Is er een proxy of een inline agent nodig?

Nee. Olivares ontdekt toegang passief op basis van signalen die u al heeft — native database-audit, cloud-auditlogs, OpenTelemetry, eBPF en MCP-introspectie. Er is geen verplichte proxy in het datapad en niets om in de gaten te houden.

Slaat de kaart mijn SQL, payloads of secrets op?

Nee. Elke toegang wordt geclassificeerd vanuit het werkwoord — het soort SQL, de HTTP-methode, de semantiek van de tool — en vastgelegd als een relatie: oorsprong, resource, lezen of schrijven. De statement-tekst, parameters, payloads en secrets worden nooit vastgelegd.

Hoe zit het met stores zonder audit per identiteit, zoals Redis?

Die worden gemarkeerd als ondoorzichtige dekking. Olivares toont de relatie op de fidelity die zij daadwerkelijk kan bewijzen en labelt de beperking, in plaats van een toeschrijving per identiteit te verzinnen die de store niet kan ondersteunen.

Hoe onderscheidt het lezen van lezen/schrijven?

Vanuit de statement of het werkwoord zelf, geclassificeerd bij de connector — een SELECT versus een INSERT of UPDATE, een GET versus een muterende methode, een alleen-lezen versus een schrijvende tool-aanroep. De kleur van de verbinding volgt: lezen, schrijven/RW, of onbekend wanneer het signaal zwak is.

Bekijk uw eigen toegangskaart

Deploy Olivares op uw eigen infrastructuur, richt het op uw auditbronnen en krijg de lees/schrijf-kaart waar uw platform- en securityteams al om vragen.