MCP vs CLI: Cosa succede quando il tuo agente AI non trova il connettore

Quando un agente AI deve agire su una macchina, la via pulita è il Model Context Protocol (MCP). Un server MCP espone un set definito di strumenti, l’agente li chiama, e puoi ragionare su cosa gli è permesso fare perché la lista è breve e scritta. Poi l’agente ha bisogno di qualcosa senza connettore, come un sistema di ticket interno o un’app di linea di business che nessuno ha toccato dal 2012, e la storia cambia. Un agente determinato a completare il suo compito cerca un’altra porta, e quella porta è quasi sempre la riga di comando.

La maggior parte della discussione online su MCP vs CLI si concentra sui costi dei token, OAuth e sulla gestione delle credenziali, che sono argomenti legittimi. Pochissimo chiede cosa eseguirà effettivamente l’endpoint una volta che l’agente esce dal percorso MCP, e questa è la parte di cui si occupano gli amministratori IT.

MCP vs CLI

I due approcci conferiscono all’agente quantità di potere molto diverse. Con MCP, l’agente riceve un elenco definito di strumenti e nient’altro. Con una CLI, l’agente controlla una shell, e una shell ha tutti i diritti dell’utente connesso. Il modo codice, il modello più recente descritto di seguito, si comporta come il lato CLI di quella linea quando viene eseguito su un desktop gestito, perché l’agente scrive il proprio programma e la macchina lo esegue.

Questa differenza spiega perché agli sviluppatori piace la CLI (consuma pochi token e gli agenti conoscono strumenti come git e docker) e perché ai team di sicurezza piace MCP (una lista breve è più facile da controllare e OAuth offre un’autenticazione centrale). Entrambe le parti hanno ragione. Ciò che nessuno risolve è cosa impedisce a un agent di eseguire qualcosa che nessuno ha approvato una volta che esce dalla lista degli strumenti.

Gli agenti tornano alla CLI

Immagina che uno sviluppatore chieda a un agente di estrarre dati da quel sistema di ticketing. Senza un connettore, l’agente scrive uno script, scarica un binario di supporto e mette insieme alcuni comandi, e nessuno ha approvato nulla perché la governance del tuo MCP non l’ha mai visto. L’agente ha lasciato completamente il mondo MCP. È come un film di rapine in cui il team di sicurezza ha passato mesi nella cassaforte principale mentre la squadra è entrata dal magazzino; la squadra qui è un software ben intenzionato, e il magazzino è altrettanto aperto.

Il fallback è anche silenzioso, perché un log MCP non registra un PowerShell command eseguito autonomamente dall'agente.

L'esecuzione del codice con MCP mette il codice scritto dall'agente sui tuoi endpoint

Lo stesso MCP sta cambiando. Invece di chiamare uno strumento alla volta e inviare ogni risultato al modello, gli agenti stanno passando alla modalità codice: l’agente scrive un piccolo programma che chiama gli strumenti MCP, filtra e combina ciò che riceve, e lo esegue tutto. Anthropic ha descritto questo schema nel suo blog di ingegneria, e il vantaggio è facile da vedere, dato che uno script può effettuare venti chiamate agli strumenti senza passare ogni risultato attraverso il modello. Risparmia token e rende gli agenti più capaci, quindi sta guadagnando terreno.

Inserisce anche codice reale scritto dall’agente sui tuoi endpoint. L’esecuzione del codice con MCP sposta la questione di controllo da quali strumenti l’agente può chiamare a quali programmi l’endpoint eseguirà, e un programma è affidabile solo quanto chi lo ha scritto. Alcune configurazioni eseguono quel codice in una sandbox, e una sandbox aiuta molto. Tuttavia, un desktop Windows o Mac gestito di solito non è una sandbox, e se la macchina esegue qualsiasi cosa le venga fornita, la tua lista di strumenti approvati è solo un suggerimento, perché il codice dell’agente può aggirare il server MCP con la stessa facilità con cui lo attraversa.

Cosa che uno shell rogue o script agente può fare con privilegi di amministratore locale

Il danno dipende dai diritti che l'agente sta prendendo in prestito. Con un amministratore locale, il fallback CLI ha il pieno controllo della macchina, quindi può installare software o disattivare le protezioni senza chiedere a nessuno. L'agente di un utente standard può comunque eseguire un eseguibile che nessuno ha revisionato, sia per un suo errore sia perché una iniezione di prompt nascosta in un documento letto gli ha ordinato di farlo.

Imporre limiti dove viene eseguito il codice

Molti team cercano di controllare l’agente stesso con prompt di sistema, limitazioni e politiche in linguaggio semplice. Questo aiuta, ma agisce sul lato AI, e un agente può essere confuso o manipolato. La mossa affidabile è imporre limiti dove il codice viene eseguito, così il risultato resta sicuro qualunque cosa tenti l’agente. L’endpoint è la parte dello stack che l’IT già possiede, ed è lì che PolicyPak funziona.

Come PolicyPak gestisce MCP vs CLI: minimo privilegio e allowlisting

PolicyPak affronta il problema da due direzioni, e la prima è il principio del minor privilegio. PolicyPak Least Privilege Manager rimuove i diritti di amministratore locale dagli utenti e concede i diritti di amministratore solo alle applicazioni e ai compiti specifici che ne hanno bisogno, su Windows e Mac. Un agente che ricorre alla CLI sotto un utente standard non può installare driver né manomettere gli strumenti di sicurezza, e le eccezioni che hai concesso rimangono limitate alle app che hai nominato.

Il secondo è la lista di consentiti. PolicyPak SecureRun funziona basandosi sulla proprietà del file: gli eseguibili introdotti da utenti standard, o da un agente che agisce come tale, non vengono eseguiti a meno che non siano di proprietà di un account attendibile, come il tuo strumento di distribuzione software o un amministratore. Questo è importante per la modalità codice. Quando un agente scrive uno script o inserisce un binario di supporto, SecureRun non si fida del file e lo blocca, motivo per cui funziona anche come prevenzione ransomware con un clic. Ottieni una lista di consentiti generale senza manutenzione hash per hash e senza rimuovere gli strumenti che già usi.

Gli agenti possono continuare a usare MCP ovunque sia presente un connettore. Dove non c’è, il fallback CLI viene eseguito su una macchina dove l’utente non ha diritti di amministratore e il file appena scritto dall’agente non ha un proprietario attendibile, e ciò rimane valido quando l’esecuzione del codice con MCP è la norma.