Una sola policy per tutti non basta più
La maggior parte delle application è stata progettata attorno a un solo tipo di utente: una persona che naviga un'interfaccia, autenticata in un account. Il controllo degli accessi seguiva questa assunzione. Se la sessione è valida, la request passa. Se sembra automatizzata, compare un CAPTCHA o un blocco.
Quel modello si sta rompendo. Oggi la stessa application serve persone, persone che lavorano con assistenti AI e agenti autonomi che agiscono per conto di qualcuno. Alcuni agenti sono integrazioni del cliente. Alcuni sono assistenti AI che recuperano documentazione. Alcuni sono crawler. Alcuni stanno cercando di abusare del tuo prodotto. Una singola regola sì o no non può gestirli bene tutti.
Le policy di routing e accesso per agenti AI sostituiscono quella singola regola con un insieme di decisioni deliberate: quali attori ricevono quale esperienza, su quali route, in quali condizioni. Proof of Actor fornisce alla tua application le evidenze per prendere quelle decisioni e lascia le decisioni stesse nelle tue mani. Per i principi di progettazione dietro questo approccio, leggi progettare policy per app per persone e agenti AI, e guarda il caso d'uso per le SaaS apps per vedere come le policy si mappano su workflow di prodotto reali.
Come si presenta una buona policy per agenti
Una policy utile è specifica. Nomina una route o un workflow, una classe di attore, il livello di evidenza richiesto e la risposta. Per esempio:
- Route di catalogo in sola lettura: consenti agli agenti verificati e servi una risposta strutturata; consenti agli agenti dichiarati con il rate limit standard.
- Azioni che modificano l'account: mantieni la tua riautenticazione esistente per tutti; aggiungi review quando l'attore è Unknown e l'azione è ad alto impatto.
- Invii al supporto: accetta contenuti con AI dichiarati e etichettali per il routing.
- Signup: mantieni i controlli esistenti; non decidere mai solo in base a un risultato di attore inferred.
Ognuno di questi risponde all'attore senza trattare ogni agente come abuso e senza fidarsi ciecamente di ogni agente. Questo equilibrio è il punto centrale dell'accesso consapevole agli agenti, e il post del blog su progettare policy per app per persone e agenti AI sviluppa altri esempi route per route.
Le cinque risposte
La capacità di Route di Proof of Actor si basa su cinque risposte tra cui le tue policy possono scegliere.
Allow
Lascia che la request prosegua normalmente. Gran parte del traffico, incluso la maggior parte del traffico degli agenti su route pubbliche o a basso rischio, dovrebbe semplicemente essere consentito.
Adapt
Cambia l'esperienza in base all'attore. Servi una risposta API strutturata o una versione in Markdown di una pagina a un agente verificato invece di un'interfaccia pensata per persone. La guida su servire agli agenti AI contenuti strutturati copre questo pattern.
Challenge
Chiedi qualcosa di più forte: un login recente, una credenziale aggiuntiva, una conferma del proprietario dell'account. Usa challenge sulle route in cui il costo di una decisione sbagliata è alto.
Review
Fai sì che l'azione entri in una coda invece di arrivare direttamente al completamento, oppure segnalala affinché una persona la controlli. Review è utile quando bloccare danneggerebbe utenti legittimi ma il completamento senza supervisione è troppo rischioso.
Limit
Applica un limite di rate o di volume tarato sull'attore e sulla route, così i chiamanti automatizzati non possono sovraccaricare un workflow progettato per le persone.
Perché robots.txt non è una policy di accesso
Molti team iniziano con robots.txt, ed è un primo segnale sensato per i crawler. Non è una policy di accesso per gli agenti. Gli operatori dei crawler documentano comportamenti diversi per user agent diversi: Anthropic afferma che i suoi bot rispettano le direttive robots.txt (Anthropic crawler documentation), mentre OpenAI osserva che per ChatGPT-User, che agisce quando un utente fa una domanda a ChatGPT, le regole robots.txt potrebbero non applicarsi perché l'azione è avviata da un utente (OpenAI crawler documentation). Robots.txt inoltre non dice nulla su API, strumenti MCP o workflow con accesso autenticato.
Una policy di accesso deve funzionare dove la request viene gestita, leggere evidenze come una signature verificata secondo RFC 9421 e scegliere una risposta per singola route. Per i MCP server, la specifica di autorizzazione MCP definisce come i client ottengono access token su HTTP; le policy degli attori aggiungono contesto sopra questo livello, non lo sostituiscono.
Come Proof of Actor alimenta le tue policy
Ogni request che la tua integrazione valuta produce un risultato dell'attore con quattro parti che la tua policy può leggere:
- Class: Human, Human + AI, Agent o Unknown.
- Basis: verified, declared, inferred o unknown, così la tua policy può trattare una signature convalidata in modo diverso da un nome client auto-dichiarato.
- Evidence summary: una descrizione leggibile su cui si basa il risultato, utile per logging e review.
- Context: quale integrazione e quale route l'ha prodotto.
Poiché la basis è esplicita, le tue policy possono essere precise. "Allow agenti" diventa "consenti agli agenti verified sulle route di lettura, applica il rate limit agli agenti declared, usa il fallback Unknown per tutto il resto." Il flusso completo dalla request alla decisione è descritto in Come funziona.
I fallback fanno parte della policy
Una policy è efficace solo quanto il suo comportamento quando mancano evidenze. Proof of Actor rende questi casi espliciti invece di nasconderli.
- Unknown: le evidenze non supportavano una determinazione. La tua policy dice che cosa significa Unknown su ogni route. Non viene mai convertito in Human e non viene mai trattato come malevolo per impostazione predefinita.
- Timeout: il risultato non è arrivato in tempo. La tua integrazione applica il fallback che hai scelto per quella route.
- Segnali mancanti: un collector non è stato eseguito o un header era assente. Il risultato lo riflette e la tua policy lo tratta di conseguenza.
Per ogni route scegli se fail open o fail closed. Fail open significa che la request prosegue come farebbe senza Proof of Actor; fail closed significa che si applica il tuo controllo più forte esistente. Le route a basso rischio di solito fanno fail open. Le azioni sensibili di solito fanno fail closed. Lo imposti per livello di rischio, non globalmente.
Mantieni separati identità, credenziali e autorizzazione
Le policy di accesso per agenti si collocano sopra tre livelli distinti, e tenerli separati previene gli errori più dannosi.
- Le evidenze di identità rispondono a che tipo di attore sta chiamando e a cosa lo prova. Proof of Actor fornisce questo.
- Le credenziali rispondono quale account è responsabile. La tua sessione, il tuo token o la tua API key forniscono questo.
- L'autorizzazione risponde se questo chiamante può eseguire questa azione. Il tuo modello di permessi fornisce questo.
Un'identità di agente verificata non significa che l'agente sia autorizzato, che una persona gli abbia delegato l'autorità o che la sua azione sia sicura. Usa i risultati dell'attore per il routing e per aggiungere contesto. Usa il tuo modello di autorizzazione per concedere i permessi. La pagina su Detection & Limitations spiega esattamente che cosa può stabilire ogni tipo di evidenza.
Rilascia senza rompere nulla
Il modo più sicuro per introdurre le policy di accesso per agenti è per fasi.
- Observe. Installa Proof of Actor in observation mode. Per i tuoi utenti non cambia nulla; i risultati vengono registrati.
- Understand. Rivedi quali attori usano quali route, il tasso di Unknown su ciascuna e i risultati che non coincidono con ciò che sai già.
- Preview. Esegui una policy in preview, registrando cosa avrebbe fatto senza applicarla.
- Enforce in modo mirato. Abilita la policy su una sola route in cui le evidenze la supportano chiaramente. Osserva i risultati.
- Expand. Estendi ad altre route man mano che aumenta la fiducia.
La guida su rilasciare in sicurezza policy consapevoli dell'attore accompagna ogni fase, e proteggere le azioni sensibili senza bloccare gli agenti copre le route ad alto rischio.
Cosa ottiene il tuo team
Con Proof of Actor, il tuo team ottiene una sola integrazione con tre capacità. Detect raccoglie i segnali dell'attore e separa le affermazioni verificate dalle inferenze. Understand mostra analytics sugli attori, trend e le evidenze dietro ogni risultato, mantenendo Unknown visibile. Route ti permette di scrivere le policy descritte in questa pagina e applicarle dove scegli tu. Durante la private beta, le policy di routing vengono progettate con ogni founding team ed eseguite nel codice della tua application, così mantieni il pieno controllo.
Errori comuni di policy da evitare
I team che progettano per la prima volta l'accesso per agenti tendono a ripetere alcuni errori. Evitarli fa risparmiare settimane di rework.
- Bloccare ogni agente per impostazione predefinita. Gli agenti legittimi allora aggirano il tuo sistema, spesso raschiando l'interfaccia che hai costruito per le persone, che è più difficile da proteggere di un percorso strutturato.
- Fidarsi di un nome dichiarato. Un client che si limita a nominarsi ha fatto un'affermazione, non ha fornito una prova. Trattalo come tratteresti un chiamante non verificato.
- Usare un solo fallback ovunque. Unknown su una pagina pubblica di pricing e Unknown su un cambio password sono situazioni diverse. Ogni route ha bisogno della sua risposta.
- Decidere sulle persone a partire da un'inferenza. I risultati dell'attore sono contesto per il routing, non un verdetto su una persona. Mantieni le decisioni con conseguenze rilevanti nei tuoi controlli e nella tua review.
- Saltare l'osservazione. Applicare l'enforcement dal primo giorno significa scoprire i falsi positivi tramite i reclami dei clienti. Prima osserva, poi applica l'enforcement dove le evidenze sono chiare.
Una breve review della policy con i responsabili security, product e support prima di ogni passo di enforcement intercetta in anticipo la maggior parte di questi problemi.
Inizia con il founding developer program
Proof of Actor è in private beta. I team di founding development selezionati possono ricevere fino a 12 mesi di accesso gratuito, entro limiti di utilizzo concordati, con supporto diretto dai nostri engineer mentre progettate le vostre prime policy.
Se stai decidendo come la tua application dovrebbe trattare gli agenti AI, richiedi l'accesso anticipato. Dicci quali route contano di più e quali decisioni vuoi prendere, e ti aiuteremo a costruire policy adatte. Puoi anche vedere come questo si applica a APIs e MCP server.
Fonti
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Overview of OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- MCP authorization, modelcontextprotocol.io.