Quali funzioni aprire agli agenti IA?

Rendi una funzione della tua azienda accessibile agli assistenti IA quando aiuta a svolgere un compito preciso del cliente e i tuoi sistemi possono farne rispettare i limiti. Parti dal compito, dai dati necessari e dalla persona responsabile del risultato. Una FAQ pubblica potrebbe aver bisogno solo di una pagina più chiara. Lo stato privato di un ordine richiede accesso controllato. Una prenotazione richiede un processo definito di approvazione e conferma.

Una funzione «richiamabile dagli agenti» è una funzione che esponi perché un assistente la utilizzi, per esempio per verificare la disponibilità. Non implica concedergli accesso generale ai tuoi sistemi.

Scegli il primo compito e i suoi limiti

Immagina un’azienda di servizi i cui clienti chiedono spesso se il lavoro è pronto. Un primo strumento utile potrebbe restituire lo stato di una singola pratica. Le sue regole dovrebbero stabilire che:

• Chi chiama deve essere autorizzato a vedere quella pratica. Conoscerne il numero non basta.
• La risposta contiene lo stato approvato per il cliente, l’ultimo aggiornamento e un contatto di assistenza. Esclude note interne e dati di altri clienti.
• Lo strumento non può modificare la pratica, emettere rimborsi o promettere una data di completamento assente dal sistema di origine.
• Se la fonte non è disponibile o l’accesso fallisce, segnala la situazione senza inventare uno stato.

Confronta questa soluzione con il portale clienti esistente prima di creare un’altra interfaccia. Se il portale risolve già il problema, chiarisci perché ai clienti serve un collegamento tramite assistente e come lo manterrai.

Nella prima versione escludi pagamenti, rimborsi, modifiche distruttive ed esportazioni massive di dati personali. Ogni ampliamento proposto deve avere approvazione e test propri. Chiedere al modello di comportarsi bene non è un controllo degli accessi.

Anche la sola lettura richiede protezione

Una lettura può divulgare un documento privato, mostrare l’ordine di un altro cliente o presentare un vecchio prezzo come attuale. Può danneggiare i clienti anche senza modificare alcun record.

Determina l’accesso da un’identità verificata e dai permessi applicati sul server. Un account_id fornito dall’assistente non prova che l’account appartenga all’utente. Anche nella stessa organizzazione, un dipendente potrebbe non avere diritto a tutti i documenti.

Che cosa offre MCP e che cosa devi implementare

Il Model Context Protocol (MCP) è un modo per esporre strumenti agli assistenti. I riferimenti seguenti riguardano la revisione del 28 luglio 2026, verificata il 9 ottobre 2026. Controlla le versioni effettivamente supportate da client e server.

La specifica di autorizzazione tratta autorizzazione HTTP, validazione dei token e ambiti dei permessi. Non si limita a trasmettere un login. La tua implementazione deve comunque collegare i permessi concessi a operazioni e record consentiti. Un token valido ma destinato a un altro servizio non deve essere accettato.

La specifica degli strumenti richiede validazione degli input, controlli di accesso, limiti alle chiamate e sanificazione degli output sul server. Raccomanda supervisione umana e richieste di conferma, senza imporre un unico modello di interazione. Collegare un client MCP non prova che questi controlli funzionino nella tua applicazione.

Le indicazioni di sicurezza avvertono inoltre che possedere un identificatore di stato non equivale ad autenticarsi. Un riferimento a un flusso o a un carrello identifica qualcosa da verificare, non chi possa usarlo.

Rendi l’approvazione precisa e vincolante

Per una prenotazione proposta, mostra al cliente servizio, fuso orario, data, prezzo e condizioni di cancellazione prima della conferma. Registra ciò che è stato approvato. Se cambia un dettaglio sostanziale, ottieni una nuova approvazione. Un campo «approvato» generato dal modello non dimostra il consenso del cliente.

Separa la preparazione della proposta dalla sua conferma. Se salvare una bozza crea un record o invia una notifica, è già una scrittura da includere nel disegno dei permessi. Il server deve rifiutare l’impegno senza l’approvazione richiesta per quelle condizioni esatte.

La nostra offerta di sistemi accessibili agli agenti parte dagli strumenti di lettura e aggiunge per ultime le azioni che creano obblighi, con conferma del cliente per ciò che è irreversibile. Il nostro pilota ha requisiti propri di approvazione umana per scritture nei sistemi, messaggi ai clienti e movimenti di denaro. Un esempio generale di architettura non amplia quel perimetro contrattuale.

Prova rifiuti e recupero prima del rilascio

Usa account e record di test. Conserva il risultato atteso accanto a quello osservato, affinché un altro sviluppatore possa ripetere la prova.

Usa permessi ristretti, credenziali con scadenza e revoca verificata. Separa le credenziali quando il confine di sicurezza lo richiede; un login diverso per ogni strumento non è una regola universale. Imposta timeout, limiti ai tentativi e quote per chiamante. Per le scritture, usa un identificatore stabile dell’operazione e una gestione dei duplicati sul server, senza affidarti alla memoria del modello.

Registra chiamante, operazione, decisione sui permessi, riferimento pertinente all’approvazione ed esito. Oscura segreti e dati personali superflui; stabilisci chi può leggere i log e quanto vengono conservati. Assegna un operatore che possa ritirare uno strumento e chiarire un esito incerto. La guida ai piloti per l’ufficio acquisti spiega come rendere verificabili queste responsabilità.

Che cosa dimostra il nostro esempio pubblico

Il 9 ottobre 2026 abbiamo esaminato tools/list su mcp.strataigize.com, i metadati pubblici di autorizzazione e auth.md. L’elenco dichiarava sette strumenti pubblici di lettura e uno strumento autenticato, request_growth_audit, per una consulenza gratuita sulla crescita. Nonostante il vecchio nome, richiede una consulenza, non l’AI Opportunity Audit a pagamento.

Quella richiesta è una scrittura. La documentazione esige la richiesta di una persona specifica e indica che un essere umano esamina gli invii; nulla viene prenotato automaticamente. Distingue inoltre la registrazione aperta di un client software dalla verifica dell’identità di una persona.

Questa ispezione conferma l’interfaccia e le regole pubblicate. Non abbiamo inviato una richiesta né verificato la sicurezza in questa revisione. L’elenco degli strumenti non dimostra uso esterno o vendite.

Prima di commissionare un’interfaccia, annota primo compito del cliente, dati consentiti, azioni vietate, punto di approvazione, test di errore, operatore e procedura di ritiro. Misura i compiti completati correttamente insieme a rifiuti, eccezioni e tempo di revisione. Le chiamate grezze comprendono tentativi ripetuti e fallimenti: non sono un conteggio dei successi. La consulenza IA può aiutarti a definire il perimetro prima di commissionare l’integrazione.