Salta al contenuto principale
COME FUNZIONA

Come funziona Proof of Actor.

Un percorso evidence-first dall'interazione in ingresso alla decisione dell'applicazione.

Richiedi l'accesso anticipatoVisualizza Detection & Limits
policy · example-app.test
  • /api/v1/catalogenforceAgenteConsenti · API strutturata
  • /support/ticketsenforceUmano + IAConsenti · etichetta come Human + AI
  • /account/*previewSconosciutoMantieni i controlli esistenti
  • /api/v1/orderspreviewAgenteRichiedi credenziali più forti

Dall'interazione alla decisione

  1. 01Richiesta o evento dell'applicazioneUna visualizzazione di pagina, una chiamata API, una chiamata strumento MCP o un'azione nell'app.
  2. 02Segnali dall'integrazione supportataSolo ciò che quell'integrazione può osservare in quel contesto.
  3. 03Normalizzazione e classificazione delle evidenzeI segnali vengono controllati, etichettati in base al fondamento e combinati.
  4. 04Risultato dell'attore con base e incertezzaHuman, Human + AI, Agent o Unknown, più su cosa si basa.
  5. 05Dashboard e analyticsTendenze, route ed evidenze da rivedere per il tuo team.
  6. 06La decisione della tua applicazioneSolo osservazione, oppure applica una policy che hai scelto.
PER GLI SVILUPPATORI

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent o Unknown.
basis
Quanto sono forti le evidenze: Verified, Declared, Inferred o Unknown.
evidence
I segnali dietro il risultato, così il tuo team può vedere il perché.

Inizia in modalità di osservazione: registra i risultati accanto ai tuoi log e non cambiare nulla finché non scegli una policy. Leggi la guida di integrazione Node.js

Observation mode è l'impostazione predefinita

L'installazione di Proof of Actor non blocca né modifica alcuna richiesta. I risultati vengono registrati in modo che il tuo team possa confrontarli con gli esiti reali dell'applicazione, esaminare i falsi positivi e decidere se una policy sia appropriata.

Tipi di evidenza

L'evidenza disponibile dipende dall'integrazione e dal contesto. I controlli per ciascun workflow vengono concordati con il team durante l'onboarding e i dettagli interni dei segnali restano privati, così sono più difficili da imitare.

  • Firme delle richieste

    Firme crittografiche da client automatizzati che pubblicano le loro chiavi.

  • Dichiarazioni

    Un client che si identifica come agent, oppure una dichiarazione di assistenza AI all'interno della tua app.

  • Segnali di interazione

    Segnali da un collector browser approvato, nelle pagine in cui viene eseguito.

  • Contesto della richiesta

    Header e dettagli del protocollo disponibili per un'integrazione lato server.

L'identità di un agent non è autorizzazione

Una richiesta firmata da un client automatizzato può mostrare che la richiesta è stata firmata con una chiave associata a un identificatore pubblicato, come il dominio di un operatore. È un'evidenza utile su quale client l'abbia inviata.

Non mostra chi abbia istruito l'agent, se una persona gli abbia delegato il permesso, l'identità legale dietro di esso o se l'azione sia sicura. Sono domande separate a cui la tua applicazione risponde con la propria autenticazione, autorizzazione e policy.

tre domande separate
  • Chi sta chiamando?Proof of Actor: firma, dichiarazione o inferenza
  • Quale credenziale?La tua chiave API, token OAuth o sessione
  • Cosa può fare?La tua autorizzazione e la tua policy

Dove si inseriscono le decisioni di routing

La tua applicazione chiama Proof of Actor, riceve un risultato e applica le proprie regole. Scegli, per route e per livello di rischio, se l'integrazione deve fallire open (la richiesta prosegue come se Proof of Actor non fosse presente) oppure fail closed (si applica il tuo controllo più rigoroso esistente).

  • Timeout API

    Se un risultato non è disponibile in tempo, la tua integrazione usa il fallback che hai scelto per quel route. Un timeout non diventa mai un risultato Human.

  • Telemetria mancante

    Se il collector del browser non è stato eseguito o un segnale è assente, il risultato lo riflette. Le evidenze mancanti riducono ciò che si può dire; non vengono trattate come sospette.

  • Classificazioni Unknown

    Unknown è un risultato normale. La tua policy definisce cosa significa Unknown per ogni route, per esempio: consentire le pagine pubbliche, mantenere i controlli esistenti sulle modifiche all'account.

  • Evidenza obsoleta

    Le evidenze hanno un tempo e un ambito. Un risultato ottenuto all'inizio di una sessione non dovrebbe essere riutilizzato per un'azione successiva più sensibile senza un controllo تازه.

Il workflow di integrazione beta

  1. 01RichiediRaccontaci della app e dell'interazione che vuoi comprendere.
  2. 02AmbitoConcorda l'integrazione, i percorsi, i limiti d'uso e la gestione dei dati.
  3. 03Integra in modalità osservazioneNessuna modifica al modo in cui la tua app risponde.
  4. 04ConvalidaConfronta i risultati con il ground truth che conosci: copertura, tasso di sconosciuti, falsi positivi, latenza.
  5. 05DecidiAbilita una policy solo dove le evidenze la supportano.

Cosa misuriamo con i team fondatori

Copertura, tasso di sconosciuti, falsi positivi rispetto a esiti noti e latenza aggiunta, in ciascun contesto supportato.

Inizia in modalità di osservazione.

Candidati per unirti al founding developer program.

Richiedi l'accesso anticipatoVisualizza Detection & Limits

Preferisci parlare prima? Parla con i fondatori