Per gran parte della storia del web, il traffico automatizzato aveva un solo compito nello stack di sicurezza: farsi identificare e farsi fermare. La gestione dei bot è nata attorno a quel compito. Si colloca all'edge della tua infrastruttura, assegna un punteggio alle request e blocca o sfida quelle che sembrano abusive. È molto brava in questo, e dovresti continuare a usarla.
Gli agent AI hanno cambiato ciò che le application devono sapere. Una quota crescente di request automatizzate ora proviene da agent che agiscono per clienti reali: un assistant che confronta i piani, un agent che invia un ticket di supporto, un client che chiama il tuo MCP server per completare un task. Allo stesso tempo, molte persone usano il tuo prodotto con un assistant AI al proprio fianco. Questi non sono attacchi. Sono utenti, e meritano l'esperienza giusta invece di una pagina di blocco.
Questo è il vuoto che Proof of Actor colma. Questa pagina confronta le due categorie in modo chiaro, così puoi vedere dove si colloca ciascuna.
La sintesi
| Gestione dei bot | Proof of Actor | |
|---|---|---|
| Domanda principale | Questa request va fermata? | Chi o cosa sta agendo, e quali sono le evidenze? |
| Dove funziona | All'edge, davanti alla tua application | Dentro la tua application, API o MCP server |
| Output tipico | Consenti, blocca o sfida; spesso un punteggio | Human, Human + AI, Agent o Unknown, più una base |
| Considera le persone assistite dall'AI come | Di solito indistinguibili dalle altre persone | Una classe distinta, Human + AI |
| Considera il traffico poco chiaro come | Spesso sfidato o bloccato | Unknown, con un fallback che scegli per route |
| Chi decide la risposta | Il set di regole dell'edge | Il codice della tua application |
| Comportamento predefinito all'installazione | Enforcement | Osservazione; nulla cambia finché non aggiungi una policy |
| Il migliore per | Fermare credential stuffing, scraping abusivo e attacchi volumetrici | Decisioni di prodotto, analytics e policy per ogni actor |
Il resto di questa pagina spiega ogni riga.
Due domande diverse
La gestione dei bot risponde a una domanda di protezione. Il suo obiettivo è tenere lontana l'automazione abusiva dalla tua infrastruttura, dai tuoi account e dal tuo inventario. Ogni segnale che raccoglie serve a questo obiettivo, e il suo output è una decisione: lasciare passare la request, bloccarla o mettere davanti una challenge.
Proof of Actor risponde a una domanda di comprensione. Il suo obiettivo è dire alla tua application chi o cosa guida ogni interazione, così puoi decidere come servirla. Il suo output non è un verdetto sulla request. È una classificazione con le sue evidenze:
- Human: i segnali osservabili indicano un'interazione guidata da una persona.
- Human + AI: una persona ha guidato l'interazione con un'assistenza AI dichiarata o osservata.
- Agent: interazione automatizzata o originata da un agent, supportata da identità verificabile o da un'inferenza qualificata.
- Unknown: le evidenze non supportano una determinazione affidabile.
Ogni risultato indica anche la sua base dell'evidenza: verified, declared, inferred o unknown. È l'informazione di cui ha bisogno una decisione di prodotto, ed è l'informazione che un punteggio di protezione non è progettato per trasportare.
Dove funziona ciascuno
La gestione dei bot di solito gira all'edge della rete o in un reverse proxy, davanti a tutto il resto. Quella posizione è esattamente giusta per la protezione. Vede il traffico in anticipo, assorbe gli attacchi prima che ti costino qualcosa e mantiene puliti i tuoi origin server.
Proof of Actor gira dove vive la logica della tua application: middleware server-side, Next.js, il livello edge che controlli, un'integrazione browser approvata, una API HTTP generica o il tuo MCP server. Quella posizione gli dà accesso a ciò che la tua application sa: quale route viene chiamata, a quale workflow appartiene, se il tuo assistant ha eseguito un'azione e se un client si è dichiarato. Vedi i percorsi di integrazione per l'elenco completo.
Poiché i due funzionano in luoghi diversi, non competono per lo stesso compito. Una request può superare la tua gestione dei bot, raggiungere la tua application e poi ricevere il contesto dell'actor che modella la risposta.
Punteggi versus evidenze
Molti prodotti di protezione esprimono il proprio giudizio come un punteggio. Un punteggio è efficiente per una decisione di blocco: scegli una soglia, agisci al di sopra di essa. È molto meno utile quando la domanda è "quale esperienza dovrebbe ricevere questo actor?"
Un punteggio non ti dice se una request a basso rischio provenisse da una persona, da una persona che lavora con un assistant o da un agent ben comportato. Non ti dice quali parti della conclusione sono state verificate e quali sono state inferite. E non può esprimere "non lo sappiamo" senza forzarlo in un numero.
Proof of Actor conserva queste distinzioni. Un risultato verified per un agent significa che una request signature è stata verificata rispetto a una chiave pubblicata, per esempio tramite HTTP Message Signatures. Un risultato declared significa che un client o la tua stessa application lo ha dichiarato. Un risultato inferred è etichettato come inferenza. E Unknown è una risposta di prima classe, non un default nascosto. Il tuo team può leggere ogni risultato e vedere esattamente su cosa si basa.
Le persone assistite dall'AI non sono bot
Il gruppo in più rapida crescita nella maggior parte delle application è formato da persone che lavorano con l'AI. Redigono messaggi con un assistant, compilano moduli con aiuto e si muovono nel tuo prodotto con uno strumento AI al loro fianco. Gli strumenti di protezione non sono stati costruiti per separarli dalle altre persone, e non hanno motivo di farlo.
Il tuo prodotto spesso sì. Potresti voler etichettare i ticket di supporto redatti con AI in modo che il team giusto li gestisca, misurare come gli utenti assistiti dall'AI si muovono nell'onboarding o offrire loro un percorso più fluido. Proof of Actor assegna a questo gruppo una classe propria, Human + AI, e la segnala solo quando l'assistenza è dichiarata o osservabile tramite un'integrazione supportata. Leggi di più nella voce di glossario interazione assistita dall'AI.
Unknown è una risposta, non una minaccia
Ogni classifier incontra traffico che non sa spiegare. I sistemi di protezione sono costruiti per essere prudenti, quindi il traffico poco chiaro spesso incontra una challenge. È una scelta sensata all'edge.
Dentro la tua application, un singolo default prudente è spesso la scelta sbagliata. Una request unknown a una pagina pubblica di documentazione e una request unknown per modificare la password di un account meritano un trattamento molto diverso. Proof of Actor restituisce Unknown come risultato proprio e ti permette di impostare il fallback per route: consentirlo nelle pagine pubbliche, mantenere i controlli esistenti nelle modifiche dell'account, inoltrarlo alla revisione nelle azioni ad alto impatto. La guida sulla gestione del traffico Unknown illustra i pattern.
Chi decide la risposta
Con la gestione dei bot, decide il set di regole all'edge. È efficiente e mantiene coerenti le decisioni su tutte le tue properties.
Con Proof of Actor, decide la tua application. Il prodotto fornisce il contesto dell'actor; il tuo codice applica la policy. Puoi servire agli agent verificati una API strutturata invece di pagine pensate per le persone, mantenere l'esperienza standard per le sessioni umane, etichettare le submission assistite dall'AI e richiedere credenziali più forti sulle azioni sensibili quando le tue condizioni lo richiedono. Le policy sono scritte per route, per classe di actor e per base, e vivono accanto al resto della tua logica di business.
Prima l'osservazione
La gestione dei bot di solito viene installata per enforce, perché tutto il suo valore sta nel fermare l'abuso.
Proof of Actor inizia in modalità osservazione. Installarlo non cambia nulla nel comportamento della tua application. Vedi la tua reale combinazione di actor per route, esamini le evidenze, visualizzi in anteprima l'effetto di una policy sul traffico reale ed effettui l'enforcement solo quando sei pronto, una route alla volta. La guida sul rilascio sicuro di policy consapevoli dell'actor descrive il processo.
Come funzionano insieme
La configurazione più solida usa entrambi, ciascuno nel proprio livello:
- All'edge, la gestione dei bot ferma credential stuffing, scraping abusivo e attacchi volumetrici.
- Nella tua application, Proof of Actor classifica il traffico che passa come Human, Human + AI, Agent o Unknown, con la sua base.
- Nel tuo codice, le policy usano quel contesto per scegliere l'esperienza: la API strutturata per un agent verificato, il flusso normale per una persona, un'etichetta per una submission assistita dall'AI, un fallback esplicito per Unknown.
- Nei tuoi analytics, il tuo team vede quali route e quali workflow usa ciascuna classe di actor, così product e security lavorano dalla stessa immagine.
Registrare la decisione dell'edge accanto al risultato dell'actor rende il quadro completo: cosa ha fatto la protezione e chi stava davvero agendo.
Quando scegliere cosa
Scegli la gestione dei bot quando il tuo problema principale è l'abuso: tentativi di account takeover, accumulo di inventario, scraping aggressivo o flood di traffico.
Scegli Proof of Actor quando la tua domanda principale riguarda i tuoi utenti: quanto del tuo prodotto è già usato dagli agent, quali agent chiamano la tua API o il tuo MCP server, dove le persone assistite dall'AI incontrano difficoltà e quali route necessitano di una policy consapevole dell'actor.
La maggior parte dei team che gestiscono una application, API o MCP server in produzione ha bisogno di risposte a entrambe le domande, ed è per questo che i due strumenti appartengono allo stesso stack.
Inizia
Proof of Actor è in private beta. I team fondatori developer selezionati possono ricevere fino a 12 months di accesso gratuito entro limiti di utilizzo concordati, con supporto diretto dal team che lo costruisce. Richiedi l'accesso anticipato e raccontaci dell'application e dell'interazione che vuoi comprendere.