Salta al contenuto principale
IDENTIFICAZIONE DEI CHIAMANTI MCP

Scopri chi sta chiamando il tuo MCP server

Il tuo MCP server espone tool a client AI che non controlli. Proof of Actor ti dice cosa c'è dietro ogni chiamata, quali evidenze la supportano e ti lascia impostare policy per singolo tool.

Richiedi accesso anticipatoEsplora come funziona
Toshendra Sharma

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

I tuoi tool sono aperti a chiamanti che non puoi vedere

Un MCP server rende il tuo prodotto utilizzabile dai client AI. Espone tool, risorse e prompt che assistenti e agent possono scoprire e chiamare, usando messaggi JSON-RPC 2.0 tra host, client e server come descritto nella specifica del Model Context Protocol. È esattamente per questo che i team li costruiscono: inseriscono il tuo prodotto nei workflow in cui gli agent AI stanno già lavorando.

Significa anche che il tuo server riceve chiamate da client che non hai costruito e che non puoi osservare direttamente. Un singolo tool potrebbe essere invocato da uno sviluppatore che testa in locale, da un assistente desktop che agisce per una persona connessa, da un agent autonomo che esegue un'attività lunga durante la notte, oppure da qualcosa che analizza il tuo server alla ricerca di punti deboli. Il protocollo ti dice quale tool è stato chiamato e con quali argomenti. Da solo, non ti dice quale tipo di attore c'è dietro la chiamata né quanto dovresti fidarti.

L'identificazione dei chiamanti di MCP server colma questa lacuna. Proof of Actor aggiunge a ogni chiamata di tool un risultato sull'attore supportato da evidenze, così il tuo server può prendere decisioni informate su chi ottiene cosa. Per un approfondimento sul problema, leggi chi sta chiamando il tuo MCP server e vedi il caso d'uso MCP servers per capire come i team lo applicano.

Nota sui termini. "Caller identity" ha anche un significato ben noto nell'infrastruttura cloud. AWS STS GetCallerIdentity, per esempio, restituisce i dettagli dell'utente IAM o del ruolo le cui credenziali sono usate per chiamare l'operazione. Questo risponde alla domanda su quale credenziale cloud abbia effettuato una chiamata. L'identificazione dei chiamanti di un MCP server in questa pagina risponde a una domanda diversa: quale tipo di attore, Human, Human + AI, Agent o Unknown, si trova dietro una chiamata di tool al tuo MCP server, e quali evidenze supportano quella risposta.

Cosa rende diversi i chiamanti MCP

I chiamanti MCP differiscono dai visitatori del browser e dai client API tradizionali in modi che contano per le policy.

  • Sono quasi sempre automatizzati. La domanda è meno "persona o bot?" e più "quale agent, in che modo, con quali evidenze?"
  • Spesso agiscono per conto di una persona. Un assistente può chiamare il tuo tool perché un utente glielo ha chiesto, oppure può agire in autonomia. Questi casi meritano trattamenti diversi.
  • Si descrivono da soli. La specifica del lifecycle di MCP prevede che il client invii un oggetto clientInfo con nome e versione nella sua richiesta initialize. Quella dichiarazione è un contesto utile, ma è una dichiarazione, non una prova.
  • I tool variano enormemente per impatto. Un tool di ricerca e un tool che elimina record non dovrebbero condividere la stessa policy.

Una buona identificazione dei chiamanti MCP deve rispettare tutti e quattro gli aspetti.

Come Proof of Actor identifica i chiamanti MCP

Segnali dal tuo server

La tua integrazione MCP passa a Proof of Actor il contesto disponibile per ogni chiamata: i dettagli dichiarati dal client, il contesto di trasporto e di richiesta, eventuali firme crittografiche della richiesta fornite dal client, come HTTP Message Signatures definite in RFC 9421, e il tool chiamato. Ogni segnale è etichettato con la sua origine.

Classificazione con una base

