Un worker IA deve verificare un server di progetto o avviare un’azione approvata. Servono strumenti e permessi adeguati. Un file con tutti i token API e le chiavi SSH private nella cartella del progetto rende il flusso comodo, ma aumenta le possibili conseguenze di un errore o di un input manipolato.
Un intermediario MCP controllato può rappresentare in modo preciso l’ambito delle azioni consentite. L’agente richiede un’azione definita; il server verifica identità, progetto e autorizzazione. Quando il flusso lo permette, un servizio backend limitato usa le credenziali necessarie senza restituirle al modello.
MCP fornisce strumenti, non permessi automaticamente sicuri
Il Model Context Protocol descrive come i client utilizzano strumenti e altre capacità di un server. È l’applicazione a dover decidere in modo affidabile se un utente può compiere una determinata azione su un oggetto concreto. Un client autenticato non è automaticamente autorizzato per ogni progetto o strumento.
Per le connessioni HTTP protette, MCP descrive un percorso di autorizzazione basato su OAuth. La specifica attuale lo distingue dalle connessioni STDIO locali. La protezione adatta dipende dal trasporto effettivo. Una chiave arbitraria nel parametro URL o un token permanente condiviso non equivalgono a una gestione differenziata dei permessi.
Un esempio concreto: il progetto A resta il progetto A
Un worker riceve il compito di interrogare lo stato di un servizio concordato nel progetto A. Uno strumento dedicato accetta un identificativo oggetto verificato e restituisce solo il risultato necessario. Non offre una shell liberamente utilizzabile né un’esportazione generale di tutti i segreti.
Ogni chiamata viene verificata sul server rispetto a utente, progetto, strumento e azione. Nemmeno un identificativo di progetto modificato dal client deve consentire accesso al progetto B. Le destinazioni vengono risolte da associazioni approvate; un indirizzo arbitrario fornito dal modello non è un’autorizzazione sufficiente. I confini tra tenant rientrano in questa verifica.
Verificare il token per il destinatario corretto
Sul server HTTP MCP protetto, un access token deve essere emesso per il destinatario previsto e verificato lì. Audience, ambito consentito e validità sono aspetti congiunti. Durate brevi limitano la finestra d’uso di un token rubato; non sostituiscono né il controllo server degli oggetti né la procedura di revoca.
La documentazione di sicurezza MCP vieta il token passthrough non verificato: un server non deve accettare token destinati ad altre risorse come propria prova di autorizzazione e inoltrarli invariati alle API successive. L’accesso del client MCP e l’autorizzazione presso un sistema di destinazione sono relazioni di fiducia separate. Un passaggio poco chiaro può far usare un intermediario privilegiato per scopi altrui; questo problema è chiamato confused deputy.
Usare i segreti nel backend previsto
Un backend di gestione dei segreti può fornire credenziali secondo responsabilità e scopo. Il servizio esecutore riceve solo i permessi necessari. L’interfaccia amministrativa gestisce approvazioni, associazioni e revoche; non diventa un catalogo di password generalmente leggibile da tutti i worker collegati.
Uno strumento limitato può leggere un valore di stato o svolgere un’azione operativa esplicitamente consentita e restituire un risultato ripulito. I dati grezzi del backend dei segreti non devono finire incidentalmente in output degli strumenti, errori, trace o prompt. Se un client concreto deve tecnicamente ricevere un segreto, la divulgazione viene valutata espressamente e limitata per ambito, durata e destinatario. Una garanzia generale di assenza di divulgazione sarebbe allora falsa.
| Punto di verifica | Confine richiesto | Test concreto |
|---|---|---|
| Utente e progetto | Ogni azione resta nell’ambito di progetto consentito. | Cambiare identificativo di progetto: rifiutare l’accesso non autorizzato. |
| Strumento e parametri | Sono raggiungibili solo azioni e destinazioni previste. | Rifiutare un indirizzo libero o l’identificativo di un oggetto estraneo. |
| Token e backend | Destinatario e percorso di autorizzazione sono chiari. | Verificare audience errata, scadenza e revoca. |
| Segreti e risultati | Solo i risultati necessari lasciano il backend. | Controllare output degli strumenti, errori e log per valori grezzi. |
| Approvazione e gestione | Le modifiche con conseguenze rilevanti hanno approvazioni specifiche. | Testare vincolo alla destinazione, durata, limiti e gestione del guasto. |
Un contenuto esterno non può concedere un permesso
Un ticket, sito o repository può contenere testo che tenta di indirizzare l’agente verso altre azioni. Anche descrizioni e risposte degli strumenti possono essere manipolate. Questi contenuti sono dati, non prove di autorizzazione. Un prompt come «usa solo il progetto A» aiuta a descrivere il compito, ma non sostituisce un confine di progetto imposto tecnicamente.
Strumenti circoscritti, parametri verificati, sistemi di destinazione limitati e controlli di autorizzazione indipendenti riducono l’effetto della prompt injection. Le approvazioni aggiuntive dipendono dall’azione: una lettura di stato richiede un percorso diverso da una modifica con conseguenze importanti. L’approvazione viene vincolata alla destinazione concreta e alla modifica prevista.
Pianificare registrazione e revoca
Per una gestione verificabile si registrano identità utente o di servizio, progetto, strumento, decisione, momento e risultato. I valori segreti restano esclusi. Conservazione, accesso ai log e dettaglio necessario vengono concordati per l’ambiente. Un singolo log di successo non sostituisce la verifica di ciò che è realmente accaduto sulla destinazione.
Limiti di frequenza, limiti temporali e un ambito backend ristretto riducono ulteriormente le conseguenze di chiamate inattese. Nella revoca si considerano separatamente nuove chiamate, credenziali già emesse e azioni in corso. Un guasto del servizio MCP o dei segreti richiede un percorso definito di errore e ripristino.
Iniziare con un piccolo progetto pilota
Un pilota adatto parte da un progetto e pochi strumenti di sola lettura. Si verificano identificativi oggetto consentiti e vietati, permessi mancanti, credenziali scadute, risposte manipolate e indisponibilità di un backend. Solo dopo si valutano azioni di scrittura chiaramente limitate. L’ambito dipende dal rischio e dalla gestione esistente.
DAXS supporta architettura, integrazione e un ambito di strumenti verificabile. La pagina su MCP e interfacce, il contributo sugli accessi SSH gestiti e la panoramica sulla sicurezza IA approfondiscono i collegamenti. È possibile discutere un’integrazione IA legata a un progetto.
Domande frequenti
Un server MCP può nascondere tutte le credenziali al modello?
Con azioni server progettate in modo adatto, il modello può ricevere solo il risultato ripulito. Va verificato se ciò sia possibile per ogni operazione necessaria. Il trasferimento tecnico di un segreto al client cambia la valutazione del rischio.
Un lungo token segreto basta come protezione?
No. Vanno verificati anche destinatario, ambito, validità, associazione a utente e progetto, e azione concreta. Un unico token ampiamente autorizzato non offre da solo questa separazione.
Come inizia un pilota con più progetti?
Prima si definiscono e testano le azioni consentite per un progetto. Poi si verifica un secondo progetto anche con riferimenti incrociati esplicitamente vietati. Solo una separazione realmente imposta crea la base per ulteriori compiti.
Fonti: MCP: autorizzazione, versione 28.07.2026 (link esterno) · MCP: confini di fiducia e token passthrough (link esterno) · OWASP: autorizzazione per chiamata e oggetto (link esterno) · OWASP: gestione dei segreti (link esterno) · OWASP: limitare la prompt injection (link esterno)
Funzionalità e ambito operativo concreti vengono concordati per l’ambiente.
