Porta i tuoi agenti AI nella piattaforma che già gestisci

Il problema: gli agenti arrivano più velocemente di quanto la tua piattaforma riesca a modellarli

Gestisci una piattaforma interna per sviluppatori. Hai un catalogo di servizi, un IdP, l’infrastruttura come codice, la riconciliazione GitOps e un portale che gli ingegneri aprono davvero. Quella macchina esiste proprio affinché nulla di importante venga eseguito senza essere modellato — nessun servizio senza un proprietario, nessun accesso senza una policy, nessuna modifica senza un diff.

Gli agenti AI infrangono questo contratto. Una sessione di Claude Code, un MCP server, un agente autonomo pianificato — ognuno può leggere e scrivere sugli stessi database, object store e API che i tuoi servizi toccano, ma compaiono al di fuori del catalogo. Vengono avviati dagli sviluppatori, non provisionati da te. Si autenticano come service account condivisi tanto spesso quanto no. E gli hyperscaler hanno peggiorato la situazione rendendo l’identità degli agenti una primitiva GA in tre registri reciprocamente incompatibili.

Il segnale di mercato è netto. Gartner prevede che oltre il 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027 (Gartner, comunicato stampa), e lo studio IBM Cost of a Data Breach 2025 (Ponemon) ha rilevato che, tra le organizzazioni che hanno subìto una violazione legata all’AI, circa il 97% non disponeva di controlli di accesso AI adeguati. Un risultato preliminare del MIT nell’ambito del progetto NANDA — the GenAI Divide, via Fortune, agosto 2025, non ancora sottoposto a revisione paritaria — riporta che circa il 95% dei progetti pilota di GenAI non ha mostrato alcun impatto misurabile sul conto economico, e che gli strumenti acquistati esternamente hanno avuto successo circa il doppio delle volte rispetto agli sviluppi interni. Letto alla luce del lavoro di un team di piattaforma, questo punta nella stessa direzione: la proliferazione di agenti non governati e non modellati è il punto in cui il valore si disperde e il rischio si infiltra.

Come Olivares AI si integra nella piattaforma che già gestisci

Olivares AI è una piattaforma aperta e self-hostable che scopre gli agenti AI sulla tua infrastruttura, mappa cosa ciascuno può leggere e scrivere, e governa e verifica tale accesso. L’obiettivo di progettazione per i team di piattaforma non è un’altra console — è rendere gli agenti cittadini di prima classe della piattaforma che già gestisci.

Agenti come entità di catalogo di prima classe

La piattaforma scopre agenti, MCP server, sessioni e identità non umane, e costruisce una mappa degli accessi: un grafo di ogni arco agente → database / store / API, ognuno contrassegnato come lettura (R) o lettura-scrittura (RW). Quel grafo è la voce di catalogo che un agente avrebbe dovuto avere fin dall’inizio — cosa è, cosa tocca e se ciò che tocca corrisponde a ciò che gli è consentito toccare.

Quest’ultima distinzione è il cuore del prodotto. Gli archi sono classificati come consentiti vs osservati, così che la deriva rispetto al least-privilege sia visibile anziché presunta. Consulta la mappa degli accessi e la pagina concettuale su consentito vs osservato.

L’avvertenza sull’onestà conta qui e la teniamo allo scoperto: la fedeltà R/RW è a livelli. La copertura è clean sulle sorgenti con audit nativo, lossy dove gli archi sono grossolani e opaque dove non esiste alcun segnale passivo di lettura/scrittura; l’attribuzione è firm quando una sorgente porta un’identità per agente e approximate quando un account condiviso la nasconde. La mappa mostra il livello anziché simulare certezza — consulta fedeltà.

Gestione come codice: un provider Terraform/OpenTofu

Per un team di piattaforma, la config-as-code è un requisito minimo. Olivares AI fornisce terraform-provider-olivares, che gestisce il tuo control plane self-hosted in modo dichiarativo rispetto alla sua API stabile. Il provider espone risorse e data source per agenti, policy, distribuzioni, binding di identità degli agenti, budget, configurazione delle capability e route di notifica, con import, plan/apply e gestione della deriva — così che gli agenti che governi vengano riconciliati nello stesso modo in cui ArgoCD o Flux già riconciliano il resto del tuo patrimonio.

Un dettaglio sulla licenza da precisare, perché differisce dall’SDK dei connettori: il provider è AGPL-3.0-only, non Apache-2.0.

resource "olivares_agent" "billing_assistant" {
  name = "billing-assistant"
  # ...managed alongside the rest of your platform, as code
}