Proof of Actor restituisce una delle quattro classi, Human, Human + AI, Agent o Unknown, insieme alla base del risultato:

  • verified quando un controllo crittografico, come una firma della richiesta verificata rispetto a una chiave pubblicata, è riuscito;
  • declared quando il client o la tua applicazione lo ha dichiarato, come il nome del client nella sessione;
  • inferred quando il risultato si basa su pattern nelle chiamate;
  • unknown quando le evidenze non supportano una determinazione.

Il nome di un client dichiarato non viene mai presentato come verifica. Quando le evidenze sono deboli, il risultato è Unknown invece di un'ipotesi sicura, e il tuo server sa esattamente con cosa sta lavorando.

Un risultato che i tuoi tool possono usare

Il risultato sull'attore arriva insieme alla chiamata del tool, pronto per la logica del tuo server. In modalità di osservazione lo registri. Quando sei pronto, le tue policy a livello di tool agiscono su di esso.

Cosa ottiene il tuo team: Detect, Understand, Route

Detect

Acquisisci le evidenze sul chiamante disponibili a ogni chiamata di tool e mantieni distinte le evidenze verified, declared e inferred.

Understand

Vedi quali client chiamano quali tool, con quale frequenza, con quali evidenze e come questo cambia nel tempo. Individua i tool che attraggono soprattutto chiamanti Unknown, i client che cambiano comportamento e la quota di chiamate che porta un'identità verificabile.

Route

Scrivi policy per tool e per livello di rischio. Modelli tipici:

  • Tool a basso impatto come la ricerca o le consultazioni di sola lettura: consenti in modo ampio, con un rate limit standard.
  • Tool a impatto moderato come la creazione di bozze: consenti chiamanti verified e declared, limita il rate limit per Unknown.
  • Tool ad alto impatto come l'eliminazione di dati, la modifica delle impostazioni o l'invio di messaggi per conto di un utente: richiedi la tua autorizzazione più forte e aggiungi conferma o revisione quando il chiamante è Unknown o agisce in autonomia.

La guida su proteggere azioni sensibili senza bloccare gli agent mostra come progettare questi livelli.

Le evidenze di identità, le credenziali e l'autorizzazione sono separate

La sicurezza MCP funziona meglio quando tre domande restano distinte:

  1. Evidenze di identità: quale tipo di client sta chiamando e cosa lo dimostra? Proof of Actor fornisce questo.
  2. Credenziali: con quale account o token viene effettuata questa chiamata? L'autenticazione del tuo MCP server fornisce questo. La specifica di autorizzazione di MCP rende l'autorizzazione facoltativa e, per i trasporti basati su HTTP, la fonda su OAuth 2.1, con il MCP server che agisce come resource server e convalida gli access token.
  3. Autorizzazione: questo chiamante può usare questo tool, con questi argomenti, per questo account? Il tuo modello dei permessi fornisce questo.

Un client riconosciuto non è automaticamente autorizzato. Una firma valida non dimostra che la persona dietro la sessione abbia delegato l'autorità per questa specifica azione. Leggi di più su autorità delegata e autorizzazione degli agent. Proof of Actor fornisce al tuo server un contesto migliore per la prima domanda, così le risposte alla seconda e alla terza sono più informate.

Perché non fidarsi semplicemente del nome del client?

Perché qualunque client può inviare qualunque nome. Trattare un nome dichiarato come prova invita all'imitazione: un client ostile deve solo copiare il nome di un assistente popolare. Proof of Actor registra il nome come evidenza dichiarata, lo combina con qualunque evidenza più forte esista e ti indica la base. La tua policy può così dare più spazio ai chiamanti verified rispetto a quelli che si sono solo dichiarati, e applicare il tuo fallback Unknown quando nessuna delle due condizioni vale.

Inizia in modalità di osservazione

