Cosa sono gli Agent Plugins?

Gli Agent Plugins sono uno standard aperto e vendor-neutral che definisce un formato di packaging comune per distribuire estensioni di un agente AI: una singola directory portabile con un manifest plugin.json, una cartella skills/ per le Agent Skill incluse e un file mcp.json per i server MCP collegati, oltre a estensioni specifiche per singolo client. La specifica versione 1.0.0, annunciata il 6 agosto 2026, nasce dal progetto open-plugin-spec incubato da Vercel e transita in un'organizzazione indipendente, agentplugins, con manutentori principali da Amazon, Cursor, Microsoft, OpenAI e Vercel: lo statuto vieta a un singolo fornitore di detenere la maggioranza dei seggi nel comitato direttivo. I client di lancio che supportano il formato includono ChatGPT, Codex, Cursor, GitHub Copilot, Kiro e VS Code. L'obiettivo dichiarato è che un plugin si impacchetti una sola volta e venga scoperto e caricato in modo uniforme da qualsiasi client compatibile.

Il problema che risolve, e quello che non risolve ancora

Prima di questo standard, chi costruiva una skill o collegava un server MCP doveva adattare l'imballaggio della distribuzione a ogni client diverso: un formato per ChatGPT, un altro per Cursor, un altro ancora per VS Code, con la stessa logica di manutenzione duplicata a ogni aggiornamento. Agent Plugins sposta quel lavoro a monte: un solo pacchetto, letto da tutti i client che implementano la specifica. Ma il documento ufficiale "future considerations" della spec 1.0.0 elenca esplicitamente cosa manca ancora: nessun modello di trust, nessuna dichiarazione dei permessi né sandboxing dei plugin, nessun flusso di consenso graduale; nessuna verifica di provenance, quindi nessuna firma crittografica che collega un plugin pubblicato al proprio repository di origine; le credenziali sono vietate in variabili d'ambiente e header HTTP, ma senza un'alternativa portabile che le sostituisca; nessuna allowlist, blocklist o registro con ambito organizzativo per un controllo centralizzato enterprise; nessun audit trail standardizzato per installazione, abilitazione, aggiornamento o disinstallazione; e nessuna risoluzione delle dipendenze tra plugin.

Un esempio enterprise

Un'azienda che ha già costruito una skill interna per interrogare il proprio data warehouse, abbinata a un server MCP che espone le query autorizzate, si trova davanti a una scelta reale con l'arrivo di questo standard: impacchettare i due componenti in un plugin Agent Plugins rende la distribuzione interna più semplice, un solo pacchetto per tutti i team che usano client diversi, invece di mantenere build separate. Ma quella comodità arriva senza i controlli che un reparto sicurezza si aspetta da un canale di distribuzione interno: nessuna firma che garantisca che il plugin scaricato sia davvero quello pubblicato dal team dati, nessuna allowlist che impedisca a un client non autorizzato di caricarlo, nessun audit log di chi lo ha installato e quando. La decisione corretta oggi non è "adottare" o "ignorare" lo standard, è continuare a distribuire skill e server MCP attraverso il canale interno già controllato (repository privato, revisione del codice, gestione dei segreti esistente) e trattare il packaging Agent Plugins come un formato di interoperabilità tra client, non come un sostituto dei controlli di sicurezza che l'organizzazione già applica.

Perché conta per chi decide

Per chi valuta come distribuire estensioni di un agente su più client AI, Agent Plugins merita di essere seguito perché arriva con il sostegno di un comitato multi-vendor reale (non un formato proprietario travestito da standard) e riduce concretamente il lavoro di manutenzione multi-client. Ma adottarlo alla lettera come unico canale di distribuzione enterprise nella versione 1.0.0 significherebbe rinunciare temporaneamente a permessi, provenance, allowlist e audit trail, cioè esattamente i controlli che una funzione di sicurezza aziendale richiede prima di autorizzare un canale di distribuzione interno. La mossa prudente è adottare il formato per l'interoperabilità tra client mantenendo i controlli di governance nel proprio processo di distribuzione, e rivalutare quando le versioni successive della specifica coprono i gap che il progetto stesso ha già dichiarato.