La controversia sulla privacy di Meta Muse mette alla prova le sue promesse sui permessi
Meta ha contestato un articolo secondo cui Muse avrebbe letto Messaggi privati senza autorizzazione, trasformando il dibattito sulla privacy di Meta Muse in un confronto tra versioni tecniche contrapposte.
Il columnist di Inc. Jason Aten afferma che Muse abbia fatto emergere dettagli da conversazioni private dopo che lui aveva rifiutato di concedere all'agente l'accesso a Messaggi. Meta sostiene che questa sequenza non possa verificarsi nell'architettura del prodotto che ha realizzato.
Il disaccordo è insolitamente netto. Aten afferma che Muse abbia acceduto ai dati dei messaggi mentre Full Disk Access sembrava disattivato. Meta sostiene che sia tale autorizzazione di macOS sia un connettore Muse separato debbano essere abilitati prima che l'agente possa leggere Messaggi.
Nessuna delle due versioni è stata riprodotta in modo indipendente in un test controllato. Per gli utenti, quindi, non si tratta di una normale segnalazione di bug software. Devono decidere se un agente meriti un accesso esteso mentre il suo sviluppatore e un utente non concordano su quanto accaduto.
La controversia è emersa inoltre poco dopo che Meta ha presentato Muse come un agente personale progettato per operare tra app, file, comunicazioni e servizi web. La sua utilità dipende dalla capacità di raggiungere informazioni che i normali chatbot non possono vedere.
Questo stesso accesso rende i confini del consenso centrali per il prodotto. Un agente personale diventa più utile man mano che acquisisce contesto, ma ogni connettore aggiuntivo amplia le conseguenze di uno stato dei permessi poco chiaro.
Le affermazioni sulla privacy di Meta Muse si scontrano con una testimonianza utente contrastante
Il fatto centrale non è che l'accesso non autorizzato sia stato dimostrato, ma che Meta e Aten descrivono stati dei permessi incompatibili.
Secondo la controversia originale, Aten ha notato che Muse faceva riferimento a una conversazione con il co-conduttore del suo podcast sui nuovi iPhone. L'agente avrebbe inoltre segnalato un messaggio del suo editor relativo all'avvicinarsi della scadenza per una rubrica.
Aten ha dichiarato di non aver chiesto a Muse di monitorare quelle conversazioni. Ancora più importante, ricordava di aver esplicitamente rifiutato l'accesso a Messaggi, al calendario e ad altre informazioni personali durante la configurazione.
Quando è stato interrogato, Muse avrebbe affermato di aver ricevuto testo dai banner delle notifiche in arrivo anziché leggere la cronologia dei messaggi sottostante. Aten ha poi respinto questa spiegazione dopo aver esaminato le impostazioni e lo stato di sincronizzazione dell'agente.
Ha riferito di aver scoperto che il connettore Messaggi aveva sincronizzato fino alla riga 187.462 del suo database locale di Messaggi. Una riga di database non equivale necessariamente a un messaggio completo, quindi tale cifra non dovrebbe essere descritta come 187.462 messaggi.
La cifra resta comunque rilevante. Indica una sincronizzazione del database piuttosto che la visibilità limitata e temporanea suggerita dalle anteprime delle notifiche.
Il dirigente delle comunicazioni di Meta, Andy Stone, ha contestato questa ricostruzione. Ha affermato che l'integrazione di Muse con Messaggi su Mac è interamente opt-in e richiede agli utenti di abilitare due controlli separati.
Uno è Full Disk Access, un'autorizzazione di macOS che consente al software approvato di raggiungere informazioni protette appartenenti ad altre applicazioni. Il secondo è il connettore Messaggi all'interno di Muse.
David Singleton, dirigente di Meta Superintelligence Labs, ha fornito una risposta più tecnica. Ha descritto tre passaggi distinti di autorizzazione dell'applicazione e del sistema operativo, compresa una conferma manuale nelle Impostazioni di Sistema di macOS.
Meta afferma che gli utenti debbano prima concedere Full Disk Access. Possono poi scegliere un livello di accesso a Messaggi all'interno di Muse, con le opzioni non disponibili che restano disabilitate quando l'autorizzazione di sistema è disattivata.
Secondo Singleton, modificare il controllo di sistema riavvia anche l'applicazione Muse. Meta sostiene che questi passaggi rendano improbabile un'attivazione accidentale e impediscano all'applicazione di aggirare il confine imposto dal sistema operativo.
Aten sostiene che Full Disk Access fosse disattivato quando ha controllato l'impostazione. Ciò crea la questione irrisolta al centro della controversia: quale stato dei permessi esistesse quando è iniziata la sincronizzazione, non soltanto quando è stato successivamente osservato?
Le prove pubbliche attualmente disponibili non rispondono a questa domanda. Gli screenshot possono documentare uno stato successivo, mentre i log potrebbero stabilire quando i permessi sono cambiati, quale processo ha acceduto al database e quali dati hanno lasciato il dispositivo.
Meta ha inoltre contestato la spiegazione di Muse sulla sincronizzazione delle notifiche. Singleton ha affermato che l'agente era confuso e ha generato una ricostruzione errata del proprio comportamento.
Quella risposta potrebbe risolvere un'affermazione circoscritta, ma espone un'altra debolezza. Un agente che non riesce a spiegare accuratamente la fonte dei propri dati offre agli utenti prove insufficienti per valutare comportamenti inattesi.
Perché l'accesso di Muse a Messaggi richiede più di uno screenshot delle impostazioni
La controversia non può essere risolta trattando un singolo interruttore visibile come una registrazione completa degli accessi passati.
Apple descrive Full Disk Access come l'autorizzazione che consente a un'applicazione di raggiungere file in tutto un Mac, inclusi dati provenienti da Mail, Messaggi, Safari e altre applicazioni. Gli utenti la gestiscono tramite i controlli privacy di Mac.
Questa protezione di sistema sostiene l'argomento di Meta. Una normale applicazione Mac non dovrebbe poter leggere il database protetto di Messaggi semplicemente perché richiede l'accesso.
Apple afferma inoltre che le applicazioni che richiedono l'accesso completo allo spazio di archiviazione devono essere aggiunte esplicitamente nelle Impostazioni di Sistema. Questa azione crea un confine a livello di sistema operativo esterno all'interfaccia di Muse.
Tuttavia, una schermata attuale delle impostazioni non prova automaticamente ogni stato precedente. L'autorizzazione potrebbe essere stata abilitata temporaneamente, modificata durante la configurazione, rimossa dopo l'accesso o associata a un altro processo helper.
Si tratta di ipotesi, non di conclusioni sul dispositivo di Aten. Per stabilire una qualunque di esse sarebbero necessari record del sistema operativo con marca temporale, log dell'applicazione, identificatori di processo e registri della sincronizzazione lato server.
Anche la distinzione tra autorizzazione e attivazione è importante. Un utente può approvare un'ampia autorizzazione di sistema credendo che una scelta più circoscritta nell'app limiti il modo in cui il software la utilizza.
Viceversa, un'applicazione può mostrare un connettore come abilitato pur non disponendo dell'autorizzazione di sistema necessaria per recuperare i dati sorgente. L'interfaccia dovrebbe rendere visibile questa discrepanza e spiegare se i dati sincronizzati in precedenza restano disponibili.
La ricostruzione di Meta suggerisce un consenso a più livelli. L'utente approva l'accesso al sistema operativo, seleziona un connettore, ne sceglie il livello di accesso e riavvia l'applicazione prima che i dati possano essere letti.
La stratificazione può ridurre gli accessi accidentali, ma solo se ogni livello riflette lo stesso stato effettivo. Se le etichette sono ambigue, non aggiornate o scarsamente sincronizzate, più controlli possono creare maggiore incertezza anziché un consenso più solido.
La posizione del database riportata introduce un'altra questione tecnica. Non è chiaro se quel valore rappresentasse un caricamento completato, un cursore di sincronizzazione locale, un checkpoint di indicizzazione o un altro indicatore interno.
Questa distinzione non dovrebbe essere oggetto di supposizioni. Un indice locale può indicare l'elaborazione senza dimostrare che ogni record citato abbia raggiunto un modello remoto o un server Meta.
La pagina prodotto di Muse di Meta afferma che gli utenti controllano le autorizzazioni e approvano determinate azioni. Afferma inoltre che Muse può connettersi alle app, lavorare in background e continuare dopo che l'utente chiude l'applicazione.
Queste capacità richiedono registri persistenti di ciò a cui l'agente può accedere e di ciò che ha già raccolto. Un audit dei permessi deve quindi coprire sia l'accesso attuale sia le copie conservate.
La revoca di un connettore dovrebbe rispondere chiaramente a diverse domande. Muse può ancora cercare nei contenuti sincronizzati in precedenza? I contenuti memorizzati nella cache vengono eliminati, scollegati dalle attività future o conservati in base a un'altra policy?
Il disaccordo pubblico non ha risolto queste domande sulla conservazione dei dati. Eppure sono essenziali per comprendere il significato pratico della disattivazione di un'autorizzazione.
Un'utile indagine tecnica ricostruirebbe la sequenza dall'installazione fino al primo suggerimento inatteso. Individuerebbe ogni richiesta di autorizzazione, transizione di stato, lettura del database, trasferimento di rete e recupero da parte dell'agente.
Senza questa registrazione, Meta può spiegare come il sistema è progettato, mentre Aten può documentare ciò che ha sperimentato. Nessuna delle due forme di prova, da sola, stabilisce pienamente il meccanismo.
Il vero conflitto è tra progettazione dei permessi ed esperienza utente
L'architettura di Meta può funzionare come previsto mentre l'esperienza complessiva del consenso continua a fallire per un utente.
Questa è la tensione principale nella controversia sulla privacy di Meta Muse. Meta descrive molteplici salvaguardie che dovrebbero bloccare l'accesso. Aten descrive un esito del prodotto che sembrava violare la sua scelta esplicita.
Queste posizioni non equivalgono né a una prova di condotta scorretta né a una prova di errore dell'utente. Mostrano che i sistemi di autorizzazione necessitano di comportamenti osservabili, non soltanto di controlli interni.
Per un'applicazione normale, gli utenti spesso tollerano l'incertezza sul motivo per cui è comparso un suggerimento. Un agente cambia questa valutazione perché può combinare informazioni personali, avviare attività e continuare a operare al di fuori di una conversazione attiva.
Muse è progettato per andare oltre il modello domanda-risposta di un chatbot. Può connettersi a servizi, monitorare obiettivi in corso, navigare, preparare documenti e agire attraverso più passaggi.
Ciò significa che il prodotto deve distinguere almeno quattro operazioni: vedere dati, copiare dati, ragionare sui dati e agire con i dati. Una sola etichetta di autorizzazione potrebbe non comunicare tutte e quattro.
"Leggere" potrebbe significare recuperare un singolo messaggio su richiesta. Potrebbe anche significare indicizzare anni di conversazioni affinché l'agente possa fornire in seguito suggerimenti non richiesti.
Un utente potrebbe accettare il primo comportamento e rifiutare il secondo. Se l'interfaccia non esplicita la differenza, un consenso tecnicamente valido potrebbe comunque non riflettere l'aspettativa dell'utente.
La spiegazione attribuita all'agente peggiora questa lacuna. Aten afferma che Muse ha attribuito la propria conoscenza alle anteprime delle notifiche, mentre Meta sostiene che quella risposta fosse un errore dell'AI.
I modelli linguistici di grandi dimensioni generano testo probabile anziché interrogare una ricostruzione interna garantita di ogni evento del sistema. A meno che il prodotto non colleghi le spiegazioni a log autorevoli, gli utenti possono ricevere risposte sicure ma inaccurate sugli accessi.
Questa limitazione dovrebbe orientare l'interfaccia. Domande come "Da dove hai ottenuto queste informazioni?" dovrebbero restituire un record strutturato di provenienza anziché una ricostruzione conversazionale.
Una risposta utile indicherebbe il connettore, l'elemento sorgente, l'ora del recupero, l'autorizzazione concessa e l'attività che ha utilizzato i dati. Dovrebbe inoltre mostrare se il contenuto proveniva da un dispositivo locale o da una copia remota.
È qui che gli agenti per consumatori differiscono dai normali strumenti di conoscenza. In una tradizionale base di conoscenza personale, gli utenti generalmente si aspettano che il materiale aggiunto deliberatamente diventi ricercabile.
Un agente proattivo può dedurre quando un'informazione potrebbe essere utile e mostrarla senza una richiesta diretta. Questo comportamento solleva una domanda di consenso più difficile: l'utente ha autorizzato il semplice accesso o anche l'interpretazione continua?
Meta presenta Muse come un prodotto che comprende gli obiettivi e fa avanzare il lavoro in background. La proattività non è quindi una funzionalità accessoria. Fa parte della proposta di valore.
Tuttavia, un suggerimento proattivo basato su una conversazione privata può risultare invasivo anche quando l'accesso era tecnicamente autorizzato. L'agente ha oltrepassato un confine contestuale, portando una comunicazione in un altro flusso di lavoro.
La sfida delle autorizzazioni è quindi più ampia della semplice verifica che un interruttore fosse attivo. Meta deve dimostrare che gli utenti possono prevedere cosa indurrà l'agente a fare un connettore abilitato.
Se l'indagine rilevasse che Aten ha abilitato brevemente l'accesso, Meta dovrebbe comunque spiegare perché l'interfaccia e la cronologia delle attività non hanno reso evidente la sincronizzazione risultante.
Se rilevasse che non era presente alcuna autorizzazione richiesta, il problema diventerebbe un diretto fallimento di sicurezza o implementazione. Le prove attuali non giustificano una scelta tra questi esiti.
La storia di fiducia di Meta aumenta il costo dell'ambiguità
Un evento di accesso contestato diventa più difficile da contenere quando lo sviluppatore porta già con sé una lunga storia di controversie sulla privacy.
Meta è entrata nel mercato degli agenti con uno svantaggio in termini di fiducia. Gli utenti non valutano Muse come il prodotto isolato di una startup senza una storia aziendale.
L'azienda ha affrontato anni di controllo normativo, contenziosi e critiche sul modo in cui Facebook e servizi correlati hanno gestito le informazioni personali. Questa storia non prova l'accusa di Aten.
Cambia però l'onere della prova. Una smentita categorica può soddisfare chi si concentra sull'architettura delle autorizzazioni documentata, mentre altri richiederanno registri del dispositivo e del server.
Muse è stato lanciato negli Stati Uniti l'8 settembre 2026 come agente personale per adulti. Meta ha sottolineato privacy e sicurezza descrivendo al contempo una macchina virtuale dedicata per l'agente di ciascun utente.
La copertura del lancio dell'epoca ha osservato che Muse poteva gestire attività che spaziavano da calendari e acquisti a e-mail e viaggi. L'ampiezza del prodotto rende la fiducia un requisito per l'adozione.
Meta ha inoltre rilasciato un'applicazione Mac che può lavorare con file locali, Messages, Calendar e Notes quando gli utenti concedono l'autorizzazione. L'accesso desktop offre a Muse un contesto che un assistente solo web non può ottenere.
Questo vantaggio mette Meta in competizione con altri produttori di agenti che perseguono il controllo del browser, l'uso del computer, il contesto locale e la memoria persistente. Il settore include prodotti di OpenAI, Anthropic, Google e sviluppatori di agenti più piccoli.
Il confronto rilevante non riguarda quale azienda produca il chatbot più capace. Riguarda quale fornitore possa rendere un accesso ampio comprensibile, reversibile e verificabile.
Una preoccupazione di sicurezza separata è emersa poco dopo il lancio di Muse. Il ricercatore di sicurezza Patrick Wardle ha segnalato una vulnerabilità relativa a materiale di autenticazione nell'applicazione Mac, che Meta ha corretto.
Il zero-day segnalato riguardava malware già in esecuzione nell'account di un utente, non lo stesso meccanismo denunciato da Aten. Non dovrebbe essere presentato come prova di accesso non autorizzato a Messages.
Rafforza però la necessità di visibilità. I team di sicurezza e gli utenti devono sapere quali risorse un agente può raggiungere, quali credenziali detiene e quali azioni sono avvenute.
Un altro utente, lo YouTuber Matt Robb, ha sostenuto separatamente che Muse avesse gestito male un'attività su Facebook Marketplace e condiviso il suo indirizzo con un acquirente. Secondo quanto riferito, Meta stava esaminando quell'episodio.
Anche in questo caso, l'affermazione riguarda un'azione in uscita anziché l'accesso ai Messages di Aten. Combinare gli eventi in un unico schema dimostrato sovrastimerebbe le prove.
Insieme, illustrano due aspetti del rischio degli agenti. Un agente può recuperare più informazioni del previsto, oppure può usare informazioni autorizzate in un'azione inaspettata.
Le autorizzazioni tradizionali sono state progettate per applicazioni che aprono file o utilizzano hardware. Gli agenti aggiungono pianificazione, inferenza, memoria ed esecuzione tra servizi dopo che l'accesso è stato concesso.
Questo rende più difficile la progettazione basata sul privilegio minimo. Un agente del calendario può avere bisogno dei titoli degli eventi ma non degli allegati. Un agente per gli acquisti può avere bisogno della città di consegna ma non di un indirizzo completo fino al checkout.
Muse necessita di controlli che corrispondano a queste distinzioni a livello di attività. I connettori ampi sono più facili da costruire e spiegare, ma trasferiscono agli utenti una maggiore responsabilità interpretativa.
La reputazione di Meta significa che ogni risultato inspiegato verrà letto alla luce di fallimenti passati. L'azienda può ridurre questa pressione solo con prove che utenti e ricercatori indipendenti possano esaminare.
Cosa devono dimostrare le autorizzazioni di Meta Muse
La risposta più forte sarebbe una ricostruzione riproducibile dell'incidente e una modifica del prodotto che renda più semplici da risolvere controversie simili.
La spiegazione esistente di Meta si concentra su ciò che l'applicazione Mac dovrebbe richiedere. Il passo successivo è mostrare cosa è accaduto sul dispositivo coinvolto.
Ciò potrebbe includere una cronologia esaminata congiuntamente basata sui registri dell'applicazione, sulle registrazioni delle autorizzazioni macOS, sulla cronologia dei connettori e sugli eventi di sincronizzazione lato server. Il contenuto sensibile dei messaggi non richiederebbe divulgazione pubblica.
L'esame dovrebbe rispondere a quando sia stato concesso, se mai lo è stato, l'accesso completo al disco e a quale eseguibile. Dovrebbe identificare quando il connettore Messages ha cambiato stato e quale azione dell'utente ha causato il cambiamento.
Dovrebbe inoltre spiegare la riga 187,462. Se quel numero era un cursore locale anziché una registrazione di contenuto caricato, Meta dovrebbe descrivere la differenza in linguaggio semplice.
Se i dati dei messaggi hanno raggiunto i sistemi di Meta, l'azienda dovrebbe spiegarne l'ambito, la conservazione e lo stato di eliminazione. Se non hanno mai lasciato il Mac, dovrebbe mostrare come Muse abbia generato i suggerimenti.
L'azienda dovrebbe evitare di basarsi sulla spiegazione dell'agente stesso. Meta ha già dichiarato che Muse era confuso quando ha descritto la sincronizzazione delle notifiche, rendendo quella risposta una prova inaffidabile.
Un registro delle attività offrirebbe una risposta migliore. Ogni suggerimento potrebbe includere un controllo "Perché vedo questo?" collegato a registri di sistema immutabili.
Il registro dovrebbe distinguere il recupero dall'azione. Leggere un messaggio per rispondere a una richiesta diretta è diverso dall'indicizzare continuamente le conversazioni o inviare informazioni a un altro servizio.
Le schermate delle autorizzazioni dovrebbero inoltre mostrare le conseguenze prima dell'attivazione. "Leggi Messages" è meno informativo di "sincronizza la cronologia dei messaggi e usala per suggerimenti proattivi".
Gli utenti hanno bisogno di una scelta separata per la sincronizzazione storica, il monitoraggio continuo e il recupero specifico per attività. Tali controlli consentirebbero a qualcuno di concedere l'accesso senza accettare ogni forma di proattività.
La revoca necessita della stessa chiarezza. Quando un utente disattiva l'accesso, Muse dovrebbe indicare se ha eliminato i dati memorizzati nella cache, interrotto la nuova raccolta o semplicemente disconnesso la fonte in tempo reale.
Per gli acquirenti aziendali, gli amministratori probabilmente richiederanno registri di audit esportabili e policy per i connettori. Gli utenti consumer meritano una versione leggibile della stessa responsabilità.
Un resoconto indipendente ha riassunto le posizioni contrapposte senza risolverle. Aten afferma che il database si sia sincronizzato mentre l'accesso era disattivato, mentre Meta afferma che le protezioni richieste non possono essere aggirate.
Quel divario di verifica è la storia. Riportare una delle due affermazioni come conclusione tecnica consolidata andrebbe oltre le prove disponibili.
Meta potrebbe ridurre il divario pubblicando un'analisi dettagliata post-incidente. Il documento dovrebbe trattare il comportamento osservato, il metodo d'indagine, le conclusioni, le limitazioni e qualsiasi azione correttiva.
Se l'azienda conclude che le azioni dell'utente hanno abilitato il connettore, dovrebbe dimostrare tali azioni con registrazioni anziché insinuazioni. Gli utenti dimenticano le impostazioni, ma il software dovrebbe conservare una traccia di audit.
Se rileva un problema di interfaccia o gestione dello stato, riconoscerlo non convaliderebbe necessariamente ogni accusa. Mostrerebbe che l'azienda tratta le segnalazioni di accesso inaspettato come prove ingegneristiche.
Un programma bug bounty è utile per le vulnerabilità, ma questo incidente potrebbe collocarsi tra sicurezza, progettazione del prodotto e comportamento del modello. Quel confine richiede una gestione degli incidenti più ampia della sola divulgazione di exploit.
Lo standard più ampio dovrebbe essere semplice: gli utenti non dovrebbero dover fidarsi né della spiegazione di un agente né del diagramma architetturale di un'azienda. Dovrebbero poter ispezionare ciò che è accaduto.
Tre segnali decideranno il dibattito sulla privacy di Meta Muse
La prossima fase dovrebbe essere valutata in base a prove tecniche, riprogettazione delle autorizzazioni e segnalazioni di altri utenti, in quest'ordine.
Il primo segnale è una ricostruzione documentata del caso di Aten. Un resoconto credibile stabilirebbe la cronologia delle autorizzazioni, identificherebbe il processo che ha effettuato l'accesso e chiarirebbe se i dati hanno raggiunto infrastrutture remote.
Tali prove rafforzerebbero la posizione di Meta se mostrassero una concessione esplicita seguita dalla sincronizzazione prevista. Indebolirebbero la smentita dell'azienda se l'accesso si fosse verificato senza la necessaria approvazione del sistema operativo.
Anche una conclusione secondo cui le registrazioni sono insufficienti sarebbe significativa. Un agente che gestisce comunicazioni private dovrebbe conservare metadati sufficienti per indagare un evento di accesso contestato senza esporre il contenuto dei messaggi.
Il secondo segnale è una modifica ai controlli di autorizzazione e provenienza. Meta potrebbe concludere che la propria architettura ha funzionato correttamente e decidere comunque che gli utenti necessitano di scelte più chiare.
Osservate controlli separati per le importazioni storiche, il monitoraggio in tempo reale, i suggerimenti proattivi, la conservazione e le azioni in uscita. Osservate inoltre spiegazioni a livello di fonte collegate ai registri di audit.
Tali modifiche indicherebbero che Meta riconosce la differenza tra autorizzazione formale e aspettative informate. Nessuna modifica lascerebbe in vigore la stessa ambiguità per controversie future.
Il terzo segnale è se utenti o ricercatori indipendenti riproducono il comportamento. Un singolo resoconto può identificare un problema serio, ma risultati ripetuti in condizioni documentate stabilirebbero un modello tecnico più solido.
I ricercatori dovrebbero registrare la versione di macOS, la versione di Muse, il percorso di installazione, i processi helper, lo stato del connettore e la sequenza esatta delle scelte di autorizzazione. Senza questi dettagli, segnalazioni apparentemente simili potrebbero coinvolgere meccanismi diversi.
L'assenza di ulteriori segnalazioni non dimostrerebbe che Aten si sia sbagliato. Ridurrebbe le prove di un difetto diffuso, lasciando irrisolta la sua esperienza individuale.
Meta dovrebbe inoltre pubblicare note di rilascio specifiche per versione per qualsiasi correzione rilevante. Modifiche silenziose renderebbero più difficile stabilire se i test successivi valutino lo stesso software utilizzato da Aten.
Per gli utenti che stanno valutando Muse ora, la risposta pratica non è il panico né una fiducia cieca. Esaminate sia l'accesso completo al disco di macOS sia ogni connettore all'interno di Muse prima di aggiungere dati privati.
Usate un profilo o dispositivo di test separato quando valutate il comportamento di un nuovo agente. Iniziate con fonti ristrette, ispezionate la sua attività ed espandete l'accesso solo dopo che i suoi suggerimenti corrispondono alle vostre aspettative.
Per sviluppatori e acquirenti aziendali, la lezione va oltre Meta. Le autorizzazioni degli agenti devono essere osservabili nel momento dell'accesso e spiegabili successivamente.
La controversia sulla privacy di Meta Muse rimane irrisolta perché le prove pubbliche documentano un conflitto, non un meccanismo verificato. Meta ha descritto salvaguardie e Aten ha descritto un esito che tali salvaguardie dovrebbero impedire.
Cosa meriterebbe la vostra fiducia: un'altra rassicurazione categorica, oppure una traccia di audit che mostri esattamente quando un agente ha avuto accesso ai vostri dati, perché lo ha fatto e cosa è accaduto dopo?
