Ga naar hoofdinhoud
MCP-AANROEPERIDENTIFICATIE

Weet wie je MCP-server aanroept

Je MCP-server stelt tools beschikbaar aan AI-clients die je niet beheert. Proof of Actor laat zien wat er achter elke aanroep zit, welk bewijs dat ondersteunt en laat je beleid per tool instellen.

Krijg vroege toegangOntdek hoe het werkt
Toshendra Sharma

Door Toshendra SharmaOprichter & CEO, AgentCredia · Updated November 13, 2026

Je tools staan open voor aanroepers die je niet kunt zien

Een MCP server maakt je product bruikbaar voor AI-clients. Het stelt tools, resources en prompts beschikbaar die assistants en agents kunnen ontdekken en aanroepen, met JSON-RPC 2.0-berichten tussen hosts, clients en servers zoals beschreven in de Model Context Protocol specification. Dat is precies waarom teams ze bouwen: ze plaatsen je product in de workflows waar AI-agents al werken.

Dat betekent ook dat je server aanroepen ontvangt van clients die je niet hebt gebouwd en niet direct kunt waarnemen. Een enkele tool kan worden aangeroepen door een developer die lokaal test, door een desktopassistant die optreedt voor een aangemelde persoon, door een autonome agent die ’s nachts een lange taak uitvoert, of door iets dat je server op zwakke plekken onderzoekt. Het protocol vertelt je welke tool is aangeroepen en met welke arguments. Het vertelt je op zichzelf niet welk type actor achter de aanroep zit of hoeveel vertrouwen je daarin moet hebben.

MCP-server aanroeperidentificatie vult dat gat. Proof of Actor voegt een evidence-onderbouwd actorresultaat toe aan elke toolaanroep, zodat je server weloverwogen beslissingen kan nemen over wie wat krijgt. Voor een diepere kijk op het probleem, lees who is calling your MCP server, en bekijk de MCP servers use case voor hoe teams het toepassen.

Een opmerking over termen. "Caller identity" heeft ook een bekende betekenis in cloudinfrastructuur. AWS STS GetCallerIdentity geeft bijvoorbeeld details terug over de IAM user of role waarvan de credentials worden gebruikt om de operatie aan te roepen. Dat beantwoordt welke cloudcredential een aanroep deed. MCP-server aanroeperidentificatie op deze pagina beantwoordt een andere vraag: welk type actor, Human, Human + AI, Agent of Unknown, achter een toolaanroep naar je MCP-server zit, en welk bewijs dat antwoord ondersteunt.

Wat MCP-aanroepers anders maakt

MCP-aanroepers verschillen van browserbezoekers en van traditionele API-clients op manieren die belangrijk zijn voor beleid.

  • Ze zijn bijna altijd geautomatiseerd. De vraag is minder "mens of bot?" en meer "welke agent, handelend hoe, met welk bewijs?"
  • Ze handelen vaak namens een persoon. Een assistant kan je tool aanroepen omdat een user dat vroeg, of het kan autonoom handelen. Die gevallen verdienen een andere behandeling.
  • Ze beschrijven zichzelf. De MCP lifecycle specification laat de client een clientInfo-object met een naam en versie sturen in zijn initialize request. Die declaratie is nuttige context, maar het is een declaratie, geen bewijs.
  • Tools verschillen enorm in impact. Een zoektool en een tool die records verwijdert, zouden niet één beleid moeten delen.

Goede MCP-aanroeperidentificatie moet al deze vier respecteren.

Hoe Proof of Actor MCP-aanroepers identificeert

Signalen van je server

Je MCP-integratie geeft Proof of Actor de context die beschikbaar is voor elke aanroep: de gedeclareerde details van de client, transport- en requestcontext, eventuele cryptografische request signatures die de client levert, zoals HTTP Message Signatures gedefinieerd in RFC 9421, en de tool die wordt aangeroepen. Elk signaal krijgt een label dat aangeeft waar het vandaan komt.

Classificatie met een basis

