La cabina di pilotaggio per gli agenti AI in esecuzione sulla tua infrastruttura

Gestisci già le dashboard di tutto il resto del parco: host, code, data store, percorso delle richieste. Poi compaiono una dozzina di agenti AI: copilot, server MCP, job pianificati, un’istanza di Claude Code che qualcuno ha collegato alla produzione, e non hai un unico posto che risponda alla prima domanda dell’operatore: cosa sta girando e cosa può effettivamente raggiungere ogni cosa?

È lo stesso schema della shadow infrastructure non gestita, solo che i carichi di lavoro detengono credenziali e agiscono per conto proprio. Tra le organizzazioni che hanno subito una violazione legata all’AI, circa il 97% era priva di adeguati controlli di accesso all’AI (IBM Cost of a Data Breach 2025, Ponemon). Il settore ha ormai un termine per la causa, agent sprawl, e Gartner prevede che più del 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027 (Gartner), spesso perché nessuno è riuscito a operarli in sicurezza una volta che si sono moltiplicati.

Cosa ottiene un operatore

Olivares AI è una piattaforma aperta e in self-hosting che gira dove girano i tuoi agenti. Li scopre, costruisce una mappa degli accessi in lettura/scrittura di ciò che ognuno tocca e ti dà i controlli per governare e auditare quell’accesso. Per un SRE o un sysadmin, cinque proprietà contano più dell’elenco delle funzionalità.

Passiva — non sul percorso delle richieste

La scoperta è costruita a partire dalla telemetria e dall’audit nativo delle sorgenti fuori banda. La vista su salute e affidabilità è un consumatore dell’event bus, non un prober che apre socket verso la tua infrastruttura: la liveness è dedotta dall’attività osservata, e un agente che smette di emettere è esso stesso un segnale. Poiché Olivares non è un proxy né un sidecar davanti ai tuoi agenti, un’interruzione di Olivares non può metterli fuori uso. Le uniche superfici che si trovano mai in linea sono i gate di attuazione opzionali che scegli di collegare, e quelli falliscono in modalità chiusa.

Un unico binario statico in self-hosting

Si distribuisce come singolo binario statico con la console web integrata: nessuna flotta di agenti da distribuire, nessun operator Kubernetes del control plane da accudire. Lo store è SQLite pure-Go (Postgres per il multi-tenant), quindi non c’è alcuna toolchain C da combattere. Installi un solo file, lo esegui come utente di servizio dedicato e hai la tua cabina di pilotaggio. Vedi installazione e self-host.

Il control plane gira all’interno del tuo perimetro e può funzionare air-gapped: i tuoi dati di governance e osservazione non escono mai. Una precisazione che gli operatori dovrebbero tenere a mente: questa non è AI offline. I modelli ospitati come Claude raggiungono comunque l’API del fornitore; air-gapped significa che i dati del tuo parco restano in casa, non che il modello giri in locale. Solo i modelli realmente eseguibili in self-hosting (vLLM, Ollama) funzionano completamente offline. Maggiori dettagli in sicurezza e architettura.

Ingest OTel-native

Il percorso di ingest fa riferimento alle convenzioni semantiche OpenTelemetry GenAI insieme a OCSF, ai formati SIEM e al W3C Trace Context, così la telemetria che già emetti è la telemetria che legge. Un confine onesto: Olivares correla il proprio registro di eventi governati tramite il trace_id W3C; non memorizza gli span OTel completi. Le durate e lo stato nella vista delle tracce sono finestre di eventi del registro, non dati di span ricostruiti. Gli span completi restano nel tuo collector OTLP, dove devono stare. Olivares ti dice chi ha toccato cosa e se era consentito: non sostituisce il tuo backend di tracing. (Vedi la pagina confronto per capire dove si colloca accanto a LiteLLM/Langfuse.)

Probe e salute, come qualsiasi servizio che gestisci

Il binario espone gli endpoint che il tuo orchestratore si aspetta già:

