Come dare a un agente AI accesso ai dati aziendali in modo sicuro

L'architettura: l'agente è un cliente, il sistema è l'autorità

Inizia con la forma, perché la maggior parte degli errori sono errori di forma. Una persona chiede qualcosa al proprio agente. L'agente decide quali strumenti chiamare. Ogni chiamata passa attraverso uno strato di autorizzazione che appartiene al sistema aziendale, non all'agente, e solo allora raggiunge un modulo come finanza o CRM. L'agente non tocca mai il database, non detiene mai una credenziale del database e non vede mai uno strumento che la sua persona non potrebbe utilizzare.

Il principio sottostante all'immagine è una frase: l'agente agisce con l'autorità della persona che rappresenta, e mai di più. Tutto il resto in questo articolo è un modo per rendere vera quella frase sotto pressione, quando il modello è errato, quando un documento che legge contiene istruzioni, o quando un token perde.

L'OWASP Top 10 per le applicazioni LLM nomina il fallimento che questa architettura previene: agenzia eccessiva, che scompone in funzionalità eccessiva (strumenti oltre ciò che il lavoro richiede), permessi eccessivi (più accesso a valle del necessario) e autonomia eccessiva (nessun controllo indipendente prima di un'azione ad alto impatto). Le sue mitigazioni leggono come una specifica per lo strato di autorizzazione: eseguire nel contesto dell'utente, minimizzare gli strumenti e i loro permessi, applicare l'autorizzazione nel sistema a valle piuttosto che fare affidamento sul modello, e richiedere l'approvazione di una persona per azioni ad alto impatto.

Cinque controlli e dove si trovano

I controlli non sono nuovi; sono i controlli che già applichi a una persona con accesso al sistema, applicati a un cliente che agisce per quella persona. La tabella indica cosa risponde ciascuno, dove viene applicato e come appare un fallimento quando manca. La colonna della posizione è quella importante. Un controllo applicato nel prompt è un suggerimento.

Identità: connettersi come persona, tramite OAuth, mai con una chiave condivisa

La specifica di autorizzazione del Model Context Protocol è precisa su questo. Un server remoto funge da server di risorse OAuth 2.1; il client ottiene un token attraverso un flusso di autorizzazione standard con PKCE; il client deve dichiarare per quale server è destinato il token utilizzando il parametro di risorsa; e il server deve convalidare che ogni token sia stato emesso specificamente per esso, rifiutando qualsiasi altro. La specifica vieta esplicitamente il passaggio del token, in cui un server accetta un token che non ha emesso e lo inoltra a valle, perché distrugge sia la traccia di audit che il confine di fiducia.

In pratica, questo è ciò che significa "accedi una sola volta, nessun token da incollare". La persona aggiunge l'indirizzo del workspace al proprio agente, viene inviata a una normale pagina di accesso, approva la connessione e l'agente riceve un token che lo identifica e funziona solo contro quel workspace. Le indicazioni di Anthropic per i connettori personalizzati in Claude sono di rivedere gli ambiti richiesti da un server, limitarli dove possibile e connettersi solo a server di cui ti fidi. Un fornitore che invece ti chiede di incollare una chiave API aziendale nella configurazione di un agente ha saltato il primo controllo e reso gli altri quattro molto più difficili.

Ambito: filtrare prima di offrire, controllare di nuovo durante l'esecuzione

Un agente scopre cosa può fare chiedendo al server la sua lista di strumenti. Il design giusto risponde a questa domanda per persona: la lista che riceve l'agente di un contabile è diversa da quella che riceve l'agente di un direttore, e nessuna delle due include strumenti per moduli che il loro ruolo non può vedere. Questo è il consiglio OWASP per minimizzare la funzionalità reso concreto, e ha un secondo vantaggio: un modello che non viene mai mostrato uno strumento non può essere indotto a chiamarlo.

Filtrare l'elenco non è sufficiente da solo, perché i ruoli cambiano, le sessioni persistono e i client memorizzano nella cache. La stessa verifica deve essere eseguita di nuovo quando ogni chiamata arriva, in base ai permessi della persona in quel momento. Di seguito è riportato un elenco di strumenti nella forma definita dal protocollo, per un ruolo che può leggere le fatture ma non registrare i pagamenti. Lo strumento assente è il punto.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

Una risposta tools/list nella forma definita dalla specifica MCP, con i nomi degli strumenti dal modulo contabile di Sois. La specifica afferma anche che i clienti devono considerare annotazioni come readOnlyHint come non affidabili a meno che il server non sia affidabile, il che è un ulteriore motivo per cui deve essere il server, e non l'annotazione, a far rispettare la regola.

Iniezione di prompt: i dati possono rispondere