Proof of Actor geeft een van vier klassen terug, Human, Human + AI, Agent of Unknown, samen met de basis voor het resultaat:

  • verified wanneer een cryptografische controle, zoals een request signature tegen een gepubliceerde key, is geslaagd;
  • declared wanneer de client of je applicatie het heeft verklaard, zoals de clientnaam in de sessie;
  • inferred wanneer het resultaat berust op patronen in de aanroepen;
  • unknown wanneer het bewijs een vaststelling niet ondersteunt.

Een gedeclareerde clientnaam wordt nooit als verificatie gepresenteerd. Wanneer het bewijs dun is, is het resultaat Unknown in plaats van een zelfverzekerde gok, en weet je server precies waarmee hij werkt.

Een resultaat dat je tools kunnen gebruiken

Het actorresultaat komt samen met de toolaanroep binnen, klaar voor de logica van je server. In observatiemodus leg je het vast. Wanneer je klaar bent, handelen je toolbeleid erop.

Wat je team krijgt: Detect, Understand, Route

Detect

Leg het aanroepersbewijs vast dat beschikbaar is bij elke toolaanroep en houd verified, declared en inferred bewijs gescheiden.

Understand

Zie welke clients welke tools aanroepen, hoe vaak, met welk bewijs en hoe dat in de loop van de tijd verandert. Spot tools die vooral Unknown-aanroepers aantrekken, clients die hun gedrag veranderen, en het aandeel aanroepen dat verifieerbare identiteit bevat.

Route

Schrijf beleid per tool en per risiconiveau. Typische patronen:

  • Low-impact tools zoals zoeken of read-only opvragingen: sta breed toe, met een standaard rate limit.
  • Moderate-impact tools zoals concepten maken: sta verified en declared aanroepers toe, rate-limit Unknown.
  • High-impact tools zoals data verwijderen, instellingen wijzigen of berichten verzenden namens een user: vereis je sterkste autorisatie en voeg bevestiging of review toe waar de aanroeper Unknown is of autonoom handelt.

De gids over protecting sensitive actions without blocking agents laat zien hoe je deze niveaus ontwerpt.

Identiteitsbewijs, credentials en autorisatie zijn gescheiden

MCP-beveiliging werkt het best wanneer drie vragen gescheiden blijven:

  1. Identiteitsbewijs: welk type client roept aan, en wat bewijst dat? Proof of Actor levert dit.
  2. Credentials: met welk account of token wordt deze aanroep gedaan? De authenticatie van je MCP-server levert dit. De MCP authorization specification maakt autorisatie optioneel en baseert die voor HTTP-based transports op OAuth 2.1, waarbij de MCP-server optreedt als een resource server die access tokens valideert.
  3. Autorisatie: mag deze aanroeper deze tool gebruiken, met deze arguments, voor dit account? Je permissiemodel levert dit.

Een erkende client is niet automatisch een geautoriseerde client. Een geldige signature laat niet zien dat de persoon achter de sessie bevoegdheid heeft gedelegeerd voor deze specifieke actie. Lees meer over delegated authority en agent authorization. Proof of Actor geeft je server betere context voor de eerste vraag, zodat je antwoorden op de tweede en derde beter onderbouwd zijn.

Waarom niet gewoon op de clientnaam vertrouwen?

Omdat elke client elke naam kan sturen. Een gedeclareerde naam als bewijs behandelen nodigt uit tot imitatie: een kwaadwillende client hoeft alleen de naam van een populaire assistant over te nemen. Proof of Actor registreert de naam als declared evidence, combineert die met welk sterker bewijs dan ook aanwezig is en vertelt je wat de basis is. Je beleid kan verified-aanroepers dan meer ruimte geven dan aanroepers die zichzelf alleen hebben gedeclareerd, en je Unknown-fallback toepassen wanneer geen van beide van toepassing is.

Begin in observatiemodus

Proof of Actor installeren in je MCP-server verandert niet hoe een tool reageert. Resultaten worden vastgelegd zodat je kunt zien wie je tools aanroept, hoe sterk het bewijs is en waar beleid zou helpen. Wanneer je zeker bent, schakel je een beleid in voor één hoog-impact tool, bekijk je de uitkomsten en breid je daarna uit. How It Works behandelt de volledige flow, en Detection & Limitations legt uit wat elk type bewijs wel en niet kan vaststellen.

Gebouwd voor teams die MCP-servers en APIs beheren

