Pagamenti agentici sotto policy umana

I pagamenti agentici sono pagamenti avviati da un software e non da una persona alla cassa. Un agente AI detiene le credenziali, decide che un acquisto deve avvenire e muove il denaro da sé: paga una fattura, rinnova un abbonamento, prenota un charter, senza che un umano tocchi il pulsante finale. Ciò che li distingue è chi li avvia. Una persona che clicca su acquista fa un normale pagamento con carta con un chatbot davanti; un pagamento agentico è un software che decide, autorizza e regola nel momento in cui il denaro si muove davvero. Tutto ciò che è difficile in questa categoria discende da questa proprietà: chi spende non è una persona e non si stanca, non diffida, non si innervosisce come farebbe una persona prima di fare un bonifico a uno sconosciuto.

Per questo la domanda interessante non è mai stata se gli agenti spenderanno denaro (già possono farlo). La domanda è chi stabilisce le regole con cui spendono e se queste regole siano imposte dalla piattaforma o solo promesse dall'agente.

Il rischio è ovvio, ed è proprio questo il punto

Date a un agente una credenziale di pagamento attiva e nessun tetto, e avrete costruito un incidente di frode che non è ancora avvenuto. Il modo in cui va storto non ha nulla di esotico. Una prompt injection nascosta in una pagina web dice all'agente di pagare un malintenzionato. La descrizione malformata di uno strumento indirizza un acquisto legittimo al destinatario sbagliato. Un ciclo di retry tenta lo stesso addebito mille volte perché il segnale di successo non è mai tornato. Nessuno di questi casi richiede un avversario geniale: sono i normali bug del software autonomo, con la differenza che l'output è denaro che esce dal vostro conto.

La soluzione che tenta è rendere l'agente più prudente: un system prompt migliore, un'istruzione più severa, un modello che ragiona di più sulla spesa. Ma così il controllo finisce nel punto meno affidabile del sistema: il ragionamento dell'agente stesso, proprio ciò che si può convincere a cedere. Un budget che un agente può aggirare con le parole non è un budget. Il controllo deve stare dove l'agente non può arrivare, cioè fuori dall'agente.

La policy è il prodotto, non il prompt

Il modello di contenimento è una policy che la piattaforma applica prima che il denaro si muova, non dopo che l'agente ha deciso. Ogni agente ha un limite per transazione e un limite giornaliero (€150.00 a pagamento, €500.00 al giorno nella nostra policy demo), con un tetto mensile di €6,000.00 sopra di essi. Sono muri rigidi verificati dalla piattaforma, non promesse mantenute dall'agente. Quando il travel bot della demo ha provato a noleggiare un charter da €640.00, il pagamento è stato negato sul momento: oltre il limite, prima che si muovesse un centesimo. Un agente che si comporta alla perfezione ogni giorno non può comunque sforare ciò che il mese consente.

Un budget dice quanto; una allowlist dice dove. Gli agenti pagano solo i merchant che avete indicato in anticipo. L'Ops Agent della demo ne conosce esattamente quattro, e un tentativo da €180.00 verso un fornitore non in elenco è stato rifiutato come not-listed. Insieme, i due vincoli tracciano un perimetro: questa somma di denaro, solo verso questi destinatari. Dentro il perimetro l'agente corre a piena velocità e non deve mai chiedere; il perimetro è ciò che appartiene a un umano.

La domanda non è mai se un agente AI spenderà denaro. È chi ha scritto le regole con cui spende, e la risposta dovrebbe essere sempre un umano, in anticipo, per iscritto.

Un umano sopra la soglia

Alcune decisioni sono troppo grandi per essere lasciate a un perimetro. Per questo la policy prevede una soglia: un importo oltre il quale un umano deve approvare prima che il pagamento vada a buon fine. Nella demo la soglia è a €100.00. Quando l'Ops Agent ha segnalato la fattura #088 di Nord Logistics (€120.00, ampiamente dentro il budget giornaliero di €500.00 ma sopra la soglia di approvazione) non ha pagato. Si è fermato, ha messo la proposta davanti a una persona e ha aspettato. Una risposta di una riga l'ha sbloccata; il pagamento è stato regolato con riferimento 9F21-0716 ed è finito nell'audit log alle 09:41. Sotto la soglia l'agente si muove da solo; sopra, risponde prima una persona.

L'approvazione non è una casella da spuntare che svanisce. Registra chi ha approvato, da quale dispositivo, a che ora, con una firma allegata: approved in app, phone key, 09:41:12. Quando qualcuno chiede poi perché un pagamento è avvenuto, la risposta è una persona con nome e cognome e un timestamp, non un'alzata di spalle.

