Trasparenza e limiti

Una piattaforma che governa gli agenti AI sulla tua infrastruttura e un prodotto di sicurezza. Se esagera ciò che copre, offre una falsa sensazione di sicurezza — che è peggio di nessuno strumento. Perciò questa pagina e il contratto esplicito: ciò che funziona oggi, ciò che è in fase di progettazione e ciò che è fuori ambito di proposito. Il resto della documentazione si attiene a questo. Dove il prodotto non copre ancora qualcosa, la pagina lo dichiara anziché suggerire il contrario.

Olivares AI e pre-1.0 e open-core. Tratta la profondità a livello di modulo come lavoro in corso salvo che una pagina non dichiari diversamente.

Cosa funziona oggi

• Un singolo binario si avvia con un grafo degli accessi popolato. Il binario del piano di controllo compila in un singolo artefatto statico con la web UI incorporata. L’avvio contro l’estate demo sintetico e il percorso discover -> grafo R/RW -> drift permesso-vs-osservato -> inventario sono testati end-to-end dalla suite di test. Il quickstart riproduce quel percorso.
• Il primo avvio e senza credenziali. Un’installazione nuova non ha credenziali predefinite. Al primo avvio, senza utenti presenti, il motore genera un token di setup unico e monouso e lo stampa su stdout (mai nei log); lo scambi per creare il primo amministratore.
• L’API REST e il registro di audit sono reali. La superficie pubblica e descritta dal contratto OpenAPI 3.1 del prodotto stesso. Il registro di audit e append-only e hash-chained, con checkpoint firmati, e può essere esportato in formati SIEM per la ri-verifica offline.
• La firma dei rilasci è costruita e si verifica offline — le evidenze si pubblicano con la prima release pubblica. Ogni rilascio taggato porta firme cosign, provenienza SLSA e SBOM (SPDX e CycloneDX). Tutto questo può essere verificato senza accesso alla rete. La firma basata su chiave (non-OIDC) è supportata per pipeline di build air-gapped, e un bundle air-gap viene distribuito per installazioni senza uscita.

Cosa e in fase di progettazione o pre-1.0

Il catalogo comprende 29 moduli; tutti sono cablati in un’installazione standard oggi. Vedi il riferimento dei moduli per lo stato per modulo.

La fedeltà della mappa R/RW è a livelli, per progetto

La fedeltà dipende da ciò che la sorgente può dimostrare, e la mappa degli accessi lo mostra onestamente anziché fingere certezza. Vedi fedeltà per il modello completo.

• Copertura e clean sui datastore con audit nativo (SQL, object storage, data warehouse/data lake), lossy su document store e vector store dove gli archi esistono ma sono approssimativi, e opaque dove non c’e alcun segnale passivo di lettura/scrittura (ad esempio Redis, SQLite, D1). Dove la distinzione lettura vs scrittura non può essere determinata, l’arco viene marcato unknown.
• Attribuzione e firm quando una sorgente porta identità per agente, e si riduce a approximate quando un account di servizio condiviso la nasconde. Qualsiasi cosa non risolta resta approximate — mai promossa silenziosamente a un agente fabbricato.

Sorgenti: osservatori host cablati; alcuni connettori caricati su richiesta

La composition root registra gli osservatori R/RW a livello host nel percorso serve standard, configurabili tramite la configurazione delle sorgenti. Diversi connettori sorgente sono costruiti ma non ancora cablati nel serve standard — ad esempio le sorgenti di documenti di conoscenza, che vengono caricate su richiesta dalle richieste di ingestione anziché funzionare come osservatori permanenti. La guida connect-a-source e il riferimento dei moduli indicano quale e quale.

Il default è un binario; il bus distribuito e opt-in

L’installazione predefinita funziona come un singolo binario con un bus eventi in-process — backpressure bloccante, nessuna perdita locale. Un bridge NATS distribuito è costruito e cablato per lo scale-out HA, opt-in tramite configurazione del bus; un bus mal configurato fallisce l’avvio anziché partizionare silenziosamente. La consegna cross-nodo attraverso il bridge e documentata onestamente come at-most-once (la cattura in-process e il confine di durabilita); le perdite sono contate nelle metriche, mai silenziose.

L’attuazione governata ha tre stati onesti

