Personal Agent Protocol: Meta e Sierra propongono uno standard di accesso per gli agenti IA. La specifica non c'è ancora, ma la matrice dei permessi non può aspettare

Personal Agent Protocol: Meta e Sierra propongono uno standard di accesso per gli agenti IA. La specifica non c'è ancora, ma la matrice dei permessi non può aspettare

Il 6 ottobre 2026 Sierra, l'azienda di IA per le imprese fondata tra gli altri da Bret Taylor, ha annunciato insieme a Meta quello che chiamano Personal Agent Protocol (PAP): una proposta di standard aperto su come l'agente IA di un consumatore si collega a un'azienda. I partner citati nel post di Sierra sono Genesys, Instinct, Rocket, Shopify, Stripe e Walmart. Il disegno, per quanto descritto finora, è familiare a chiunque abbia realizzato un pulsante «accedi con»: sessioni basate su OAuth, un agente che può partire come ospite per verificare la disponibilità di un prodotto o le regole sui resi, e un cliente che effettua l'accesso e decide se l'agente ha accesso in sola lettura o anche in scrittura. L'azienda sceglie il canale: il sito, le API (Sierra cita MCP e OpenAPI) o un proprio agente.

Conta altrettanto ciò che ancora non esiste. Al 9 ottobre non c'è una specifica pubblicata, né una licenza, né un organismo di governo; Sierra dice che la v0.1 arriverà «entro fine mese», con workshop di progettazione e un'implementazione di riferimento. Secondo CNBC, OpenAI e Anthropic per ora non partecipano. La nostra tesi: che PAP si affermi o no, gli agenti stanno ricevendo una porta d'ingresso tutta loro, e il lavoro che ripaga con qualsiasi standard è decidere cosa un agente esterno può leggere e modificare sull'account di un cliente, e realizzarlo come accesso limitato e registrato. Di seguito: cosa è stato annunciato, cosa manca, la disputa tra Amazon e Meta sullo sfondo e una checklist sui permessi per gli MSP e i loro clienti PMI. Abbiamo letto il post di Sierra, CNBC, The Next Web e un'analisi indipendente il 9 ottobre 2026.

Cosa hanno annunciato davvero Sierra e Meta

Restiamo al post. Sierra descrive PAP come «uno standard aperto che Meta e Sierra stanno sviluppando insieme a partner del settore» e che «definisce come gli agenti personali interagiscono con le aziende», pensato «per gestire l'autenticazione, dare più potere ai consumatori e offrire alle aziende visibilità su ciò che gli agenti personali fanno». Dice che chiunque potrà implementarlo. Il problema indicato: oggi la maggior parte degli agenti personali usa i siti come le persone, caricando pagine e compilando moduli, e quando non basta può chiamare il servizio clienti o aprire una chat. Sierra sostiene che un collegamento diretto farebbe lo stesso lavoro in sicurezza in pochi secondi; è un obiettivo, non un risultato misurato. Il principio: i consumatori decidono quale accesso dare ai propri agenti, le aziende fissano i limiti di ciò che quegli agenti possono fare.

Il flusso: l'agente scopre sul sito dell'azienda cosa offre e come raggiungerla, poi apre una sessione per conto dell'utente. Per domande semplici può restare ospite. Per tutto ciò che tocca l'account, il cliente accede dalla pagina dell'azienda o usa credenziali già configurate con il proprio agente, e decide se concedere accesso in sola lettura o anche in scrittura. La sessione si basa su OAuth e prosegue tra i canali. I canali: le normali pagine web, le API «basate su standard come MCP e OpenAPI», oppure l'agente dell'azienda per i compiti che richiedono una conversazione, come una richiesta di garanzia. I prossimi passi, secondo Sierra: una specifica v0.1 entro ottobre, workshop di progettazione e un'implementazione di riferimento; permessi più granulari, notifiche push e pagamenti sono idee per dopo. Taylor l'ha detto in modo semplice a CNBC: le aziende sapranno quando hanno davanti un agente personale e quando una persona. Tony Bates, amministratore delegato di Genesys, citato nella pagina di Sierra, descrive allo stesso modo il bisogno delle aziende: sapere chi rappresenta un agente, cosa è autorizzato a fare, con quale intento e come lavorarci in sicurezza. (Citazioni tradotte o parafrasate da noi.)

Cosa manca, e chi non è al tavolo

Consideriamo PAP un annuncio, non uno standard compiuto. Al nostro controllo del 9 ottobre il post di Sierra prometteva ancora la specifica v0.1 «entro fine mese» e non rimandava a nessuna specifica, licenza o codice. Rajesh Beri, su THE D*AI*LY BRIEF, l'ha scritto chiaramente il 7 ottobre: al lancio non erano stati pubblicati né specifica, né licenza, né organismo di governo, e finché licenza e governance non esistono «aperto» resta un'intenzione dichiarata. È un buon criterio da tenere: quando arriverà la v0.1, controlla che ci sia una licenza pubblicata, un organismo di governo non controllato soltanto dai due promotori e almeno un produttore di agenti esterno a Meta che si impegni a implementarla.

