La strategia "Bring Your Own Agent" su Red Hat AI, edizione OpenClaw

Il mondo dell’Agentic AI è complesso. I team si affidano a LangChain, LlamaIndex, CrewAI, o ad AutoGen oppure creano soluzioni personalizzate da zero. Bene. È così che dovrebbe essere durante la fase creativa. Tuttavia, una volta che un agente lascia il laptop di uno sviluppatore e inizia a comunicare con i dati nella fase di produzione, a chiamare interfacce di programmazione di applicazioni (API) esterne o a essere eseguito su un'infrastruttura condivisa, la libertà senza protezioni smette di essere una caratteristica e diventa una responsabilità.

Abbiamo osservato l’andamento del settore: le API dei modelli (come le sessioni di chat), le API degli agenti (come gli assistenti e, successivamente, l'API delle risposte di OpenAI), l'era dei framework e ora l'era degli strumenti e degli agenti di codifica. Lo strato in superficie è in continua evoluzione. Sta diventando sostituibile. Ciò che non cambia è la differenza tra l’efficienza sul laptop dello sviluppatore e l’efficienza in produzione, nel rispetto delle misure di sicurezza, della scalabilità e degli audit trail.

La nostra strategia AgentOps si basa su un principio fondamentale: Bring Your Own Agent (BYOA). La piattaforma è indipendente dal framework. L'importante è che l'agente disponga di un'identità, funzioni con privilegi minimi, venga monitorato, superi i controlli di sicurezza e possa essere verificato a posteriori. La piattaforma offre sicurezza, governance, osservabilità e gestione del ciclo di vita. L'agente rimane tuo.

Cosa offre Red Hat AI

Questa serie mostra in anteprima il funzionamento pratico di BYOA, illustrando ciò che è ora disponibile e ciò che svilupperemo in futuro.

Prendiamo OpenClaw, un assistente IA personale che indirizza le interazioni degli agenti tra i canali (WhatsApp, Telegram, Slack, Discord e altri) tramite un WebSocket Gateway centrale e lo rendiamo operativo su Red Hat AI. Non lo stiamo inserendo in un framework proprietario, ma nell'infrastruttura della piattaforma. OpenClaw è solo un esempio: questo approccio funziona per qualsiasi ambiente di runtime per agenti.

Per impostazione predefinita, OpenClaw spesso non utilizza il sandboxing. Non applica il controllo degli accessi basato sui ruoli (RBAC), non tiene traccia delle chiamate agli strumenti e non blocca l'accesso ai servizi esterni. Red Hat AI aggiunge ciascuno di questi livelli utilizzando le funzionalità native di Red Hat OpenShift e Red Hat OpenShift AI, senza intervenire sul codice dell'agente. Il resto del post esamina ciascuno di questi livelli.

Riadattare il concetto da cloud native ad agent native

Non creiamo un'infrastruttura di agenti da zero. Con Red Hat AI stiamo riadattando gli strumenti e i modelli di deployment già presenti in OpenShift e li stiamo estendendo ai carichi di lavoro degli agenti.

Gli agenti necessitano di isolamento: i container sandbox di OpenShift (basati sul progetto Kata Containers e un prodotto a più livelli di GA) e l'imminente integrazione agent-sandbox offrono l'esecuzione isolata dal kernel per ogni sessione dell'agente. I dati dell'host e degli altri agenti sono protetti dagli agenti compromessi.

Gli agenti necessitano di identità: token dell'account di servizio con ambito, con SPIFFE/SPIRE per l'identità del carico di lavoro crittografico. Nessuna chiave hardcoded: la piattaforma verificherà l'agente e inserirà token dell'account di servizio specifici e di breve durata a livello di piattaforma. Questo approccio è pianificato con l'integrazione di Kagenti per il ciclo di vita degli agenti all’interno di Red Hat AI. 

Gli agenti necessitano di un’architettura multitenancy: isolamento dello spazio dei nomi, NetworkPolicy, ResourceQuota, e verifica del rispetto dei limiti durante i test contro gli attacchi avversari.

Gli agenti necessitano di policy guardrail su più livelli: policy OPA/Gatekeeper e Kyverno a livello di Kubernetes; il Gateway di Model Context Protocol (MCP) per l'autorizzazione a livello di strumento; Guardrails Orchestrator e NeMo Guardrails al limite dell'inferenza del modello (maggiori informazioni nella sezione successiva).

Rendi gli agenti più sicuri e pronti per la produzione

Per molti team aziendali, la sicurezza sta diventando il principale ostacolo al rilascio in produzione di agenti e modelli. Non le prestazioni. Non il costo. La fiducia. Le aziende devono avere la certezza che la loro IA rimanga conforme alle normative e protegga il proprio marchio da rischi legali e di reputazione, soprattutto quando utilizzata da utenti esterni.

Il portafoglio Red Hat AI offre un approccio alla sicurezza che copre l'intero ciclo di vita (dal rilevamento al test, fino alla mitigazione dei rischi prima del passaggio in produzione), e protegge dalle minacce che emergono in fase di runtime.

Prima che un agente diventi operativo: Garak (pianificato nell'ambito di Red Hat AI) offre una scansione delle vulnerabilità agli attacchi avversari individuando jailbreak, prompt injection e altri vettori di attacco a livello di modello. L'integrazione è pianificata tramite l'operatore TrustyAI e può essere utilizzata tramite EvalHub (un piano di controllo per la valutazione) e Kubeflow Pipelines, consentendo scansioni di attacchi avversari in ambito CI/CD prima del passaggio alla fase successiva.

Al runtime (guardrail al limite dell'inferenza): TrustyAI Guardrails Orchestrator (generalmente disponibile a partire da OpenShift AI 3.0) analizza gli input e gli output del modello. NeMo Guardrails (anteprima tecnica) aggiunge canali di conversazione programmabili. Entrambi operano al limite dell'inferenza, intercettando le singole chiamate dei modelli linguistici di grandi dimensioni (LLM) per garantire la sicurezza prima che una risposta raggiunga l'agente. Una visualizzazione pianificata del rischio del modello nel catalogo dei modelli metterà in evidenza questi segnali di sicurezza insieme ai metadati del modello, in modo che i team possano tenere conto del rischio dello scenario di utilizzo prima di scegliere un modello.

Osservabilità, tracciamento e valutazione

Gli agenti sono stocastici. Non è possibile eseguirne il debug o considerarli attendibili in produzione senza tracce di esecuzione.

Red Hat AI offre le basi per l'osservabilità degli agenti, a partire dal supporto proprietario per MLflow, attualmente disponibile in anteprima per gli sviluppatori e la cui disponibilità generale è prevista in una prossima release. 

MLflow Tracing acquisisce prompt, fasi di ragionamento, chiamate agli strumenti, richieste API LLM e i costi dei token. Tutte le tracce sono compatibili con OpenTelemetry, quindi qualsiasi sink compatibile con OTEL può essere integrato. Oltre al tracciamento, le funzionalità di MLflow per il punteggio e la valutazione possono essere utilizzate per valutare la qualità degli agenti nel tempo. Questi flussi di lavoro sono pianificati per essere richiamati tramite Eval Hub, un piano di controllo di valutazione che fa parte di OpenShift AI.  

Gestione scalabile delle chiamate degli strumenti

Gli agenti chiamano gli strumenti. Il problema è la gestione di queste chiamate.

Il gateway MCP (realizzato con il team di rete di OpenShift e basato su Envoy), attualmente disponibile in anteprima per gli sviluppatori, si trova davanti a tutti i server MCP come un singolo endpoint sicuro. Aggiunge il filtraggio degli strumenti basato sull'identità, in modo che gli agenti vedano solo gli strumenti autorizzati, lo scambio di token OAuth2 per l’accesso limitato a livello di backend e la gestione delle credenziali, in modo che le chiamate sensibili agli strumenti passino attraverso l'autorizzazione corretta. La piattaforma impone l'accesso. L'applicazione gestisce le credenziali, evitando fughe di dati tra server.

L'autorizzazione viene applicata tramite AuthPolicy di Kuadrant, che integra Authorino per la convalida del token web JSON (JWT) e la valutazione delle regole Open Policy Agent (OPA) a livello di Gateway API.

Per OpenClaw, questo significa che l'agente imposta una variabile di ambiente MCP_URL e ottiene l'accesso a un catalogo di strumenti aggregato. Gli strumenti che può effettivamente chiamare sono determinati dalle relative attestazioni dei token, non dal prompt. Gli attacchi di prompt injection che tentano di indurre l'agente a chiamare strumenti non autorizzati vengono bloccati a livello di infrastruttura, perché il gateway ignora completamente il contenuto dei prompt. Convalida le attestazioni sui token.

Scelta delle superfici API per gli agenti di produzione

Molti team hanno iniziato con la chat, sono passati al completamento delle chat e alle API OpenAI, quindi ai framework e ora agli agenti. Le API utilizzate dagli agenti si stanno consolidando. Una delle API più diffuse per i carichi di lavoro degli agenti è l'API Responses e OpenAI ha aperto questa strada con la specifica OpenResponses.

Red Hat AI offre un'implementazione completamente conforme alla specifica OpenResponses. In questo modo, i team possono eseguire i carichi di lavoro degli agenti su un'infrastruttura self-hosted o basata su modelli ibridi, invece di indirizzare ogni prompt, chiamata dello strumento e artefatto di ragionamento tramite servizi di terze parti.

I runtime compatibili con OpenResponses per gli ambienti ibridi e autogestiti sono ancora limitati. Red Hat AI fornisce una delle implementazioni più mature della specifica che colma questa lacuna, rendendola una soluzione pratica per gli utenti di OpenClaw che desiderano preservare il comportamento degli agenti orientato alle API delle risposte OpenAI, trasferendo al contempo l'esecuzione nell'infrastruttura che controllano.

Per i team che desiderano un percorso self-hosted senza un livello di orchestrazione API Responses, vLLM, incluso in Red Hat AI, fornisce un endpoint compatibile con OpenAI /v1/chat/completions che OpenClaw può utilizzare direttamente.

Ciclo di vita degli agenti con Kagenti

Molti team hanno difficoltà a trasferire un agente dal laptop alla produzione. Kagenti, previsto all’interno di OpenShift AI, colma questa lacuna. kagenti-operator individua automaticamente gli agenti tramite CRD AgentCard basati su A2A e inserisce identità (SPIFFE/SPIRE), tracciamento e tool governance (MCP Gateway) senza modificare il codice dell'agente tramite un costrutto AgentRuntime. L'intero ciclo di vita, dall'individuazione alla governance del runtime, è gestito dalla piattaforma. Il catalogo e il registro degli agenti sono inclusi nella roadmap per la UI di OpenShift AI, insieme a un catalogo MCP per i server degli strumenti.

In questa serie

Questa serie di blog illustra in dettaglio questi livelli, utilizzando OpenClaw come esempio di runtime dell'agente. Ogni post è indipendente. Leggili in ordine oppure passa direttamente a quelli che corrispondono al tuo problema attuale.

L'unica costante in ogni post è il principio BYOA. Non ti chiediamo mai di riscrivere il tuo agente. Applichiamo il rigore enterprise all'agente, non il contrario.

Per maggiori informazioni sui prodotti Red Hat AI per la creazione, la valutazione e l'applicazione della sicurezza per le applicazioni di IA, consulta la documentazione ufficiale del prodotto e i seguenti progetti upstream, importanti per l’aspetto AgentOps di Red Hat AI :

• vLLM
• MCP Gateway
• Open Responses/Llama Stack
• Authorino
• Garak
• TrustyAI Service Operator
• NeMo Guardrails
• Kagenti
• Kagenti Operator