Proof of Actor zit in je server naast je bestaande authenticatie, rate limiting en logging. Integraties worden hands-on geleverd met elk founding team, zodat de setup past bij je transport, hosting en toolontwerp. De use cases MCP Servers en APIs laten zien hoe dezelfde aanpak over je tools en je API wordt toegepast.

Vragen om over elke tool die je beschikbaar stelt te stellen

Voordat je beleid op toolniveau schrijft, helpt het om elke tool die je MCP-server beschikbaar stelt te bekijken met een korte checklist:

  • Wat kan deze tool veranderen? Read-only tools en tools die data wijzigen, berichten verzenden of invloed hebben op billing verdienen een andere behandeling.
  • Voor wie is hij bedoeld? Sommige tools bestaan voor assistants die handelen namens een aangemelde persoon; andere voor autonome workflows. De verwachte aanroeper bepaalt het juiste beleid.
  • Wat kost een fout? Een verkeerd zoekresultaat is goedkoop. Een verkeerde verwijdering niet. Koppel elke tool aan een risiconiveau.
  • Welk bewijs moet vereist zijn? Bepaal of een gedeclareerde client genoeg is, of dat de tool verifieerbare identiteit plus je sterkste autorisatie nodig heeft.
  • Wat gebeurt er bij Unknown? Kies voor elke tool een expliciete fallback: toestaan, rate-limit, de user om bevestiging vragen of naar review routeren.
  • Hoe weet je dat het werkt? Bepaal welke uitkomsten je in observatiemodus volgt voordat je iets afdwingt.

Door dit eenmaal per tool te beantwoorden, maak je van aanroeperidentificatie duidelijke, testbare regels en wordt het eenvoudig om het gedrag van je server uit te leggen aan de clients die ermee integreren.

Sluit je aan bij het founding developer-programma

Proof of Actor zit in private beta. Geselecteerde founding development-teams kunnen tot 12 maanden gratis toegang krijgen, binnen overeengekomen gebruikslimieten, met directe ondersteuning van onze engineers terwijl je beleid op toolniveau ontwerpt.

Als je een MCP-server runt en wilt weten wie die aanroept, vraag vroege toegang aan. Vertel ons over je server, de tools die je beschikbaar stelt en de aanroepen die voor jou het belangrijkst zijn.

Bronnen

VOOR ONTWIKKELAARS

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 of Unknown.
basis
Hoe sterk het bewijs is: verified, declared, inferred of unknown.
evidence
De signalen achter het resultaat, zodat je team kan zien waarom.

Begin in observatiemodus: leg resultaten vast naast je logs en wijzig niets totdat je een beleid kiest. Lees de Node.js-integratiegids

Veelgestelde vragen

Waarom heeft een MCP-server aanroeperidentificatie nodig?

MCP-servers stellen tools bloot aan AI-clients die handelen namens mensen of autonoom draaien. Weten welk type aanroeper achter een toolaanroep zit, maakt het mogelijk om laag-impact tools vrij toe te staan en voor hoog-impact tools meer te vereisen.

Is de clientnaam in een MCP-sessie een verificatie?

Nee. Een clientnaam is een declaratie van de client. Proof of Actor registreert die als declared evidence en houdt die apart van cryptografisch geverifieerde identiteit.

Vervangt aanroeperidentificatie MCP-autorisatie?

Nee. Bewijs van de identiteit van de aanroeper, het gebruikte credential en wat de aanroeper mag doen zijn afzonderlijke vragen. Proof of Actor voegt context toe aan de eerste vraag en laat autorisatie over aan je server.

Blokkeert Proof of Actor toolaanroepen?

Alleen als je beleid dat zegt. Elke integratie begint in observatiemodus en je schakelt toolbeleid pas in wanneer je er klaar voor bent.

Hoe kan ik het proberen?

Vraag vroege toegang aan. Geselecteerde founding developer-teams kunnen tot 12 maanden gratis krijgen binnen overeengekomen gebruikslimieten, met praktische integratieondersteuning.

Weet wie uw app gebruikt.

Private beta voor een kleine groep founding developers.

Krijg vroege toegangBekijk prijzen

Eerst liever even praten? Spreek met de oprichters