Le API avevano un tempo un modello di traffico semplice. Uno sviluppatore si registrava, otteneva una chiave, scriveva un'integrazione e quell'integrazione chiamava i tuoi endpoint secondo una pianificazione o quando un utente faceva clic su qualcosa. La gestione dei bot per API è nata attorno a quel modello: autenticare la chiave, limitare il volume, filtrare il traffico chiaramente abusivo e mantenere il servizio disponibile per tutti gli altri.
Quel modello vale ancora, e gli strumenti costruiti per esso contano ancora. Ciò che è cambiato è chi si trova dietro le chiamate. La stessa API key può ora trasportare richieste da una persona che usa la app del tuo cliente, da una persona che ha chiesto a un assistente AI di fare il lavoro e da un agente autonomo che esegue un'attività in più passaggi durante la notte. I tuoi controlli esistenti vedono una chiave e un tasso di richieste. Le decisioni di prodotto, supporto e policy spesso hanno bisogno di sapere di più.
Proof of Actor colma questo divario. Dice alla tua API chi o cosa sta agendo su ogni richiesta e indica l'evidenza, poi lascia la decisione al tuo codice. Questa pagina lo confronta con i principali livelli di protezione bot per API, così puoi vedere dove appartiene ciascuno.
La versione breve
| Protezione bot per API | Proof of Actor | |
|---|---|---|
| Domanda principale | Questa richiesta è consentita, autenticata e entro i limiti? | Chi o cosa sta agendo, e qual è l'evidenza? |
| Livelli tipici | API gateway, regole bot del WAF, API key, limiti di velocità | Classificazione dell'actor dentro la tua API o il tuo MCP server |
| Identifica | L'account o l'integrazione che possiede la chiave | L'actor dietro ogni richiesta: Human, Human + AI, Agent o Unknown |
| Output | Allow, reject, throttle; a volte un punteggio bot | Una classe più una base: verified, declared, inferred o unknown |
| Traffico poco chiaro | Di solito consentito se la chiave è valida, oppure rifiutato da una regola | Unknown, con un fallback che scegli per route |
| Chi decide la risposta | Configurazione del gateway e del WAF | Il codice della tua applicazione |
| Stato predefinito all'installazione | Enforcement | Osservazione; nulla cambia finché non aggiungi una policy |
| Dà il meglio di sé in | Disponibilità, filtraggio degli abusi, quote, responsabilità | Servire correttamente ogni actor e comprendere l'uso dell'API |
Le sezioni seguenti spiegano ogni parte.
Cosa fa bene la protezione bot per API
Vale la pena essere specifici sul lavoro che svolge ogni livello, perché Proof of Actor è progettato per affiancarsi a tutti, non per sostituirne alcuno.
API gateway
Un gateway è la porta d'ingresso della tua API. Termina le connessioni, autentica le API key o i token, instrada le richieste al servizio corretto, impone le quote e spesso registra l'utilizzo per billing e analytics. Risponde in modo rapido e coerente a "questo chiamante è autorizzato a entrare, e da quale porta?" su ogni endpoint.
Regole bot del WAF
Un web application firewall con regole bot ispeziona il traffico alla ricerca di pattern di attacco noti e automazione abusiva. Può filtrare tentativi di injection, bloccare traffico proveniente da sorgenti con una storia di abuso e challenge o scartare richieste che sembrano scraping o attacchi alle credenziali. È la tua migliore difesa contro il traffico che non dovrebbe mai arrivare al tuo codice.
API key e token
Chiavi e token ti danno responsabilità. Ogni richiesta si mappa su un account, quindi sai quale integrazione ha effettuato una chiamata, puoi revocare l'accesso e puoi attribuire l'utilizzo. I token con scope vanno oltre e limitano ciò che un chiamante può fare.
Limiti di velocità
I limiti di velocità proteggono la disponibilità. Impediscono a una sola integrazione di consumare la capacità destinata a tutti e rallentano i tentativi di brute-force e di enumerazione. I limiti per chiave e per route sono un controllo standard ed efficace.
Insieme, questi livelli rispondono molto bene alle domande su protezione e responsabilità. Mantienili.
La domanda a cui non sono stati costruiti per rispondere
Nessuno di questi livelli è progettato per dirti che tipo di actor si trova dietro una richiesta autenticata. Una chiave valida dice quale account possiede l'integrazione. Non dice:
- se questa chiamata specifica è arrivata da una persona che tocca un pulsante nella app del tuo cliente,
- se una persona ha chiesto a un assistente AI di eseguire l'azione,
- se un agente autonomo ha effettuato la chiamata come un passaggio di un'attività più lunga,
- oppure se non è possibile dirlo.
Questa distinzione conta sempre più ogni mese. Una API che serve un'integrazione CRM, uno strumento di pianificazione o una piattaforma per sviluppatori riceve sempre più traffico di agenti attraverso le stesse chiavi che servono app guidate da persone. Se vuoi dare agli agenti una risposta strutturata, richiedere conferma per scritture ad alto impatto guidate da agenti, etichettare gli invii assistiti dall'AI o semplicemente misurare quanta parte dell'uso della tua API è guidata da agenti, ti serve il contesto dell'actor.
Cosa aggiunge Proof of Actor a una API
Proof of Actor restituisce una delle quattro classi per ogni interazione:
- Human: i segnali osservabili indicano un'interazione guidata da una persona.
- Human + AI: una persona ha guidato l'interazione con assistenza AI dichiarata o osservata tramite un'integrazione supportata.
- Agent: interazione automatizzata o di origine agentica.
- Unknown: l'evidenza non supporta una determinazione affidabile.
Ogni risultato indica anche la sua base dell'evidenza:
- Verified: per esempio, una HTTP Message Signature (RFC 9421) verificata rispetto a una chiave pubblicata.
- Declared: il client o la tua applicazione lo ha dichiarato.
- Inferred: segnali comportamentali o contestuali, chiaramente etichettati come inferenza.
- Unknown: nessuna base affidabile.
Per le API, la base verified è particolarmente utile. Gli agenti che firmano le proprie richieste possono essere verificati rispetto alle loro chiavi pubblicate, ed è l'approccio alla base del lavoro IETF Web Bot Auth. Leggi la spiegazione di Web Bot Auth per i team di prodotto per il contesto e la guida su verificare richieste di agenti firmate per la parte di implementazione.
Qui conta un limite. Una firma valida dimostra quale chiave ha firmato la richiesta. Non dimostra che l'agente sia autorizzato a eseguire l'azione. L'autorizzazione resta dove deve stare, nel controllo degli accessi della tua API. La voce su autorizzazione degli agenti spiega la differenza.
Punteggi e chiavi rispetto all'evidenza dell'actor
Alcuni prodotti di protezione bot associano un punteggio a ogni richiesta. Un punteggio è efficiente per una decisione di blocco. È meno utile per le decisioni di prodotto API, perché non ti dice se una richiesta legittima è stata guidata da una persona o da un agente, e non separa i fatti verificati dall'inferenza.
Le API key hanno il limite opposto. Sono precise sulla proprietà e silenziose sull'actor. La chiave di un cliente può trasportare tutte e quattro le classi in un'ora sola.
Proof of Actor mantiene entrambe le distinzioni visibili. La tua API vede l'account dalla chiave, la classe dell'actor da Proof of Actor e la base che la supporta. Ogni livello risponde alla domanda che sa gestire meglio.
Dove gira ciascuno
Gateway e WAF girano al bordo della tua rete o davanti ai tuoi servizi. Quella posizione è corretta per protezione e quote.
Proof of Actor gira dove vive la logica della tua API. I team fondatori possono integrarlo tramite middleware Node.js, Next.js, un livello edge che controlli, la generica API HTTP o un'integrazione per MCP server. Vedi integrazioni per l'elenco completo. Poiché gira dentro la tua applicazione, può usare ciò che la tua API conosce: la route, il workflow, se un client si è dichiarato e se una firma è stata verificata.
Le decisioni di routing restano nel tuo codice
Proof of Actor non blocca nulla per impostazione predefinita. Parte in modalità di osservazione, quindi installarlo non cambia il modo in cui la tua API risponde. Vedi il tuo mix di actor per endpoint, rivedi l'evidenza dei singoli risultati e osserva il tuo tasso di Unknown.
Quando sei pronto, scrivi policy definite dall'applicazione per route, per classe di actor e per base. Gli esiti tipici sono:
- Allow: servire la richiesta normalmente.
- Adapt: restituire una risposta strutturata o ridotta per un agente verified.
- Challenge: richiedere un passaggio aggiuntivo di conferma, per esempio l'approvazione umana su una scrittura ad alto impatto.
- Review: mettere l'azione in coda affinché una persona la controlli.
- Rate-limit: applicare un limite più stretto a una classe e base specifiche su una route specifica.
Puoi visualizzare in anteprima una policy sul traffico reale prima di applicarla, poi applicarla route per route. La guida su rilascio sicuro di policy consapevoli dell'actor copre il processo, e proteggere azioni sensibili senza bloccare gli agenti mostra i pattern comuni.
Gestire i chiamanti API Unknown
Ogni API riceve traffico che non può essere classificato con fiducia. Con i controlli tradizionali, una chiave valida di solito significa che la richiesta passa, e una non valida significa che non passa. Non c'è nulla nel mezzo.
Proof of Actor ti offre un risultato esplicito Unknown e ti permette di scegliere il fallback per route. Gli endpoint di catalogo in sola lettura possono restare aperti. Le modifiche all'account possono mantenere i controlli più rigorosi già presenti. Le esportazioni massive possono andare in review. Vedi gestione del traffico Unknown e traffico automatizzato Unknown per i dettagli.
Come si combinano
La configurazione API più forte usa ogni livello per il proprio lavoro:
- Al bordo, il WAF filtra il traffico abusivo e malformato.
- Al gateway, le chiavi vengono autenticate, le quote vengono applicate e l'utilizzo viene registrato.
- Dentro l'API, Proof of Actor classifica ogni richiesta che passa e ne indica la base.
- Nei tuoi handler, le policy usano la classe e la base per scegliere la risposta: gestione normale per una chiamata guidata da una persona, una risposta strutturata per un agente verified, un passaggio di conferma per una scrittura ad alto impatto guidata da un agente, un fallback per Unknown.
- Nelle analytics, il tuo team vede quali endpoint e workflow usa ogni classe di actor, insieme ai dati dell'account provenienti dal gateway.
Niente in questo stack è duplicato. Il gateway conosce l'account, il WAF conosce i pattern di minaccia e Proof of Actor conosce l'actor.
Quando concentrare l'attenzione su ciascuno
Concentrati prima sulla protezione bot per API quando i tuoi problemi principali sono abuso, disponibilità o utilizzo non misurato: attacchi alle credenziali contro gli endpoint di autenticazione, scraping aggressivo o un'integrazione che toglie capacità alle altre.
Concentrati su Proof of Actor quando le tue domande principali riguardano i chiamanti: quanta parte del traffico della tua API è guidata da agenti, quali agenti chiamano quali endpoint, dove l'uso guidato da persone e quello guidato da agenti differiscono e quali route hanno bisogno di una policy consapevole dell'actor. Il caso d'uso API e identificazione di agenti AI per API entrano più nel dettaglio.
La maggior parte dei team che gestiscono una API in produzione ha bisogno di risposte a entrambe.
Inizia
Proof of Actor è in beta privata. I team fondatori selezionati possono ricevere fino a 12 mesi di accesso gratuito entro i limiti di utilizzo concordati, senza fatturazione automatica. Richiedi l'accesso anticipato e raccontaci dell'API e dei chiamanti che vuoi comprendere.