Installare Proof of Actor nel tuo MCP server non cambia il modo in cui risponde alcun tool. I risultati vengono registrati così puoi vedere chi chiama i tuoi tool, quanto è forte l'evidenza e dove le policy sarebbero utili. Quando ne sei certo, abilita una policy su un singolo tool ad alto impatto, osserva gli esiti, poi amplia. Come funziona copre il flusso completo e Detezione e limitazioni spiega cosa può e non può stabilire ciascun tipo di evidenza.

Progettato per team che operano MCP server e API

Proof of Actor si inserisce nel tuo server accanto all'autenticazione, al rate limiting e al logging esistenti. Le integrazioni vengono fornite in modo pratico con ogni team fondatore, così la configurazione si adatta al tuo trasporto, al tuo hosting e al design dei tool. I casi d'uso MCP Servers e APIs mostrano come lo stesso approccio si applichi a tutti i tuoi tool e alla tua API.

Domande da porre su ogni tool che esponi

Prima di scrivere policy a livello di tool, è utile esaminare ogni tool esposto dal tuo MCP server con una breve checklist:

  • Cosa può cambiare questo tool? I tool di sola lettura e quelli che modificano dati, inviano messaggi o influenzano la fatturazione meritano trattamenti diversi.
  • A chi è destinato? Alcuni tool esistono per assistenti che agiscono per conto di una persona connessa; altri per workflow autonomi. Il chiamante previsto determina la policy giusta.
  • Quanto costerebbe un errore? Un risultato di ricerca errato è poco costoso. Una cancellazione errata non lo è. Mappa ogni tool a un livello di rischio.
  • Quali evidenze dovrebbero essere richieste? Decidi se un client dichiarato è sufficiente, oppure se il tool debba richiedere identità verificata più la tua autorizzazione più forte.
  • Cosa succede su Unknown? Scegli un fallback esplicito per ogni tool: consentire, limitare il rate limit, chiedere conferma all'utente o indirizzare a revisione.
  • Come saprai che funziona? Decidi quali esiti osserverai in modalità di osservazione prima di far rispettare qualsiasi cosa.

Rispondere a queste domande una volta per tool trasforma l'identificazione del chiamante in regole chiare e verificabili, e rende facile spiegare il comportamento del tuo server ai client che vi si integrano.

Unisciti al programma fondatore per sviluppatori

Proof of Actor è in private beta. I team fondatori selezionati possono ricevere fino a 12 mesi di accesso gratuito, entro limiti di utilizzo concordati, con supporto diretto dai nostri ingegneri mentre progetti le policy a livello di tool.

Se gestisci un MCP server e vuoi sapere chi lo sta chiamando, richiedi l'accesso anticipato. Raccontaci del tuo server, dei tool che esponi e delle chiamate che ti interessano di più.

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

Perché un MCP server ha bisogno dell'identificazione del chiamante?

Gli MCP server espongono tool a client AI che agiscono per conto di persone o operano in autonomia. Sapere quale tipo di chiamante c'è dietro una chiamata di tool ti consente di consentire liberamente i tool a basso impatto e di richiedere di più per quelli ad alto impatto.

Il nome del client in una sessione MCP è una verifica?

No. Il nome di un client è una dichiarazione fatta dal client. Proof of Actor lo registra come evidenza dichiarata e lo mantiene distinto dall'identità verificata crittograficamente.

L'identificazione del chiamante sostituisce l'autorizzazione MCP?

No. Le evidenze sull'identità del chiamante, la credenziale usata e ciò che il chiamante è autorizzato a fare sono domande separate. Proof of Actor aggiunge contesto alla prima e lascia l'autorizzazione al tuo server.

Proof of Actor bloccherà le chiamate ai tool?

Solo se le tue policy lo stabiliscono. Ogni integrazione inizia in modalità di osservazione e attivi le policy a livello di tool quando sei pronto.

Come posso provarlo?

Richiedi l'accesso anticipato. I team fondatori selezionati possono ricevere fino a 12 mesi gratuiti entro i limiti di utilizzo concordati, con supporto pratico all'integrazione.

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