GET /livez     liveness  — il processo è attivo
GET /readyz    readiness — sta servendo (e non è uno standby a freddo)
GET /healthz   liveness esente da setup per gli scraper
GET /metrics   esposizione Prometheus

/readyz restituisce 503 quando lo store di backing è irraggiungibile invece di restare appeso, così un load balancer drena il nodo invece di mandarlo in un black hole. Inoltre, il modulo XXII monitora la salute, lo SLA e l’uptime degli agenti e dei server MCP stessi: cosa è sano, cosa è degradato e cosa dipende da cosa, ed emette findings di down/degradato/ ripristinato/violazione di SLA verso il tuo canale esistente (Slack, PagerDuty, SIEM). Produce il segnale; non cerca di essere il tuo notificatore.

Read-first, con un vero arresto esteso a tutto il parco

Olivares è detective per impostazione predefinita e deny-closed. Osserva e governa in modo ampio; non attua in modo ampio. Ma quando un agente va in tilt alle 3 del mattino, un operatore ha bisogno di una sola leva che funzioni senza cerimonie, perciò il kill-switch è reale e costruito per essere usato:

• L’attivazione è economica. Livello admin, una motivazione obbligatoria, un clic. Non c’è alcun gate di approvazione né step-up sull’attivazione: un arresto di emergenza che attende il quorum non è un arresto. L’ambito esteso a tutto il parco nega ogni superficie di attuazione governata per il tenant; l’ambito di agente ferma un singolo agente su ogni superficie su cui può essere nominato.
• La riattivazione no. Revocare un arresto richiede il dual-control (due persone distinte) ed è seguita da una revisione successiva obbligatoria che una terza persona, non coinvolta, deve firmare. «Il parco resta fermo» è lo stato sicuro.
• Fallisce in modalità chiusa. Ogni gate di attuazione consulta lo stato di arresto in tempo reale a ogni chiamata e nega in caso di errore di lettura: un arresto illeggibile non significa mai «via libera».

Sii onesto con te stesso riguardo all’ambito: l’arresto è ampio solo quanto i gate che hai collegato. Non può congelare una superficie in cui Olivares non ha alcun punto di aggancio. È il compromesso deliberato di un sistema read-first, ed è il motivo per cui la scoperta e la mappa vengono prima.

Cosa è — e cosa non è

• È una cabina di pilotaggio passiva e in self-hosting: scopri gli agenti, mappa il loro accesso in lettura/scrittura, monitora la loro salute e tieni un arresto esteso a tutto il parco a un clic di distanza.
• Non è un proxy in linea, un backend di tracing né un sistema che ricabla silenziosamente i tuoi agenti. L’attuazione è opt-in, on-demand e deny-closed: colleghi ogni punto di aggancio in modo deliberato.
• È pre-1.0 e open-core. Il catalogo elenca 23 moduli di capacità; all’incirca venti sono collegati oggi, gli altri sono in fase di progettazione o post-v1. Il riferimento dei moduli indica cosa è attivo.
• Non è certificata. Olivares è progettata in direzione di SOC 2, ISO/IEC 42001 e della normativa AI dell’UE: non possiede quelle certificazioni e non se ne attribuirà il merito. Vedi sicurezza per la postura onesta.
• La fedeltà è suddivisa in livelli e mostrata come tale. La copertura lettura/scrittura è clean sugli store con audit nativo, lossy su alcuni store documentali/vettoriali e unknown dove non può essere ricostruita passivamente (Redis, SQLite, D1); l’attribuzione per agente è firm solo quando il segnale lo supporta, approximate dietro un account condiviso. Nulla viene indovinato. Vedi fedeltà.

Da dove iniziare

• Mettilo in piedi: self-host, poi la guida rapida per un parco sintetico.
• Collega il tuo primo segnale: connetti una sorgente.
• Comprendi il modello: consentito vs osservato e la mappa degli accessi.
• Personas vicine all’operatore: platform engineering e responsabili della sicurezza.