Un kill-switch e un log che non si modifica di nascosto

Anche dentro buoni muri, gli agenti si comportano male e le policy si rivelano sbagliate. Due controlli gestiscono questo caso. Il primo è un kill-switch: un tocco mette in pausa un agente e blocca all'istante ogni pagamento che potrebbe avviare. Le chiavi restano valide così nient'altro si rompe: l'agente semplicemente non può spendere finché un umano non lo riattiva, e le sue proposte in sospeso restano congelate invece di sparire. Nella flotta demo il travel bot è in pausa con €0.00 spesi e la sua coda intatta.

Il secondo è un audit log append-only. Ogni decisione è a verbale: cosa ha tentato l'agente, quale controllo di policy è stato superato o meno, chi ha approvato cosa, fino alle rotazioni delle chiavi. Un solo record ricostruisce un intero pagamento: la decisione DEC-4471 mostra la richiesta, ogni controllo di policy con il suo esito (allowlist superata, limite superato, soglia: escalation), la firma umana e l'importo regolato con il suo rail e il suo riferimento. Ogni voce contiene il proprio hash, l'hash della voce precedente e la propria posizione nella catena (#4,471 nella demo), quindi modificare un qualsiasi campo invalida tutti i record successivi. Il log si esporta in JSON, hash incluso: è vostro da consegnare a un revisore, non nostro da tenere.

Regolamento noioso, novità nell'autorizzazione

C'è la tentazione di rendere nuovi i pagamenti agentici fino in fondo: un nuovo rail, un nuovo strumento, un nuovo modo di far viaggiare il denaro. Resistete. La parte davvero nuova è l'autorizzazione: come un agente dimostra di poter pagare, sotto quale policy, con quale approvazione. Superato quel varco, il pagamento dovrebbe regolarsi su rail che sono noiosi da anni. Nella demo, una proposta approvata da €120.00 diventa un normale bonifico SEPA, regolato via SEPA Instant pochi minuti dopo l'approvazione, indistinguibile a valle da un pagamento fatto da una persona. La banca non sa né si cura del fatto che a iniziarlo sia stato un agente.

Questa separazione è voluta. I rail noiosi sono prevedibili, reversibili dove lo schema lo consente e ben compresi da ogni tesoreria e da ogni revisore con cui avrete a che fare. Mettere la novità nella policy e il pagamento su un rail consolidato significa che la parte rischiosa e in rapida evoluzione è quella che controllate per intero, mentre la parte che tocca le banche altrui è quella che nessuno deve reimparare. Gli agenti spendono dallo stesso core su cui gira il resto della famiglia di pagamenti, descritto in /products/pay, non da un universo parallelo costruito per i robot.

Il panorama dei protocolli non è ancora assestato: costruite di conseguenza

Come un agente debba presentare la propria identità e il proprio mandato a un esercente è una questione aperta. Diverse proposte si contendono il modo in cui un agente dimostra chi è, che cosa è autorizzato ad acquistare e come l'esercente lo verifica prima di accettare il denaro. Nessuna si è imposta, e scommettere tutto su una sola oggi sarebbe prematuro. L'approccio prudente è trattare il protocollo di autorizzazione come sostituibile e mantenere stabile tutto ciò che sta dietro: il motore di policy, il modello di audit e il rail di regolamento non cambiano quando cambia il formato sul fronte.

In pratica significa una superficie di integrazione piccola e noiosa. Gli agenti si collegano via MCP a mcp.protocore.io/agents; qualsiasi framework che parli il protocollo può gestire un wallet. L'interfaccia è volutamente stretta (proporre un pagamento, ricevere una decisione) perché la logica interessante vive sulla piattaforma, non nel prompt. Quando il settore si accorderà su come gli agenti si dimostrano ai commercianti, cambierà il fronte e le mura dietro resteranno esattamente dove sono.

Dove si colloca

I pagamenti agentici non sono una scommessa sul fatto che il software autonomo debba spendere senza limiti. Sono l'opposto: una scommessa sul fatto che il software spenderà, quindi è meglio che i limiti siano reali, esterni e leggibili. Budget e allowlist tracciano il perimetro, una soglia porta le decisioni importanti a una persona, un kill-switch ferma tutto, e un log append-only permette di ricostruire ogni pagamento a posteriori. La pagina prodotto /products/agents percorre l'intero ciclo sui dati demo usati qui (creare un agente, impostarne la policy, vedere un pagamento andare in escalation e regolarsi) e /products/pay è il core su cui questi pagamenti girano. L'autonomia è reale; lo è anche il guinzaglio, e a tenerlo è una persona.