La minaccia specifica per gli agenti è che i dati che leggono possono contenere istruzioni. Un'email da un cliente che termina con una riga che dice all'agente di inoltrare l'elenco dei fornitori a un indirizzo esterno; un documento che gli dice di contrassegnare ogni fattura come pagata. Il modello può o meno conformarsi, e nessun prompt può garantire che non lo farà, motivo per cui l'iniezione di prompt è al primo posto nella lista OWASP e perché sia Anthropic che OpenAI avvertono al riguardo nelle loro linee guida per i connettori.

La difesa è l'architettura, non il modello. Un agente che ha a disposizione solo gli strumenti che la sua persona può utilizzare non può trasmettere ciò che la sua persona non può vedere. Una richiesta per contrassegnare le fatture come pagate viene controllata dal sistema rispetto ai permessi della persona, non rispetto alla convinzione del modello che sia stata richiesta. Gli strumenti consequenziali sono contrassegnati in modo che il cliente chieda prima a una persona: ChatGPT richiede attualmente una conferma manuale in una conversazione prima delle azioni di scrittura, e le indicazioni di OpenAI sono di mantenere l'approvazione attiva per gli strumenti che modificano i dati; Claude richiede approvazione per ogni strumento e consiglia di riservare "consenti sempre" per i server fidati. E il registro registra il tentativo, quindi un'iniezione che è stata bloccata è visibile successivamente piuttosto che silenziosa.

Budget e registri: rendi il lavoro dell'agente verificabile come quello di una persona.

Il budget è importante per due motivi. Il primo è ovvio: un agente a cui viene dato un risultato vago continuerà a chiamare strumenti finché qualcosa non lo ferma, e OWASP elenca il consumo illimitato come un rischio a sé stante. Il secondo, più sottile, è il raggio d'azione: un limite per integrazione limita quanto può fare un agente compromesso o confuso prima che una persona se ne accorga. Quando l'agente della persona fa il ragionamento, il costo dell'IA ricade su di loro; quando l'agente del sistema lo fa, il limite dovrebbe essere impostato per integrazione e visibile per azione.

I registri trasformano tutto questo da una promessa in qualcosa che puoi auditare. Ogni chiamata dovrebbe registrare per chi ha agito l'agente, quale strumento, gli input, il risultato e il tempo, nello stesso posto in cui il sistema registra cosa hanno fatto le persone. La prova è se un responsabile finanziario può scoprire cosa ha fatto l'agente all'account di un cliente il mese scorso con la stessa facilità con cui può farlo per un collega. La specifica MCP richiede ai clienti di registrare l'uso degli strumenti per l'audit; un sistema aziendale non dovrebbe fare affidamento sul cliente per questo, perché il cliente non è il sistema di registrazione.

Una checklist che puoi utilizzare su qualsiasi sistema.

Porta questi a qualsiasi fornitore, incluso noi. Ognuno è un sì o un no, e ognuno ha un test piuttosto che una domanda da porre.

1. L'agente si connette come persona nominata tramite OAuth, senza una chiave aziendale da incollare. Test: connettiti da un client MCP esterno e guarda cosa richiede la pagina di accesso.
2. L'elenco degli strumenti varia in base al ruolo. Test: connettiti come utente con restrizioni e come amministratore e confronta ciò che viene offerto all'agente.
3. Il controllo viene ripetuto quando lo strumento viene eseguito. Test: rimuovi un permesso da un utente connesso a metà sessione e riprova l'azione.
4. L'accesso fallisce in modo chiuso. Test: chiama uno strumento che il ruolo non dovrebbe avere e conferma di ricevere un rifiuto, non un risultato.
5. La spesa può essere limitata per integrazione e vista per azione. Test: imposta un limite ridotto e osserva come si applica.
6. Ogni azione è registrata contro la persona, con input e risultato, dove il sistema registra tutto il resto. Test: leggi il registro per un'esecuzione che hai appena fatto.
7. Gli strumenti consequenziali sono contrassegnati per conferma quindi il cliente chiede a una persona. Test: chiedi all'agente di inviare denaro o eliminare un record e conferma che ti viene chiesto prima.

Sois è un sistema progettato per superare questo elenco, e la forma in cima all'articolo è la sua forma. Uno spazio di lavoro è un server MCP; qualsiasi client MCP si connette aggiungendo l'indirizzo dello spazio di lavoro e accedendo una volta tramite OAuth; gli strumenti sono filtrati per ruolo prima di essere offerti e controllati di nuovo quando vengono eseguiti; l'accesso fallisce in chiusura; la spesa può essere limitata per integrazione; ogni azione è registrata; e le reti costruite sulla piattaforma hanno il proprio database, archiviazione, domini e chiavi. Esegui comunque la checklist. Il valore di una checklist è che non si basa sulla parola di nessuno.

Domande che le persone pongono

Questo articolo viene revisionato quando i prodotti che descrive cambiano. Prossima revisione programmata: 4 dicembre 2026.