Salta al contenuto principale
AUTOMAZIONE VERIFICATA

Riconosci le richieste automatizzate verificate

Quando un client automatizzato firma le proprie richieste, la tua application può verificare quella firma e trattare il chiamante di conseguenza. Proof of Actor trasforma quel controllo in un risultato chiaro e instradabile.

Richiedi accesso anticipatoEsplora come funziona
Toshendra Sharma

Di Toshendra SharmaFondatore e CEO, AgentCredia · Updated November 13, 2026

Non tutto il traffico automatizzato è uguale

I client automatizzati raggiungono la tua application ogni minuto: crawler di ricerca, strumenti di monitoraggio, integrazioni con partner, assistenti AI che recuperano pagine per un utente e agent autonomi che completano attività. Per anni, il solo modo in cui la maggior parte delle application poteva distinguerli era l'header user-agent, una stringa che qualsiasi client può impostare come vuole.

Questo mette i team applicativi in una situazione difficile. Trattare tutta l'automazione con sospetto degrada l'esperienza degli agent legittimi da cui dipendono i tuoi clienti. Fidarsi dell'header significa invitare chiunque a dichiararsi un crawler noto.

Le richieste automatizzate verificate cambiano il quadro. Quando un client automatizzato firma le proprie richieste con una chiave che ha pubblicato, la tua application può controllare la firma e sapere, in modo crittografico, quale client ha firmato la richiesta. Proof of Actor rende questo controllo parte di un unico risultato coerente dell'actor su cui il tuo codice può instradare. Per un esame più approfondito di ciò che quel controllo stabilisce e non stabilisce, leggi cosa provano le richieste firmate di agent AI.

Come funziona la firma delle richieste

L'approccio emergente per il traffico automatizzato usa HTTP message signatures, standardizzate in RFC 9421, che definisce come creare, codificare e verificare firme sui componenti di un messaggio HTTP. Il client firma parti selezionate di ogni richiesta con una chiave privata e include la firma e i relativi parametri negli header. Pubblica la chiave pubblica corrispondente in una posizione collegata a un identificatore che controlla, in genere il proprio dominio.

Quando la richiesta arriva, il destinatario recupera o cerca la chiave pubblicata, ricostruisce il contenuto firmato e controlla la firma. Se convalida, la richiesta è stata firmata dal possessore di quella chiave. Il lavoro sulla firma del traffico automatizzato continua nell'IETF Web Bot Auth working group, il cui mandato copre l'autenticazione crittografica di client automatizzati come crawler e agent AI che agiscono per utenti finali; la voce del glossario Web Bot Auth ne riassume i contenuti. Il post del blog su cosa provano le richieste firmate di agent AI illustra una richiesta verificata end to end, e il caso d'uso APIs mostra dove la verifica porta valore per prima.

La guida su verificare le richieste firmate degli agent descrive in dettaglio la meccanica, inclusi timestamp, finestre di replay e caching delle chiavi.

Cosa prova una firma verificata, e cosa no

Questa distinzione è la parte più importante per gestire bene le richieste automatizzate verificate.

Una firma valida prova che la richiesta è stata firmata con una chiave associata all'identificatore pubblicato. Se la chiave appartiene al dominio di un operatore, la richiesta proviene da un client che possiede la chiave di quell'operatore.

Una firma valida non prova:

  • chi ha istruito l'agent, o se una persona ha chiesto questa azione;
  • che una persona abbia delegato autorità all'agent;
  • l'identità legale nel mondo reale dietro l'operatore;
  • che l'azione richiesta sia sicura o consentita nella tua application.

Sono domande separate. La tua application le risponde con le proprie credenziali, il proprio modello di autorizzazione e la propria policy. Proof of Actor le mantiene deliberatamente distinte, e la pagina su Detection & Limitations spiega esattamente cosa può stabilire ciascun tipo di evidenza.

Come Proof of Actor gestisce le richieste automatizzate verificate

Detect

La tua integrazione passa il contesto della richiesta, inclusi eventuali header di firma, a Proof of Actor. Le firme vengono verificate rispetto alle chiavi pubblicate. Le richieste che convalidano vengono registrate con base verified. I client che si limitano a dichiararsi vengono registrati come declared. I pattern comportamentali vengono registrati come inferred. Quando non c'è abbastanza su cui basarsi, il risultato è Unknown. Nulla viene promosso a verified senza che un controllo crittografico sia passato.

Understand

Vedi quali operatori verified chiamano la tua application, quali route usano, con quale frequenza e come questo si confronta con l'automazione declared e Unknown. Il riepilogo delle evidenze su ogni risultato ti dice quale chiave e quale identificatore erano coinvolti, così il tuo team può analizzare rapidamente ogni richiesta.

Route

Usa la base nelle tue policy. I modelli comuni includono:

  • Dare agli agent verified una risposta strutturata sulle route di sola lettura, come una API o una versione Markdown di una pagina.
  • Aumentare i limiti di rate per gli operatori verified che riconosci, mantenendo i limiti standard per i client declared.
  • Mantenere la tua autorizzazione esistente su ogni route di scrittura, qualunque cosa dica la firma.
  • Definire un fallback esplicito per i chiamanti unsigned e Unknown su ogni route.

Le tue policy decidono; Proof of Actor fornisce l'evidenza.

Perché l'header user-agent non basta

