Blocca le azioni degli agenti AI sull'endpoint

Applicazione

Tutto il resto osserva.

ZYBE rifiuta l'azione prima che parta.

La chiamata a tool che un agente AI sta per fare viene valutata sull'endpoint, nel momento che precede l'azione dentro l'agente stesso, rispetto alle tue regole. Se una regola dice no, il comando non parte, il file non si apre, il server non risponde. Il modello riceve il motivo e l'indicazione di non tentare un'altra strada. Niente proxy, niente gateway, nessun traffico da ispezionare: è l'agente stesso ad applicare la decisione, ed è per questo che regge offline e su ogni laptop insieme.

Come funziona, con i disegni

Cosa regge su ogni agente

Cosa viene fermato

Dodici tipi di azione, rifiutati sull'endpoint

Ognuno è una regola. Impostala su Report, Ask o Block, per profilo, per gruppo di endpoint, per agente.

Dove regge

Dodici agenti sotto regole, e gli altri rifiutati del tutto

Ogni agente con un hook prima dell'azione esegue l'hook di ZYBE. Le app senza hook agiscono tramite server MCP, e quelli passano dallo shim di ZYBE. La console mostra una di quattro parole per agente e per endpoint, calcolata dalle chiamate davvero arrivate: Blocking, Recording, Seen, Silent, oppure Not allowed per un prodotto che l'azienda ha rifiutato.

Agente

Come gli arriva il rifiuto

Hook, nelle impostazioni gestite

Hook

Hook, gestito nelle installazioni a livello di macchina

Hook, più la policy gestita

Hook, nel file condiviso degli hook di Gemini

Hook di shell nella sua configurazione

Un plugin ZYBE dentro il suo gateway

I suoi server MCP passano dallo shim di ZYBE

I loro server MCP passano dallo shim

Rifiutato del tutto: l'endpoint gli toglie il permesso di girare

L'ultima riga non ha un hook, quindi una regola non può valutare una chiamata alla volta. L'azienda decide se il prodotto è consentito o no, e l'endpoint lo applica. La console non conta mai un agente come bloccato solo perché un file è al suo posto.

Con le parole dell'agente

Com'è fatto un rifiuto

Sessioni reali, agenti reali, a cui è stato chiesto di installare un pacchetto che il workspace aveva contenuto. Ognuno si è fermato, ha citato il motivo e non ci ha riprovato.

Una minaccia aperta in console: l'output iniettato, il comando che è seguito, il riepilogo e la correzione

La catena, in console: istruzioni arrivate in una pagina scaricata, il comando successivo in quella sessione e cosa fare.

Il quarto stato

Not allowed: quando non c'è una porta, l'endpoint rifiuta l'app

Alcune app agiscono nel cloud del vendor o sul web, senza nulla sul laptop davanti a cui mettere un hook. Per quelle, l'azienda decide se l'app è consentita o no, e l'endpoint applica la risposta: le toglie il permesso di girare, la chiude se è aperta e le restituisce il permesso appena l'azienda la consente di nuovo. Scrivi il nome del prodotto una volta in Rules, e ogni endpoint lo rifiuta entro un minuto. Installata, rifiutata e visibile come Not allowed su ogni endpoint. Nessun altro lo fa sull'endpoint.

Nulla esce

Valutato sulla macchina, non nel cloud di qualcun altro

Il comando, il percorso, la pagina e il prompt vengono letti sull'endpoint e mai inviati. Alla console arrivano la regola che ha fatto match, la decisione, l'agente e un hash. È questa la differenza rispetto a un gateway che ispeziona il tuo traffico: ZYBE vede cosa fa l'agente, e le tue conversazioni restano tue.

Installa su una macchina

Cosa esce dalla macchina