Confronto
Dove si colloca Olivares — integriamo, non sostituiamo
Il tuo stack già traccia i prompt, sorveglia l’host e inventaria il tuo parco. Ciò a cui nessun singolo livello risponde è quale agente — legato a quale identità — abbia effettivamente letto o scritto quale risorsa. È questo il divario che Olivares colma, e lo fa consumando e arricchendo ciò che già esegui.
Il panorama
Cosa vede ciascun livello — e dove si ferma
Ciascuna di queste categorie svolge bene il proprio compito. Nessuna di esse, da sola, attribuisce una reale lettura o scrittura sulla tua infrastruttura a uno specifico agente AI. Olivares è la correlazione agent-aware che si colloca tra di esse.
Osservabilità degli LLM
es. LiteLLM, Langfuse, Phoenix
- Vede
- Prompt, trace, latenza e costo in token — il ragionamento del modello, a livello applicativo.
- Dove si ferma
- Non l’host: non quale database, store o API concreto l’agente abbia effettivamente letto o scritto.
Host e runtime
es. strumenti eBPF — Falco, Tetragon
- Vede
- Syscall, processi e traffico di rete in uscita sull’host, in tempo reale.
- Dove si ferma
- Nessuna attribuzione agent-aware: un processo e un container ID, non un agente nominale e un’identità.
Torri di controllo per l’AI
es. Datadog AI Agents Console, Microsoft Agent 365, ServiceNow AI Control Tower
- Vede
- Inventario del patrimonio IT, postura e workflow tra gli strumenti che la tua organizzazione già utilizza.
- Dove si ferma
- Valgono solo quanto l’inventario che ricevono — hanno bisogno di una fonte di verità di base al di sotto.
Dove si colloca Olivares
Il livello read/write agent-aware
Olivares risponde alla domanda che gli altri lasciano aperta, e mantiene la risposta all’interno del tuo perimetro.
Chi ha letto o scritto cosa
Correla i segnali che già emetti in un’unica relazione: questo agente, legato a questa identità, legge o scrive questa risorsa — con deriva dal principio del least-privilege quando l’accesso osservato diverge da ciò che è stato autorizzato.
Fusione di segnali reali
Audit nativo del database, log di audit del cloud, OpenTelemetry, eBPF e introspezione MCP vengono riconciliati in un unico grafo — la verità dell’host fusa con la semantica delle chiamate agli strumenti, attribuita a un agente.
Self-hosted e neutrale rispetto al fornitore
Le relazioni di accesso e il registro di governance restano sulla tua infrastruttura. Nessun lock-in del fornitore: Olivares non contatta l’esterno in modo obbligatorio.
Integrare, non competere
Rafforza gli strumenti che utilizzi
Olivares è progettato per affiancarsi al tuo stack e renderlo migliore, non per chiederti di smontare nulla.
Sopra il tuo proxy e le tue trace
Consuma OpenTelemetry e opera al di sopra di un proxy LLM e del tuo tracing — aggiungendo la mappa read/write a livello di infrastruttura che non sono mai stati pensati per produrre.
Fusione con la verità dell’host
Tratta i flussi eBPF e di audit nativo come segnali, correlando l’attività grezza dell’host con la semantica delle chiamate agli strumenti, così che un accesso risalga a un agente, non a un semplice processo.
Arricchisce la tua torre di controllo
Invia inventario in sola lettura, postura e risultati firmati e a prova di manomissione (in formati aperti come OCSF) verso il tuo SIEM, ITSM e la tua torre di controllo per l’AI — alimentandoli con la verità di base, senza sostituirli.
Cos’è Olivares — e cosa non è
Cos’è
- La verità di base agent-aware: quale agente e quale identità hanno toccato quale risorsa, lettura o scrittura, con il drift.
- Self-hosted, neutrale rispetto al fornitore e open-core sotto AGPL-3.0 — il prodotto completo, sulla tua infrastruttura.
- Un livello che consuma i tuoi segnali esistenti e alimenta i tuoi sistemi esistenti.
Cosa non è
- Un sostituto del tuo tracing LLM, del tuo proxy, dei tuoi strumenti eBPF o della tua torre di controllo — consuma quei segnali e alimenta quei sistemi.
- Un fossato difensivo. Il livello di correlazione agent-aware è una giunzione di integrazione, non una categoria che pensiamo di dominare.
- Una certificazione, né un gate inline per impostazione predefinita — Olivares è read-first e detective per impostazione predefinita; l’enforcement è opt-in e governato.
Dove si colloca — domande
Olivares sostituisce Langfuse o il nostro tracing LLM?
No. L’osservabilità degli LLM cattura il ragionamento del modello — prompt, trace, costo in token — a livello applicativo. Olivares opera un livello più in basso, sull’infrastruttura: quale risorsa un agente abbia effettivamente letto o scritto. Consuma OpenTelemetry, quindi completa il tuo tracing invece di competere con esso.
Sostituisce il nostro SIEM o la nostra torre di controllo per l’AI?
No. Le torri di controllo e i SIEM valgono solo quanto l’inventario e i risultati che ricevono. Olivares è una fonte di verità di base che li arricchisce — invia inventario in sola lettura, postura e risultati firmati verso Datadog, ServiceNow, Microsoft e il tuo SIEM in formati aperti.
Gli strumenti runtime/eBPF non lo mostrano già?
Gli strumenti eBPF vedono syscall, processi e traffico in uscita sull’host, ma li attribuiscono a un processo e a un container — non a un agente nominale e a un’identità. Olivares fonde quella verità dell’host con la semantica delle chiamate agli strumenti e con l’identità per ciascun agente, così che un accesso risalga a uno specifico agente.
Perché deve essere self-hosted?
Perché le relazioni di accesso e il registro di governance sono dati sensibili. Se eseguito in self-hosting, restano all’interno del tuo perimetro; Olivares non contatta l’esterno in modo obbligatorio e può funzionare in modalità completamente air-gapped. L’air-gap riguarda Olivares stesso — la sua mappa degli accessi e il suo registro di governance; gli agenti che usano modelli in hosting raggiungono comunque l’API del proprio fornitore.
Aggiungi il livello che manca al tuo stack
Distribuisci Olivares sulla tua infrastruttura, puntalo verso i segnali che già emetti e ottieni la mappa read/write agent-aware — senza sostituire nulla.