Le stringhe user-agent sono dichiarazioni. Qualsiasi client può inviare qualsiasi valore, e lo user-agent spoofing non richiede competenze. Per questo gli operatori di crawler pubblicano i propri controlli: Google documenta le lookup DNS reverse e forward e gli intervalli IP pubblicati per verificare Googlebot, Bing documenta un controllo DNS per verificare Bingbot, e OpenAI pubblica file di intervalli IP per ciascuno dei suoi crawler e user agent. Proof of Actor tratta una dichiarazione user-agent come evidenza declared, mai come verifica. Questo significa che un client che si presenta come un crawler noto senza una firma valida viene riportato con base declared o inferred, e la tua policy può trattarlo in modo diverso da un client che ha provato la propria identità.

Questo è ciò che rende preziose le richieste automatizzate verificate: ti offrono un modo affidabile per estendere fiducia ai client che se la guadagnano, senza estenderla a chiunque copi il loro header.

Evidenza di identità, credenziali e autorizzazione

Tre livelli lavorano insieme in qualsiasi application che serva client automatizzati:

  1. Evidenza di identità: quale client ha firmato questa richiesta? Una firma verificata risponde a questa domanda.
  2. Credenziali: quale account è responsabile? La tua API key, token o session risponde a questa domanda.
  3. Autorizzazione: questo chiamante può farlo? Il tuo modello di permessi risponde a questa domanda.

Proof of Actor rafforza il primo livello e lo rende visibile. Non emette credenziali di identità o delega, e non sostituisce la tua autorizzazione. Tenere separati i livelli è ciò che ti permette di essere generoso con gli agent verified sulle route a basso rischio e prudente su quelle ad alto impatto.

Dove si inserisce

Proof of Actor si colloca accanto al tuo gateway, all'autenticazione e al rate limiting. Le integrazioni girano come middleware lato server, all'edge, nel tuo MCP server o tramite una generica integrazione HTTP, con supporto pratico fornito insieme a ogni team fondatore. Se il tuo traffico è soprattutto API e strumenti, i casi d'uso APIs e MCP Servers mostrano i pattern più importanti.

Inizia in modalità di osservazione

Ogni integrazione inizia in modalità di osservazione. I risultati vengono registrati senza cambiare il modo in cui la tua application risponde, così puoi vedere quanta parte del tuo traffico automatizzato è verified, quali operatori stanno firmando e dove il tasso Unknown è più alto. Le policy arrivano più tardi, route per route, quando l'evidenza le supporta. How It Works illustra l'intero flusso.

Dettagli pratici che rendono affidabile la verifica

Il controllo delle firme è affidabile solo quanto i dettagli che lo circondano. Alcune pratiche rendono le richieste automatizzate verificate affidabili in produzione.

Controlla la freschezza

RFC 9421 definisce i parametri di firma created e expires, e le richieste firmate di solito li contengono. Rifiuta le firme fuori da una finestra breve, così una richiesta intercettata non può essere riprodotta più tardi.

Metti in cache le chiavi in modo sensato

Recuperare le chiavi pubblicate di un operatore a ogni richiesta aggiunge latenza. Metti in cache per un periodo ragionevole e aggiorna quando una firma fallisce con un key identifier sconosciuto, così la rotazione delle chiavi non provoca falsi fallimenti.

Firma le parti giuste della richiesta

Una firma che copre solo un timestamp prova ben poco. Controlla che i componenti firmati includano il method, il path e l'host, così la firma si vincola alla richiesta che la tua application ha effettivamente ricevuto.

Registra l'evidenza

Conserva il key identifier, l'identificatore pubblicato e il risultato con ogni richiesta verified. Quando succede qualcosa di insolito, il tuo team può vedere esattamente quale client ha firmato cosa e quando.

Proof of Actor gestisce questi controlli come parte del passo Detect e riporta il risultato come una base che le tue policy possono leggere, così il codice della tua application resta semplice.

Unisciti al founding developer program

Proof of Actor è in private beta. I team di sviluppo fondatori selezionati possono ricevere fino a 12 months free di accesso, entro i limiti di utilizzo concordati, con supporto diretto all'integrazione da parte dei nostri engineer.

Se i client automatizzati raggiungono la tua application e vuoi trattare in modo diverso quelli verified, richiedi l'accesso anticipato. Raccontaci della tua application e dei chiamanti automatizzati che osservi, e ti mostreremo come si inserisce Proof of Actor.

Fonti

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

Domande frequenti

Che cos'è una richiesta automatizzata verificata?

È una richiesta di un client automatizzato la cui firma crittografica convalida rispetto a una chiave pubblicata per un identificatore noto, come il dominio dell'operatore. Mostra quale client ha firmato la richiesta.

Una firma verificata significa che l'agent è autorizzato?

No. Una firma associa una richiesta a una chiave e al relativo identificatore pubblicato. Se quel client possa eseguire un'azione è una decisione di autorizzazione separata, presa dalla tua application.

E per i client automatizzati che non firmano le loro richieste?

Proof of Actor li classifica comunque, usando evidenze declared e inferred dove disponibili, e riporta Unknown quando l'evidenza non è abbastanza forte. Ogni risultato indica la propria base.

Una stringa user-agent può verificare un client?

No. Le stringhe user-agent sono facili da imitare, quindi valgono come dichiarazione, non come verifica. Le firme crittografiche sono ciò che rende una richiesta verificabile.

Come inizio?

Richiedi l'accesso anticipato. I team fondatori iniziano in modalità di osservazione e i team selezionati possono ricevere fino a 12 months free entro i limiti di utilizzo concordati.

Scopri chi sta usando la tua app.

Private beta per un piccolo gruppo di founding developer.

Richiedi accesso anticipatoVisualizza i prezzi

Preferisci parlare prima? Parla con i fondatori