Anche l'elenco dei partner per ora è ristretto. Secondo CNBC, OpenAI e Anthropic per ora non partecipano, anche se Taylor si aspetta che lo facciano e si direbbe «davvero deluso» se i concorrenti non lo usassero; Beri nota che mancano anche Amazon e Google. The Next Web osserva che nessun rivenditore, banca o società di pagamenti europea è stato indicato tra gli aderenti. E i pagamenti non sono nella prima versione: Sierra li elenca come possibile estensione futura. Un agente collegato tramite PAP, così come descritto, potrebbe quindi accedere e leggere o modificare dati dell'account nei limiti concessi dal cliente, ma non pagare. Niente di tutto questo rende debole l'idea. Significa che il codice può aspettare; le decisioni di policy no.

Lo sfondo: Amazon e l'agente Muse di Meta, le due versioni

PAP arriva nel mezzo di uno scontro sugli agenti che non si dichiarano. CNBC riferisce che Amazon è tra le aziende che hanno bloccato gli agenti di Meta, citando timori di scraping del sito. THE D*AI*LY BRIEF aggiunge dettagli: Amazon ha bloccato gli acquisti dell'agente Muse di Meta su Amazon.com il 20 settembre, sostenendo che Meta non aveva avvisato che Muse avrebbe avuto accesso al negozio, che l'agente non si identificava durante la navigazione e che sembrava acquisire e conservare le credenziali dei clienti. La risposta di Meta, come riportata lì: Muse non ha visibilità su password e metodi di pagamento delle persone. Secondo Beri, nessuno ha verificato in modo indipendente nessuna delle due affermazioni. Nemmeno noi le abbiamo verificate e non prendiamo posizione.

Il punto è strutturale. Entrambe le contestazioni, preavviso e auto-identificazione, sono proprio ciò che un protocollo di accesso dovrebbe risolvere: un agente che entra tramite OAuth si presenta come agente, con un perimetro approvato dal cliente, in una sessione che l'azienda può registrare. Se sarà PAP a farlo è ancora da vedere. Il problema che affronta, agenti che usano la password di una persona in un browser che l'azienda non vede, esiste già, ed è lo stesso problema di identità sollevato questa settimana da Wikimedia, che ha chiesto agenti facilmente identificabili dai gestori dei siti.

La matrice dei permessi: una checklist per MSP e clienti PMI

Sono nostre indicazioni, basate sullo schema a quattro livelli di Beri e sul modello di Sierra con ospite, sola lettura e scrittura.

1. Scrivi ora i quattro livelli. THE D*AI*LY BRIEF ne propone quattro: lettura da ospite (orari, disponibilità, regole sui resi, prezzi pubblicati), lettura con accesso (stato ordini, prenotazioni, saldi), scrittura reversibile con accesso (avviare un reso, spostare un appuntamento, cambiare un'impostazione di notifica) e scrittura irreversibile con accesso (acquisti, bonifici, cambi di indirizzo o di beneficiario). Per ogni cliente elenca i dieci compiti più frequenti dei suoi utenti e assegna ciascuno a un livello, con un responsabile.
2. Tieni chiuso il livello irreversibile. Secondo la stessa Sierra, la prima versione di PAP non include i pagamenti. Finché una specifica pubblicata non dice altro, le azioni irreversibili restano alla persona, con una conferma rafforzata.
3. Crea scope OAuth allineati ai livelli. Se il cliente espone già un'API, associa a ogni livello uno scope; letture con accesso e scritture reversibili stanno sull'API, dove ogni chiamata si può registrare. Questo lavoro resta valido qualunque standard si affermi.
4. Rendi visibili gli agenti nei log. Inizia a contare le sessioni che arrivano da agenti, distinte da quelle delle persone, così avrai una base prima di fissare le regole.
5. Separa i token degli agenti dalle sessioni umane. L'autorizzazione di un agente deve poter essere revocata da sola, scadere da sola e comparire nella pagina di sicurezza dell'account, così il cliente può vederla e tagliarla senza cambiare password.
6. Chiedi ai fornitori per iscritto. Se i clienti usano Shopify, Stripe o una piattaforma di contact center tra i partner, chiedi quando arriverà il supporto a PAP, con quale licenza e a che costo. Non promettere compatibilità con PAP prima che esista la v0.1.
7. Aspetta il testo prima di scrivere codice PAP. Leggi la v0.1 quando esce; controlla licenza, governance e chi si è impegnato a implementarla.

---

Riassumendo: il 6 ottobre 2026 Sierra e Meta hanno annunciato il Personal Agent Protocol, una proposta di standard aperto su come gli agenti IA personali accedono alle aziende e lavorano con loro, con Genesys, Instinct, Rocket, Shopify, Stripe e Walmart indicati come partner. Per come è descritto: sessioni basate su OAuth; accesso da ospite per domande semplici; accesso del cliente con scelta tra sola lettura e scrittura; canali tramite il sito, le API (MCP, OpenAPI) o l'agente dell'azienda. Sierra prevede una specifica v0.1 entro ottobre, con workshop di progettazione e un'implementazione di riferimento; al 9 ottobre non sono pubblicati né specifica, né licenza, né organismo di governo. Pagamenti e permessi più granulari sono idee future. Secondo CNBC, OpenAI e Anthropic per ora non partecipano. Il blocco dell'agente Muse di Meta da parte di Amazon e la risposta di Meta restano affermazioni non verificate. Il lavoro per gli MSP non dipende dall'esito: una matrice di permessi a quattro livelli, scope OAuth coerenti, sessioni degli agenti visibili e revocabili, e nessun codice PAP prima di una licenza.