10 min di lettura
Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.
Scegli l’identità prima di scegliere gli strumenti
Quando un cliente mi chiede se può far lavorare un agente AI dentro la sua piattaforma di marketing, la conversazione di solito parte da cosa l’agente può fare: quali tool, quali oggetti, lettura o scrittura. Ho iniziato a spostare quella domanda al secondo posto. La prima diventa: a nome di chi agisce l’agente? Da quella risposta dipendono cosa dirà l’audit log, come si revoca l’accesso e chi riceve la telefonata quando una campagna parte sbagliata. Questa settimana tre vendor hanno risposto in tre modi diversi, e due di loro lo hanno fatto su piattaforme che rientrano fra quelle che uso in produzione (Adobe Journey Optimizer, Adobe Campaign, Marketo Engage, Bloomreach, Braze, Insider, Iterable, Salesforce Marketing Cloud e Marketing Cloud Next).
TL;DR
- Tre vendor hanno dato allo stesso agente tre identità diverse. L’Operator Connect di Braze agisce con l’identità del singolo utente, il server MCP di Marketo eredita i permessi di un utente API dedicato e i dots specializzati di OpenAI hanno un’identità propria.
- Ogni modello sposta il lavoro di governance in un punto diverso. Una revisione dei ruoli, un utente API per caso d’uso, un owner con un nome.
- Il QA diventa un record. Agentic Standards di Braze controlla ogni campagna e Canvas e registra ogni controllo e ogni correzione.
- WhatsApp ha una seconda chiave. Bloomreach 1.319 introduce i Business-Scoped User ID e chiede ai sender esistenti un external ID.
Tre identità per un solo agente
Alla conferenza Forge del 29 settembre, Braze ha annunciato BrazeAI Operator Connect, che porta il suo Operator dentro Claude, ChatGPT, Snowflake Cortex Code, Microsoft Copilot e altri tool compatibili con MCP. L’annuncio descrive il modello di identità in una frase: “the actions are authenticated under the individual user’s identity and governed by that user’s Braze permissions.” È in beta ed estende il modello che Braze usava già per il suo server MCP remoto, reso disponibile con la release del 17 settembre. L’agente sei tu, con il tuo ruolo e i tuoi limiti.
La risposta di Adobe per Marketo Engage è diversa, e devo partire da una correzione. La MarTech Watch della settimana 40 ora registra che il Marketo Engage MCP Server è in open beta dalla release di maggio 2026, con una pagina completa nella Marketo Developer Guide di Adobe. Le edizioni precedenti lo descrivevano come non documentato perché la scansione leggeva solo la pagina delle release note correnti, ed era un errore. Sull’identità la documentazione è chiara: le credenziali viaggiano con ogni richiesta, e “Effective permissions are inherited from the Marketo API-only user assigned to the customer’s LaunchPoint service.” L’agente è un utente di integrazione, configurato da un amministratore.
OpenAI ha preso la terza strada, per gli agenti che costruisce insieme alle organizzazioni. I suoi nuovi dots, lanciati al DevDay e registrati nella AI Watch e nell’articolo AI di questa settimana, sono agenti sempre attivi con un proprio computer nel cloud e un proprio browser, e quelli che la maggior parte delle persone userà lavorano per conto dell’utente, con le autorizzazioni sulle app gestite dai controlli già presenti in ChatGPT. La pagina di lancio presenta però in anteprima anche i dots specializzati, che l’azienda configura “with its own identity, credentials, and access to the systems it needs”, e fra le prime aree in cui OpenAI li sta sperimentando cita appunto l’email marketing. Un dot specializzato non sei tu e non è un service account: è sé stesso.
Nessuno di questi modelli è sbagliato, e non li metterei in classifica in astratto, perché rispondono a domande diverse. Un’identità personale ti dice chi ha chiesto, un utente di integrazione ti dice quale connessione ha agito, e un’identità dell’agente ti dice quale agente l’ha fatto, lasciando all’organizzazione la decisione su chi ne risponde. Quello a cui resisterei, per come la vedo, è l’idea che si tratti di un dettaglio implementativo per il team di piattaforma. Da questa scelta dipende se l’audit trail di una campagna lanciata tramite un assistente AI riporta a una persona, a una credenziale condivisa o a un agente con un nome, ed è prima di tutto una decisione di governance.
Braze: il confine è la persona
Il punto di forza del modello Braze è che la revoca segue la persona. La documentazione MCP di Braze dice che se un utente della dashboard perde l’accesso in Braze, anche il client lo perde, e la release del 17 settembre ha aggiunto il provisioning SCIM che sincronizza i gruppi da Okta e Microsoft Entra ID nei ruoli custom di Braze. In uno stack dove l’identity provider gestisce già ingressi e uscite del personale, l’agente eredita quella disciplina senza che nessuno debba progettarla due volte.
Il modello eredita però anche tutto ciò che è disordinato nella base utenti. Se un team condivide un login della dashboard, lo condivide anche l’agente, e se i ruoli sono stati assegnati con generosità durante un’implementazione e mai rivisti, l’agente lavora con quei ruoli generosi. La documentazione di Braze aggiunge due limiti pratici che contano nei rollout enterprise: il server remoto non può essere usato dai clienti che si affidano all’IP allowlisting, e Braze sconsiglia di usare l’auto-mode del client per le azioni, perché la piattaforma applica chi sei, mentre è il client a decidere se una persona rivede ogni azione prima che venga eseguita.
La mia lettura pratica è che un modello a identità personale premia una revisione dei ruoli prima del pilota. È il controllo più economico disponibile, ed è appunto quello su cui l’agente farà più affidamento.
Marketo: il confine è il service account
Il modello di Marketo sarà familiare a chiunque abbia collegato un CRM o un data warehouse a Marketo Engage. Il server MCP è ospitato da Adobe, espone più di 100 operazioni su form, programmi, smart campaign, lead, email, snippet, liste e cartelle, e accetta richieste solo dalle istanze approvate, identificate dal Munchkin ID. Non conserva le credenziali fra una richiesta e l’altra ed eredita i rate limit API dell’istanza.
Il consiglio di Adobe nella documentazione è la riga che metterei nel piano di progetto: “Use a dedicated API user in Marketo with only the permissions required for your work. Do not reuse admin credentials for API access.” Le operazioni includono la creazione di smart campaign, l’aggiunta di flow step e l’attivazione o disattivazione delle campagne, e la pagina indica che i tool di creazione e aggiornamento di smart list e smart campaign sono previsti per una release di settembre 2026. Adobe dichiara anche che le integrazioni MCP sono fornite “as is”, e incoraggia i test in sandbox e un’attenta revisione di ogni azione avviata via MCP prima di farci affidamento.
In molte delle istanze Marketo su cui ho lavorato, un solo utente di integrazione serve diversi tool contemporaneamente, perché creare utenti API era considerato una seccatura amministrativa. Con un agente in gioco quell’abitudine diventa un rischio: l’audit log mostrerà l’utente di integrazione, e la persona che ha scritto il prompt non comparirà. Un utente API dedicato per ogni caso d’uso dell’agente, con un ruolo limitato a ciò che quel caso d’uso richiede, è la versione di questo modello che approverei.
Il QA diventa un prodotto, e tiene un log
Il secondo annuncio di Forge mi interessa più dell’agente di decisioning che si prenderà i titoli. Agentic Standards, anch’esso in beta con disponibilità generale prevista a ottobre, rivede ogni campagna e Canvas rispetto a regole che il brand imposta una volta sola in Braze, su setup, copy, link, personalizzazione, compliance e linee guida del brand. Ogni controllo restituisce pass, warning o fail, e insieme a Operator può applicare la correzione, “with human sign-off wherever a brand wants it.” La frase che conta è quella successiva: “Each check and fix is logged for audit.”
Il QA è sempre stato il passaggio che rallenta un lancio e il più difficile da documentare a posteriori. Un controllo registrato trasforma la revisione in un record, ed è proprio un record quello che chiedono un auditor, un’autorità di controllo o l’ufficio legale di un cliente. La stessa idea compare in forma più piccola anche altrove nel record della settimana 40. Adobe Journey Optimizer ha aggiunto la validazione degli URL nella simulazione dei contenuti, in Limited Availability, che segnala i link rotti, non sicuri o irraggiungibili prima dell’invio, e Tealium ha aggiunto alle azioni dei connettori una scheda Delivery Requirements che permette al team di decidere se un evento con requisiti non soddisfatti viene saltato o fallisce.
Per come la leggo, sono questi i controlli che rendono governabile il lavoro prodotto da un agente. Quando un agente prepara una campagna, è nella revisione che l’output acquisisce un responsabile, e se quel passaggio lascia un log, la domanda su chi ha approvato cosa smette di dipendere dalla memoria.
WhatsApp non è più solo un numero di telefono
Lontano dagli agenti, un cambiamento di questa settimana tocca direttamente il modello dati. WhatsApp sta introducendo gli username, e Meta assegna un Business-Scoped User ID, o BSUID, a ogni cliente che scrive a un account business. Bloomreach 1.319 aggiunge il supporto ai BSUID nei sender profile di WhatsApp: continua a inviare al numero di telefono quando è disponibile e passa automaticamente al BSUID in alternativa. Contiene anche un passaggio di migrazione che merita un promemoria in calendario: “Your current senders need an external ID to keep working under the new model.” Salesforce Marketing Cloud Engagement documenta lo stesso identificativo nelle release note Winter ‘27, nella parte su come raggiungere gli utenti WhatsApp che usano uno username.
Nella maggior parte degli stack che vedo, il numero di telefono è l’unica chiave WhatsApp sul profilo, e il consenso per il canale è registrato su quel numero. Un secondo identificativo apre tre domande a cui conviene rispondere prima che il primo cliente nasconda il proprio numero. Dove vive il BSUID nel modello del profilo? L’identity resolution lo tratta come chiave di match? E come si trasferisce il consenso raccolto su un numero di telefono quando quel numero non è più visibile? Nessuna è difficile, e tutte sono più facili prima della migrazione che dopo.
Tre domande prima di attivare qualsiasi cosa
Gli annunci sugli agenti continueranno ad arrivare, e prima o poi ogni vendor della watchlist risponderà alla domanda sull’identità in un modo o nell’altro. Sulla base della documentazione pubblica disponibile alla data di pubblicazione, farei tre domande a qualsiasi funzionalità agentica prima del primo pilota, qualunque dei tre modelli abbia scelto il vendor.
Con quale identità agisce l’agente, e quell’identità porta solo i permessi che servono al caso d’uso? Per un modello personale significa una revisione dei ruoli, per un utente di integrazione un utente dedicato per ogni caso d’uso, per un’identità dell’agente un owner con un nome che ne risponde.
Cosa viene registrato, e dove? Una chiamata a un tool registrata sotto una credenziale condivisa dice meno di un controllo registrato con il suo esito e con il nome di chi lo ha approvato.
Come si revoca l’accesso, e in quanto tempo? La revoca che segue la persona, l’utente di integrazione o l’agente va testata una volta, di proposito, prima che serva.
I permessi di un agente valgono quanto l’identità da cui sono presi in prestito, quindi scegli quell’identità prima di scegliere gli strumenti.
Fonti
Braze
- Braze Accelerates AI Innovation. Fonte per Operator Connect e la sua dichiarazione sull’identità, Agentic Standards e la sua dichiarazione sul log, e gli stati di beta e disponibilità generale, pubblicato il 29 settembre 2026.
- September 17, 2026 release. Fonte per la disponibilità generale del server MCP remoto e il provisioning SCIM per i gruppi dell’IdP.
- About the Braze MCP server. Fonte per la perdita di accesso insieme all’utente della dashboard, il limite sull’IP allowlisting e la raccomandazione sull’auto-mode.
Adobe
- Marketo Engage MCP Server. Fonte per le operazioni, il modello di permessi basato sull’utente API, la lista delle istanze approvate, il consiglio sull’utente dedicato, i tool previsti per smart list e smart campaign e la dichiarazione “as is”.
- Marketo Engage release notes, May 2026. Fonte per lo stato di open beta.
- Journey Optimizer release notes. Fonte per la validazione degli URL nella simulazione dei contenuti.
OpenAI
- Introducing dots. Fonte per i dots che agiscono per conto dell’utente e le loro autorizzazioni, il computer nel cloud, l’identità dei dots specializzati e le aree pilota, pubblicato il 29 settembre 2026.
Bloomreach e Salesforce
- Bloomreach release 1.319. Fonte per il supporto ai BSUID, il comportamento di fallback e la migrazione dei sender.
- Salesforce Winter ‘27 release notes, Marketing Cloud Engagement. Fonte per il supporto ai BSUID in Marketing Cloud Engagement.
Tealium
- Tealium release notes. Fonte per la scheda Delivery Requirements.
Il record
- MarTech Watch, Week 40. Ogni data e stato citato in questo articolo, la correzione sul server MCP di Marketo e i recuperi tardivi di Salesforce.
- AI Watch, Week 40. Il record sui dots.
Il digest alla base di ogni articolo settimanale è prodotto attraverso una scansione strutturata, assistita dall’AI, di release note ufficiali e fonti di product update. Io rivedo l’output, verifico i segnali rilevanti e scrivo l’interpretazione architetturale.
Questo articolo si basa sulle scansioni del Martech Weekly Digest eseguite il 1° ottobre 2026, che coprivano il periodo dal 25 settembre al 1° ottobre su diverse piattaforme CEP e vendor. Il record datato che ne sta alla base è in MarTech Watch, Settimana 40.
Se trovate errori o lacune nella copertura, voglio saperlo. Il processo migliora quando l’output viene messo in discussione.