La piattaforma osserva e governa ampiamente; non attua ampiamente. Leggi permesso vs osservato per capire perché quella linea è importante. L’attuazione si divide in tre stati:

• Live nel binario predefinito, nessuna configurazione: enforcement del budget FinOps (un budget al tetto nega la spesa — in-process, sempre cablato), invio notifiche una volta configurata una destinazione, segnalazioni investigative di sicurezza, e il sandbox runner sintetico in-process.
• On-demand — backend costruito e cablato, ma deny-closed o degradato finche un operatore non lo configura: deploy apply/retire (un 503 finche un executor non è configurato), orchestration fire e voice dispatch (deny-closed finche un dispatcher non è configurato), il runtime sandbox/red-team isolato (sintetico finche non configurato), e l’esecuzione del modello (un 503 finche una credenziale di inferenza non è configurata).
• Seam — un’interfaccia dichiarata, deny-closed, senza backend ancora.

L’air-gap si applica al piano di controllo, non all’inferenza di Claude

Questo è il punto più importante da chiarire. Il piano di controllo — governance e osservazione — funziona completamente self-hosted e può essere air-gapped: singolo nodo, rilascio firmato offline, bundle air-gap.

Claude non è self-hostabile. Anthropic non pubblica i pesi, quindi qualsiasi inferenza Claude raggiunge l’API di Anthropic, direttamente o tramite Bedrock / Vertex / Foundry. In Olivares AI quei punti di inferenza sono fail-closed: senza credenziale di inferenza il giudice LLM resta saltato e gli embedding ripiegano su un embedder locale a zero uscita. “Air-gapped” qui significa che il tuo piano di governance e osservazione e i suoi dati restano all’interno del tuo perimetro — non significa che Claude funziona offline. Solo i modelli che self-hosti genuinamente (ad esempio tramite vLLM o Ollama sotto il modulo di gestione modelli) possono funzionare air-gapped; i modelli frontier intermediati non possono. Vedi connect Claude Code e sicurezza.

Non tutte le rotte dei moduli sono nel contratto API pubblico

Alcuni endpoint dei moduli (ad esempio il grafo della mappa degli accessi e il drift) sono raggiungibili ma sono deliberatamente non parte del documento OpenAPI servito; i loro contratti a livello di campo risiedono nelle interfacce tipizzate del prodotto. I riferimenti CLI e configurazione coprono la superficie operativa; il contratto OpenAPI e la superficie REST principale, non l’intero prodotto.

Non certificato

Olivares AI è progettato verso SOC 2, ISO 27001 e l’EU AI Act — non è certificato rispetto a nessuno di essi. Vedi conformita per cosa significa “progettato verso” e quali evidenze produce la piattaforma.

Cosa il prodotto deliberatamente non fa

• Nessuna funzionalità offensiva. Questo non è un framework di command-and-control e non scansiona le credenziali di altri. La mappa degli accessi e ricognizione per i difensori per governare il proprio estate — visualizzarla e un’azione privilegiata, circoscritta al tenant e completamente registrata nell’audit. La linea difensiva è intenzionale.
• Nessun forwarder nativo Splunk S2S. L’inoltro verso Splunk e una postura documentata (puntare un Universal Forwarder a un file che il piano di controllo aggiorna, o inviare tramite Splunk HEC), non un emettitore nativo Splunk-to-Splunk.
• Nessun webhook in uscita nel contratto REST. Il documento OpenAPI non definisce webhooks. La consegna firmata in uscita esiste come destinazione di notifica interna, e l’endpoint SCIM Security-Event-Token in ingresso e un ricevitore — nessuno dei due e un webhook OpenAPI.
• Nessun fine-tuning prima della v1. Il fine-tuning dei modelli (il modulo di gestione modelli) e post-v1. La sua assenza è una decisione, non una lacuna.

Una nota sull’export dell’audit

L’export del registro via CLI supporta cef, syslog e otlp. Il percorso push degli eventi verso un SIEM produce un dialetto più ampio (incluso OCSF e LEEF) quando un sink è configurato. L’export pull ha la forma giusta per l’archiviazione WORM e la ri-verifica offline.

Se trovi un comando che non si comporta come documentato, e un bug nella documentazione o nel prodotto — per favore segnalalo. Questa pagina e l’ancora di fiducia; tutto il resto vi si sottomette.