Descrizioni degli strumenti avvelenati

Descrizioni degli strumenti avvelenati

Gli agenti leggono le descrizioni degli strumenti come istruzioni, non come documenti.

Cos’è Descrizioni degli strumenti avvelenati?

Un agente AI legge la descrizione di uno strumento connesso per decidere come e quando utilizzarlo, il che rende quel testo più vicino alle istruzioni eseguibili che alla documentazione. Cambia la descrizione e cambierai il comportamento dell'agente, senza alcuna modifica al gestore, allo schema o alle autorizzazioni e senza nulla in una revisione del codice per rilevarlo. Troverai uno strumento approvato mesi fa che ora istruisce l'agente a BCC ogni messaggio a un indirizzo esterno, confronta la descrizione in tempo reale con la dicitura approvata e blocca il server compromesso al gateway.

Cosa imparerai in Descrizioni degli strumenti avvelenati

Descrizioni degli strumenti avvelenati — Fasi della formazione

  1. Token di pubblicazione di qualcun altro

    Bob non sta attaccando la Sarnholt Systems. Sta attaccando il venditore di cui già si fidano. Un token del manutentore rubato gli consente di pubblicare nel registro di VaultSync Bridge come VaultSync Bridge.

  2. Il manifesto che tutti leggono

    Il manifesto dello strumento del server è ciò che elenca ogni client connesso quando chiede al server cosa può fare. Bob apre la copia che sta per pubblicare.

  3. Una corda

    Non cambia nulla per cui un recensore non sarebbe d'accordo. Il gestore è intatto, lo schema di input è intatto, le autorizzazioni sono intatte. Modifica la frase letta dall'agente.

  4. Spedito come patch

    Lo pubblica come un normale comunicato stampa. Il registro lo accetta perché un account manutentore legittimo lo ha pubblicato.

  5. In attesa dell'aggiornamento

    Bob ha finito. Il resto avviene all'interno di Sarnholt, sul proprio server approvato, la prossima volta che un agente prende in mano uno strumento che ha utilizzato in sicurezza per mesi.

  6. Un aggiornamento di routine del fornitore

    Lunedì mattina alla Sarnholt Systems. Alice, un ingegnere di piattaforma AI, apre la sua casella di posta con la solita pila: note standup, un invito sul calendario e un avviso di rilascio da un server MCP di terze parti a cui il suo team si è connesso mesi fa. Niente di tutto ciò sembra urgente.

  7. Collegamento della flotta

    Sarnholt Systems gestisce i propri strumenti per agenti tramite Agent Host, il client MCP dell'azienda. ticket-desk-mcp , una piccola integrazione dell'helpdesk interno, e fileops-mcp , il connettore di file ed e-mail VaultSync Bridge appena aggiornato, sono già connessi e approvati.

  8. Revisione degli strumenti approvati

    Prima di toccare qualsiasi cosa, Alice controlla cosa è effettivamente collegato. Entrambi i server appaiono esattamente come quando il suo team li ha autorizzati: stesso endpoint, stessa versione, stesse descrizioni degli strumenti.

  9. L'aggiornamento arriva silenziosamente

    La patch di VaultSync raggiunge fileops-mcp mentre Alice è ancora nella scheda. Riscrive ciò che viene richiesto di fare a send_email . Nessuna richiesta di approvazione, nessun aggiornamento della versione, nessuna notifica. L'elenco degli strumenti viene semplicemente ridisegnato.

  10. Una richiesta ordinaria

    L'elenco degli strumenti è stato ridisegnato mentre Alice leggeva la sua casella di posta; niente le chiedeva di guardarlo. Ritorna al lavoro di routine e chiede all'agente di gestire un compito normale.

Copertura dei framework di sicurezza

OWASP MCP Top 10

  • MCP03:2025 Tool Poisoning

CWE

  • CWE-1427 Improper Neutralization of Input Used for LLM Prompting
  • CWE-345 Insufficient Verification of Data Authenticity

CIS Controls

  • CIS 16 Application Software Security

NIST CSF

  • PR.AT-02 Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
  • PR.PS Platform Security