Governate ogni agente, non solo ogni richiesta.
Un agente trasforma una istruzione in decine di chiamate a modelli, strumenti e altri agenti. Wäg sta davanti a tutte e sa quale agente agisce, per quale persona, cosa può toccare, cosa può spendere e chi ha approvato il passo rischioso — e può dimostrarlo dopo. Costruite agenti dove preferite: raggiungono tutto passando di qui.
Un agente non è una richiesta più grande.
Una richiesta di chat è una decisione che potete permettere o rifiutare. Un agente è un ciclo: legge un documento, chiama uno strumento, legge il risultato, ne chiama un altro e va avanti finché non si ritiene concluso. I guasti costosi non sono le risposte sbagliate. Sono il ciclo che non si ferma, lo strumento cambiato in silenzio, i dati usciti da una chiamata che nessuno ha ispezionato e la credenziale che vive per sempre in una variabile d'ambiente.
MCP e A2A identificano l'agente e l'account che usa. Nessuno dei due porta il dato che un revisore chiede per primo: quale essere umano ha autorizzato quel preciso passo. Wäg scrive l'identità di chi approva sulla chiamata stessa, in una voce concatenata con hash che potete verificare offline.
Tredici controlli, nell'ordine in cui li incontrate
Apache-2.0 salvo dove indicato. Vale per gli agenti che costruite ovunque — LangGraph, Bedrock AgentCore, Vertex, Foundry, Claude Code o il vostro ciclo — perché tutti raggiungono modelli, strumenti e altri agenti attraverso il gateway.
Gli agenti sono principal
Un agente è un'identità di prima classe, con un responsabile umano, un runtime dichiarato, un livello di rischio e una finalità. Ogni richiesta porta l'agente e la persona per cui agisce nel log delle richieste e nel registro delle prove.
Esecuzioni, e limiti che le fermano
Un'esecuzione è un compito dell'agente. Limitatene richieste, chiamate a strumenti, token, costo e durata. Oltre il limite la richiesta successiva dell'esecuzione viene rifiutata e il chiamante viene informato di quale limite ha raggiunto — prima che arrivi la fattura, non dopo.
Policy sugli strumenti: il firewall degli agenti
Regole ordinate decidono ogni chiamata: permettere, rifiutare, far classificare a un modello o trattenere per una persona. Le condizioni leggono argomenti e chiamante, così "i rimborsi oltre 1.000 richiedono un'approvazione" è una sola regola. La prova a vuoto conta cosa avrebbe fatto una regola e "Prova una chiamata" mostra quale decide — in console o in CI.
Approvazioni con un nome sopra
Una chiamata trattenuta aspetta una persona, non un flag. Gli approvatori sono utenti o team, l'autoapprovazione è rifiutata per impostazione predefinita e ogni richiesta scade. Decidono nella console o tramite un prompt nel proprio client MCP, e un'email può avvisarli che una richiesta è in attesa; decidere in Slack o Microsoft Teams è Enterprise. La decisione e chi l'ha presa finiscono nel registro.
Controllo dei flussi di dati
Gli strumenti portano etichette: restituisce dati privati, restituisce contenuti controllati da estranei, può far uscire dati. Quando un'esecuzione ha toccato le prime due, la terza viene rifiutata o trattenuta: il trio letale, chiuso per costruzione. Il controllo arriva anche al singolo dato, con impronte cifrate di ciò che uno strumento sensibile ha restituito, mai il testo.
Fissaggio degli strumenti
Ogni strumento MCP è fissato alla definizione approvata da un amministratore: nome, descrizione, schemi e annotazioni, così uno strumento che smette di essere in sola lettura conta come cambiato. Se un server ne cambia uno, finisce in quarantena finché una persona non esamina la differenza e la accetta. Le sostituzioni smettono di essere silenziose.
Nessuna chiave permanente
Gli agenti ottengono credenziali che durano minuti e si identificano con una coppia di chiavi registrata invece che con un segreto condiviso, legate a una sola esecuzione se lo volete. DPoP rende inutile un token copiato; funzionano anche TLS reciproco e identità SPIFFE, e le chiavi durature possono essere vietate del tutto.
Uscita gestita
Gli agenti raggiungono API di terze parti attraverso una destinazione registrata, e il gateway aggiunge la credenziale: l'agente non tiene mai la chiave e i suoi header di autenticazione vengono rimossi lungo il percorso. Ogni destinazione fissa quali metodi e percorsi ammette, e ogni chiamata passa per policy sugli strumenti, approvazioni, budget, guardrail, residenza e registro come tutte le altre.
Ogni connessione in uscita
Puntate l'HTTPS_PROXY di un agente al gateway e tutto il suo traffico web passa per la control plane, non solo le chiamate a modelli e strumenti. Le regole sugli host decidono quali siti può raggiungere, e ogni connessione vale come una chiamata a strumento: policy, approvazioni ed etichette di flusso si applicano, e conta nell'esecuzione. Il nome TLS deve corrispondere all'host richiesto, l'encrypted client hello viene rifiutato e i tunnel aperti si chiudono in pochi secondi quando un permesso viene revocato o l'agente fermato. Aprire il TLS per host selezionati, così che regole sulle richieste e guardrail si applichino all'interno, è Enterprise.
Altri agenti, dietro le vostre chiavi
Registrate un agente remoto tramite la sua agent card A2A, e le vostre persone e i vostri agenti lo chiamano sotto /v1/a2a con le credenziali di sempre. L'agente remoto vede solo la credenziale del gateway, e ogni messaggio riceve controlli di accesso, budget, guardrail, limiti di esecuzione, policy sugli strumenti e prove come una chiamata a un modello.
Inventario e interruttore di emergenza
Trovate gli agenti che nessuno ha registrato — Wäg li riconosce da come si comporta il loro traffico — e i server MCP che i vostri sviluppatori eseguono sulle proprie macchine, dai nomi degli strumenti presenti nelle loro richieste. Assegnate a ciascuno una data di revisione e una scadenza applicata. Quando qualcosa va storto, fermate un'esecuzione, un agente o tutti gli agenti di un'organizzazione, su ogni replica e regione contemporaneamente.
Agenti da altre piattaforme Enterprise
Importate nell'inventario gli agenti che Microsoft Foundry, AWS Agent Registry, Microsoft Entra Agent ID e Gemini Enterprise già conoscono, e manteneteli sincronizzati. Ognuno riceve un responsabile, un livello di rischio, limiti di esecuzione e policy sugli strumenti; le sue istruzioni e credenziali non vengono mai lette.
Pagamenti degli agenti Enterprise
Date a un agente un mandato di spesa invece di una carta: un budget proprio per valuta, approvazione oltre una soglia e traccia di ogni pagamento. Binari per x402, mandati AP2 e checkout ACP o UCP, con il gateway che tiene la credenziale oppure verifica un agente che tiene la propria.
Prove, non uno screenshot di cruscotto
Una governance che non si può dimostrare è una preferenza. Ogni decisione qui sopra finisce nello stesso posto: un registro concatenato con hash e firmato, che potete esportare e verificare offline con la chiave pubblica del gateway.
- Ogni chiamata al provider, ogni esito e ogni modifica di configurazione, concatenati: un buco o una correzione si vede.
- Ogni approvazione: chi ha chiesto, per cosa, chi ha deciso e quando sarebbe scaduta.
- Span OpenTelemetry per le esecuzioni degli agenti, acquisiti dal vostro framework, così la vista del gateway e quella dell'agente sono un solo albero di tracce.
- Con Enterprise, pacchetti di prove degli agenti: pacchetti firmati con esecuzioni, approvazioni, arresti e registro di un'organizzazione, mappati sull'AI Act e su DORA.
Gira dove girate voi
Un binario Rust nella vostra infrastruttura. Nessun phone-home, air-gap possibile e Apache-2.0 per tutto quanto sopra, tranne le schede segnate Enterprise, le approvazioni Slack e Teams, i token dell'identity provider e dei workload, la policy sugli strumenti per le risposte pass-through, l'ispezione TLS e le regole sugli strumenti per i dispositivi. Gli agenti raggiungono i modelli tramite un endpoint compatibile con OpenAI, gli strumenti tramite il gateway MCP e gli altri agenti tramite il gateway A2A — tutto con le stesse policy, budget e prove.
MCP e governance degli strumenti · Tutta la piattaforma · Il confronto con LiteLLM
Mettete un control plane davanti ai vostri agenti
Gestitelo nella vostra infrastruttura
Tutto ciò che serve per gestire una control plane in produzione è sotto Apache-2.0 e lo resterà — routing, alta disponibilità, cache, failover, budget, policy, MCP, job e osservabilità. Self-hosted, senza account, senza chiamate verso l'esterno.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Non è un pull funzionante: le immagini non sono ancora pubbliche. I partner di progettazione ricevono i dettagli del registry in forma privata.
Avvia in 5 minutiContribuite come design partner
Wäg non è ancora disponibile pubblicamente. Lavoriamo con un piccolo gruppo di team che gestiscono IA multi-provider in produzione e prendono sul serio governance e sovranità, per irrobustire la control plane su carichi reali.
- Tutte le funzioni Enterprise incluse, senza costi di licenza
- Migrazione assistita — la facciamo insieme a voi, anche da LiteLLM
- Una linea diretta con gli ingegneri e un'influenza reale su ciò che arriva dopo