resource "olivares_policy" "billing_least_privilege" {
  # least-privilege intent, versioned in Git, reconciled like everything else
}

L’HCL qui sopra è illustrativo della forma, non un contratto da copia-incolla — genera rispetto allo schema pubblicato dal provider stesso. Il prodotto è pre-1.0: considera la copertura delle risorse come allineata alla superficie dell’API, e verifica il riferimento dei moduli per sapere cosa è cablato oggi.

Integrazione con il tuo IdP — federazione, non sostituzione

Olivares AI non è un identity provider e non cerca di esserlo. Federa l’identità degli agenti in sola lettura: legge i roster da Microsoft Entra Agent ID, AWS AgentCore Identity e Google Agent Identity, e li riconcilia con un roster SPIFFE/WIF così che ogni arco nella mappa degli accessi porti un’attribuzione certa o approssimativa. Le identità dedicate di agente e di workload si risolvono in un’attribuzione certa; i principal di tipo blueprint, i credential provider e gli agenti di tipo service-account restano approssimativi anziché essere promossi a un’identità fabbricata. Non emette credenziali e non scrive nulla in quei registri — la federazione è rigorosamente in sola lettura.

Espone inoltre una classe di deriva utile per la sicurezza della piattaforma: credenziali statiche di lunga durata rilevate sulle identità degli agenti, in linea con le linee guida Five Eyes 2026 verso credenziali di breve durata. L’autenticazione client OAuth basata su SVID (il lavoro draft-ietf-oauth-spiffe-client-auth) è implementata come design-toward — non c’è alcuna dichiarazione di conformità finché un authorization server non pubblica il flusso corrispondente. Consulta identità e federazione.

Un’integrazione nel portale: Backstage, read-first

Se i tuoi sviluppatori vivono in Backstage, anche l’inventario degli agenti dovrebbe vivere lì. L’obiettivo di progettazione è un plugin nativo, read-first — inventario, sessioni live e la mappa degli accessi R/RW renderizzati all’interno del portale e autenticati rispetto al control plane — non un iframe e non una seconda dashboard. Il read-first è deliberato: è coerente con l’impostazione del prodotto (più sotto) e mantiene a basso rischio l’integrazione nel portale.

CLI-first, con un’API stabile sotto

L’intera piattaforma è un unico binario Go, controlplane, che si avvia con un grafo degli accessi popolato; la console web è incorporata nella stessa origine dell’API. Tutto ciò che puoi fare nella UI puoi guidarlo dalla CLI o dalla superficie OpenAPI 3.1, che è ciò su cui il provider Terraform, un plugin Backstage e la tua automazione si basano tutti. Inizia dal riferimento di configurazione, dal workflow CLI e dalla superficie di governance MCP.

Cos’è — e cosa non è

Questo è un prodotto orientato alla sicurezza, quindi manteniamo una linea netta su ciò che dichiara.

• Read-first e deny-closed. Osserva e governa in modo ampio; non attua in modo ampio. La maggior parte dell’attuazione è live-on-demand o una giunzione dichiarata e deny-closed — un apply di distribuzione restituisce 503 finché non provisioni un executor, non un no-op silenzioso. Consulta consentito vs osservato e la pagina onestà e limiti.
• Pre-1.0, open-core. Il catalogo conta 23 moduli; circa 20 sono cablati in un’installazione standard. Nulla qui implica che tutti e 23 siano pienamente attivi — il riferimento dei moduli indica lo stato di ciascun modulo.
• Air-gap riguarda il control plane, non Claude. Il piano di governance e osservazione viene eseguito interamente in self-hosting e può essere air-gapped. L’inferenza di Claude non è mai self-hosted — Anthropic non pubblica alcun peso, quindi qualsiasi chiamata a Claude raggiunge un’API. Solo i modelli che effettivamente self-hosti (vLLM, Ollama) vengono eseguiti offline. Consulta sicurezza.
• Non certificato. È progettato verso EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2 e altri, con evidenze di audit tratte da un registro append-only e con hash concatenati. Non è certificato SOC 2 / ISO / EU AI Act. Consulta compliance.
• Complementa le tue control tower; non pretende di sostituirle. La federazione dell’identità e l’export della postura sono in sola lettura per progettazione.

Se vuoi prima il quadro architetturale, leggi l’architettura; se vuoi sapere dove ci collochiamo rispetto a gateway, observability e agent control tower, consulta il confronto. E se stai valutando la licenza e il confine open-core, open source è la versione onesta.

Profili correlati: responsabili della sicurezza, SRE e sysadmin e istruzione superiore.