Ciò che Proof of Actor può stabilire e ciò che non può.
Una descrizione semplice delle classificazioni, delle evidenze che le sostengono, dei contesti a cui si applicano e dei limiti attorno a cui progettiamo.
- Firma della richiestavalid · sample-crawler.exampleverified
- Dichiarazione del client"research-assistant/2.1"declared
- Interazione nel browserpointer + keyboard eventsinferred
- Nessun segnale supportatoroute not instrumentedunknown
La versione breve
| Cosa Proof of Actor può dirti (quando supportato) | Cosa non può garantire |
|---|---|
| Se una firma della richiesta dell'agent supportata è valida | Che l'agente sia affidabile, sicuro o autorizzato a eseguire qualsiasi azione |
| Se una sessione espone determinati segnali di interazione o automazione | Che un umano non abbia usato AI al di fuori della tua integrazione osservabile |
| Se l'uso di AI è stato dichiarato o osservabile in un flusso di lavoro supportato | Rilevamento universale di assistenza AI, contenuti copiati o un altro dispositivo |
| Che l'evidenza fosse insufficiente | Che un'interazione sconosciuta sia malevola |
La disponibilità dipende dalla tua integrazione e dai controlli abilitati. Il proprietario dell'applicazione mantiene il controllo sulle decisioni di applicazione.
Classificazioni
Quattro classi pubbliche. Ognuna ha un significato definito e un limite esplicito.
- Umano
I segnali osservabili supportati indicano un'interazione guidata da una persona.
Non significa: Che non sia stata usata AI, oppure che l'identità reale della persona sia verificata.
- Umano + IA
L'assistenza AI è stata dichiarata, oppure rilevata da un'integrazione supportata che può effettivamente osservarla.
Non significa: Che tutto l'uso nascosto di AI possa essere rilevato, incluso un altro tab o un altro dispositivo.
- Agente
Interazione automatizzata o di origine agente, supportata da un'identità verificabile o da un'inferenza attentamente qualificata.
Non significa: Che l'agente sia autorizzato, sicuro o stia agendo con una delega valida da parte di una persona.
- Sconosciuto
L'evidenza disponibile non supporta una determinazione affidabile.
Non significa: Che l'interazione sia sospetta o malevola.
Verificato, dichiarato, inferito, unknown
Ogni risultato riporta una base. Una classe non maschera mai un'inferenza come verifica crittografica, cosa che conta soprattutto per le applicazioni sensibili alla sicurezza.
- verified
- Verificato. Un'affermazione crittografica o comunque verificabile, convalidata, per esempio una firma della richiesta contro una chiave pubblicata. Dimostra solo quel controllo, nulla di più.
- declared
- Dichiarato. L'attore o la tua applicazione lo ha dichiarato, ad esempio una disclosure di assistenza AI o un client che si definisce agente. Una dichiarazione può essere falsa.
- inferred
- Inferito. Una conclusione ricavata da segnali comportamentali o contestuali. Le inferenze possono essere errate e sono sempre etichettate come inferenze.
- unknown
- Sconosciuto. Non ci sono prove sufficienti per una determinazione. Il risultato viene riportato come Unknown invece di essere ipotizzato.
Quando un valore di confidenza richiederebbe dietro di sé un modello testato e calibrato, usiamo invece la forza qualitativa dell'evidenza. Non vedrai da parte nostra un valore come 99.7% human a meno che non sia stato misurato e spiegato.
Contesti supportati e loro limiti
Browser
Un collector del browser vede le sessioni interattive nelle pagine in cui è attivo. Non può vedere i client che non eseguono JavaScript, l'attività in altre schede, applicazioni o dispositivi, né il testo che una persona abbia copiato da altrove.
Server e API
Un'integrazione lato server vede il contesto della richiesta e, dove i client lo supportano, le firme delle richieste. Non può vedere lo schermo di una persona e la maggior parte dei client non firmati può descriversi come preferisce.
MCP
Un MCP server vede i dettagli dichiarati del client e le chiamate agli strumenti che effettua. Un nome client dichiarato è una dichiarazione, non una verifica.
Due limiti da capire
Testo generato da AI da un'altra scheda o dispositivo
Se una persona fa una domanda a un chatbot in un'altra scheda, o sul telefono, e incolla la risposta nel tuo form, il traffico web ordinario di solito non mostra nulla al riguardo. La sessione sembra human-directed perché un human l'ha diretta.
Proof of Actor segnala Human + AI solo quando l'assistenza è stata dichiarata, o osservata da un'integrazione supportata che può effettivamente vederla, come la funzionalità assistente della tua app.
Cosa dimostra una request bot firmata
Una firma HTTP Message Signatures che risulta valida rispetto a una chiave pubblicata mostra che la richiesta è stata firmata con una chiave associata a quell'identificatore, come il dominio di un operatore.
Non stabilisce l'identità nel mondo reale di chiunque sia dietro la richiesta, né se una persona gli abbia delegato l'autorità, né se l'azione sia sicura o consentita. Gli standard in quest'area, incluso il lavoro IETF Web Bot Auth, sono ancora Internet-Drafts.
Nessun blocco predefinito
Proof of Actor non blocca, rifiuta o sfida nulla per impostazione predefinita. Sconsigliamo di bloccare o rifiutare basandosi solo su un risultato di actor inferito, e in particolare di prendere decisioni rilevanti sulle persone (occupazione, credito, servizi finanziari, istruzione o accesso a servizi essenziali) basandosi su uno di questi risultati.
L'applicazione delle policy avviene nella tua applicazione, in base a policy che il tuo team sceglie e conferma, con fallback espliciti per Unknown e per i timeout.
Unknown e astensione
Quando l'evidenza non supporta una determinazione affidabile, il risultato è Unknown. Unknown non viene mai convertito in Human e non significa sospetto. Tenerlo visibile ti mostra dove termina la tua copertura, un'informazione che ti serve prima di applicare qualsiasi enforcement.
Principi di privacy e governance
Limitazione della finalità
Le evidenze descrivono le interazioni al proprietario dell'applicazione. Non vengono usate per creare profili cross-site.
Raccolta minima
Ogni integrazione raccoglie ciò che il proprio contesto richiede. La telemetria sensibile richiede un opt-in esplicito.
Isolamento dei tenant
Le evidenze di un cliente non sono mai visibili a un altro cliente.
Conservazione configurabile
La conservazione viene concordata con ogni team fondatore durante l'onboarding.
Accesso controllato dal cliente
Decidi chi del tuo team può vedere le evidenze e i risultati.
Nessun controllo dell'identità
Nessuna raccolta biometrica e nessuna verifica dell'identità fanno parte di Proof of Actor.
Concordato con ogni team
Prestazioni e metodologia
La copertura, la percentuale di unknown, i falsi positivi e la calibrazione vengono misurati con i team Founding in ogni contesto supportato, rispetto a risultati che quei team conoscono già. La metodologia e i risultati sono pubblicati qui man mano che ogni contesto matura.
Domande su privacy o sicurezza? [email protected]