Zum Hauptinhalt springen
MCP AUFRUFERIDENTIFIKATION

Erfahren Sie, wer Ihren MCP server aufruft

Ihr MCP server stellt AI-Clients, die Sie nicht kontrollieren, Tools zur Verfügung. Proof of Actor zeigt, was hinter jedem Aufruf steht, welche Evidenz dies stützt, und lässt Sie Policies pro Tool festlegen.

Frühen Zugang erhaltenFunktionsweise erkunden
Toshendra Sharma

Von Toshendra SharmaGründer & CEO, AgentCredia · Updated November 13, 2026

Ihre Tools sind für Aufrufer offen, die Sie nicht sehen können

Ein MCP server macht Ihr Produkt für AI-Clients nutzbar. Er stellt Tools, Ressourcen und Prompts bereit, die Assistenten und Agenten entdecken und aufrufen können, indem sie JSON-RPC 2.0 Nachrichten zwischen Hosts, Clients und Servern verwenden, wie in der Model Context Protocol specification beschrieben. Genau deshalb bauen Teams sie: Sie bringen Ihr Produkt in die Workflows, in denen AI agents bereits arbeiten.

Das bedeutet auch, dass Ihr server Aufrufe von Clients erhält, die Sie nicht gebaut haben und nicht direkt beobachten können. Ein einzelnes Tool kann von einem lokal testenden Entwickler aufgerufen werden, von einem Desktop-Assistenten, der für eine angemeldete Person handelt, von einem autonomen Agenten, der nachts eine lange Aufgabe ausführt, oder von etwas, das Ihren server auf Schwachstellen prüft. Das Protokoll sagt Ihnen, welches Tool aufgerufen wurde und mit welchen Argumenten. Es sagt Ihnen allein nicht, welche Art von Actor hinter dem Aufruf steht oder wie stark Sie ihm vertrauen sollten.

MCP server-Aufruferidentifikation schließt diese Lücke. Proof of Actor ergänzt jeden Tool-Aufruf um ein evidenzbasiertes Actor-Ergebnis, sodass Ihr server fundierte Entscheidungen darüber treffen kann, wer was bekommt. Einen tieferen Einblick in das Problem erhalten Sie unter wer Ihren MCP server aufruft, und im MCP servers use case sehen Sie, wie Teams dies anwenden.

Hinweis zu Begriffen. "Caller identity" hat auch in der Cloud-Infrastruktur eine etablierte Bedeutung. AWS STS GetCallerIdentity gibt beispielsweise Details über den IAM user oder role zurück, dessen credentials verwendet werden, um den Vorgang aufzurufen. Das beantwortet, welches Cloud-Credential einen Aufruf gemacht hat. Die Aufruferidentifikation für MCP server auf dieser Seite beantwortet eine andere Frage: Welche Art von Actor, Human, Human + AI, Agent oder Unknown, steht hinter einem Tool-Aufruf an Ihren MCP server, und welche Evidenz stützt diese Antwort?

Was MCP-Aufrufer unterscheidet

MCP-Aufrufer unterscheiden sich in wichtigen Punkten von Browser-Besuchern und von traditionellen API-Clients, die für Policies relevant sind.

  • Sie sind fast immer automatisiert. Die Frage lautet weniger "Mensch oder Bot?" als "welcher Agent, auf welche Weise handelnd, mit welcher Evidenz?"
  • Sie handeln oft für eine Person. Ein Assistent ruft Ihr Tool möglicherweise auf, weil ein Nutzer ihn dazu aufgefordert hat, oder er handelt autonom. Diese Fälle verdienen unterschiedliche Behandlung.
  • Sie beschreiben sich selbst. Die MCP lifecycle specification lässt den Client in seiner initialize request ein clientInfo-Objekt mit Name und Version senden. Diese Erklärung ist nützlicher Kontext, aber sie ist eine Erklärung, kein Beweis.
  • Tools unterscheiden sich stark in ihrer Auswirkung. Ein Such-Tool und ein Tool, das Datensätze löscht, sollten nicht dieselbe Policy haben.

Gute MCP-Aufruferidentifikation muss all das berücksichtigen.

Wie Proof of Actor MCP-Aufrufer identifiziert

Signale von Ihrem server

Ihre MCP-Integration übergibt Proof of Actor den für jeden Aufruf verfügbaren Kontext: die vom Client erklärten Details, Transport- und Request-Kontext, alle kryptografischen Request-Signaturen, die der Client bereitstellt, etwa HTTP Message Signatures, definiert in RFC 9421, und das aufgerufene Tool. Jedes Signal wird mit seiner Herkunft gekennzeichnet.

Klassifizierung mit Grundlage

Proof of Actor liefert eine von vier Klassen: Human, Human + AI, Agent oder Unknown, zusammen mit der Grundlage für das Ergebnis:

  • verified, wenn eine kryptografische Prüfung, etwa eine Request-Signatur gegen einen veröffentlichten Schlüssel, bestanden hat;
  • declared, wenn der Client oder Ihre Anwendung dies angegeben hat, etwa den Client-Namen in der Sitzung;
  • inferred, wenn das Ergebnis auf Mustern in den Aufrufen beruht;
  • unknown, wenn die Evidenz keine eindeutige Bestimmung trägt.

Ein deklarierter Client-Name wird niemals als Verifikation dargestellt. Wenn die Evidenz dünn ist, lautet das Ergebnis Unknown statt einer zuversichtlichen Vermutung, und Ihr server weiß genau, womit er arbeitet.

Ein Ergebnis, das Ihre Tools nutzen können

Das Actor-Ergebnis wird zusammen mit dem Tool-Aufruf geliefert, bereit für die Logik Ihres server. Im Beobachtungsmodus erfassen Sie es. Wenn Sie bereit sind, greifen Ihre Tool-Policies darauf zu.

Was Ihr Team erhält: Detect, Understand, Route

Detect

Erfassen Sie die bei jedem Tool-Aufruf verfügbaren Aufrufer-Evidenzen und halten Sie verified, declared und inferred Evidenz getrennt.

Understand

Sehen Sie, welche Clients welche Tools wie oft aufrufen, mit welcher Evidenz und wie sich das im Laufe der Zeit verändert. Erkennen Sie Tools, die überwiegend Unknown-Aufrufer anziehen, Clients, die ihr Verhalten ändern, und den Anteil der Aufrufe mit verifizierbarer Identität.

Route

Schreiben Sie Policies pro Tool und pro Risikostufe. Typische Muster:

  • Tools mit geringer Auswirkung wie Suche oder nur lesende Abfragen: breit zulassen, mit einem Standard-Rate-Limit.
  • Tools mit mittlerer Auswirkung wie das Erstellen von Entwürfen: verifizierte und deklarierte Aufrufer zulassen, Unknown rate-limitieren.
  • Tools mit hoher Auswirkung wie das Löschen von Daten, das Ändern von Einstellungen oder das Senden von Nachrichten im Namen eines Nutzers: Ihre stärkste Autorisierung verlangen und bei Unknown oder autonom handelndem Aufrufer eine Bestätigung oder Prüfung hinzufügen.

Der Leitfaden zu sensitive actions without blocking agents zeigt, wie Sie diese Stufen entwerfen.

Identitätsevidenz, Credentials und Autorisierung sind getrennt

MCP security funktioniert am besten, wenn drei Fragen getrennt bleiben:

  1. Identitätsevidenz: Welche Art von Client ruft an, und was belegt das? Proof of Actor stellt dies bereit.
  2. Credentials: Mit welchem Account oder Token wird dieser Aufruf gemacht? Die Authentifizierung Ihres MCP server stellt dies bereit. Die MCP authorization specification macht Autorisierung optional und stützt sie bei HTTP-basierten Transporten auf OAuth 2.1, wobei der MCP server als resource server fungiert, der access tokens validiert.
  3. Autorisierung: Darf dieser Aufrufer dieses Tool mit diesen Argumenten für diesen Account verwenden? Ihr Berechtigungsmodell stellt dies bereit.

Ein anerkannter Client ist nicht automatisch ein autorisierter. Eine gültige Signatur zeigt nicht, dass die Person hinter der Sitzung die Befugnis für diese konkrete Aktion delegiert hat. Lesen Sie mehr über delegated authority und agent authorization. Proof of Actor gibt Ihrem server besseren Kontext für die erste Frage, damit Ihre Antworten auf die zweite und dritte besser informiert sind.

Warum nicht einfach dem Client-Namen vertrauen?

Weil jeder Client jeden Namen senden kann. Einen deklarierten Namen als Beweis zu behandeln, lädt zur Imitation ein: Ein feindlicher Client muss nur den Namen eines beliebten Assistenten kopieren. Proof of Actor erfasst den Namen als deklarierte Evidenz, kombiniert ihn mit jeder stärkeren vorhandenen Evidenz und nennt Ihnen die Grundlage. Ihre Policy kann dann verifizierten Aufrufern mehr Spielraum geben als Aufrufern, die sich nur selbst erklärt haben, und Ihren Unknown-Fallback anwenden, wenn keines von beidem zutrifft.

Starten Sie im Beobachtungsmodus

Die Installation von Proof of Actor in Ihrem MCP server ändert nicht, wie ein Tool reagiert. Ergebnisse werden aufgezeichnet, damit Sie sehen können, wer Ihre Tools aufruft, wie stark die Evidenz ist und wo Policies hilfreich wären. Wenn Sie sich sicher fühlen, aktivieren Sie eine Policy für ein einzelnes Tool mit hoher Auswirkung, beobachten Sie die Ergebnisse und erweitern Sie dann schrittweise. How It Works beschreibt den gesamten Ablauf, und Detection & Limitations erklärt, was jede Art von Evidenz belegen kann und was nicht.

Entwickelt für Teams, die MCP servers und APIs betreiben

Proof of Actor sitzt in Ihrem server neben Ihrer bestehenden Authentifizierung, Ratenbegrenzung und Protokollierung. Integrationen werden gemeinsam mit jedem Founding-Team praxisnah umgesetzt, damit das Setup zu Ihrem Transport, Hosting und Tool-Design passt. Die MCP Servers- und APIs-Use Cases zeigen, wie derselbe Ansatz auf Ihre Tools und Ihre API angewendet wird.

Fragen, die Sie zu jedem freigegebenen Tool stellen sollten

Bevor Sie Tool-Policies schreiben, lohnt es sich, jedes Tool, das Ihr MCP server bereitstellt, mit einer kurzen Checkliste zu prüfen:

  • Was kann dieses Tool ändern? Nur lesende Tools und Tools, die Daten ändern, Nachrichten senden oder die Abrechnung beeinflussen, verdienen unterschiedliche Behandlung.
  • Für wen ist es gedacht? Manche Tools existieren für Assistenten, die im Auftrag einer angemeldeten Person handeln; andere für autonome Workflows. Der erwartete Aufrufer prägt die passende Policy.
  • Was würde ein Fehler kosten? Ein falsches Suchergebnis ist günstig. Eine falsche Löschung nicht. Ordnen Sie jedes Tool einer Risikostufe zu.
  • Welche Evidenz sollte erforderlich sein? Entscheiden Sie, ob ein deklarierter Client genügt oder ob das Tool verifizierte Identität plus Ihre stärkste Autorisierung benötigt.
  • Was geschieht bei Unknown? Wählen Sie einen expliziten Fallback für jedes Tool: zulassen, rate-limitieren, den Nutzer um Bestätigung bitten oder zur Prüfung weiterleiten.
  • Woran erkennen Sie, dass es funktioniert? Legen Sie fest, welche Ergebnisse Sie im Beobachtungsmodus überwachen, bevor Sie etwas durchsetzen.

Diese Fragen einmal pro Tool zu beantworten, verwandelt Aufruferidentifikation in klare, testbare Regeln und macht es einfach, das Verhalten Ihres server den integrierenden Clients zu erklären.

Treten Sie dem Founding Developer Program bei

Proof of Actor befindet sich in der privaten Beta. Ausgewählte Founding-Entwicklungsteams können innerhalb der vereinbarten Nutzungsgrenzen bis zu 12 Monate kostenlosen Zugriff erhalten, mit direkter Unterstützung durch unsere Ingenieure, während Sie Tool-Policies entwerfen.

Wenn Sie einen MCP server betreiben und wissen möchten, wer ihn aufruft, bewerben Sie sich für Early Access. Erzählen Sie uns von Ihrem server, den Tools, die Sie bereitstellen, und den Aufrufen, die Ihnen am wichtigsten sind.

Quellen

FÜR ENTWICKLER

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 oder Unknown.
basis
Wie stark die Evidenz ist: verified, declared, inferred oder unknown.
evidence
Die Signale hinter dem Ergebnis, damit Ihr Team den Grund sehen kann.

Starten Sie im Beobachtungsmodus: Erfassen Sie Ergebnisse neben Ihren Logs und ändern Sie nichts, bis Sie eine Richtlinie wählen. Lesen Sie die Node.js-Integrationsanleitung

Häufig gestellte Fragen

Warum braucht ein MCP server Aufruferidentifikation?

MCP servers stellen Tools AI-Clients bereit, die im Auftrag von Personen handeln oder autonom laufen. Zu wissen, welche Art von Aufrufer hinter einem Tool-Aufruf steht, ermöglicht es Ihnen, Tools mit geringer Auswirkung frei zuzulassen und bei Tools mit hoher Auswirkung strengere Anforderungen zu stellen.

Ist der Client-Name in einer MCP-Sitzung eine Verifikation?

Nein. Ein Client-Name ist eine vom Client abgegebene Erklärung. Proof of Actor erfasst ihn als deklarierte Evidenz und hält ihn klar getrennt von kryptografisch verifizierter Identität.

Ersetzt die Aufruferidentifikation die MCP-Autorisierung?

Nein. Identitätsevidenz des Aufrufers, das verwendete Credential und das, was der Aufrufer tun darf, sind getrennte Fragen. Proof of Actor ergänzt die erste um Kontext und überlässt die Autorisierung Ihrem server.

Wird Proof of Actor Tool-Aufrufe blockieren?

Nur wenn Ihre Policies dies vorsehen. Jede Integration startet im Beobachtungsmodus, und Sie aktivieren Tool-Policies erst, wenn Sie bereit sind.

Wie kann ich es ausprobieren?

Beantragen Sie frühen Zugang. Ausgewählte Founding-Developer-Teams können innerhalb der vereinbarten Nutzungsgrenzen bis zu 12 Monate kostenlos erhalten, inklusive praktischer Integrationsunterstützung.

Wissen, wer Ihre App verwendet.

Private Beta für eine kleine Gruppe von Founding-Developern.

Frühen Zugang erhaltenPreise anzeigen

Möchten Sie zuerst sprechen? Mit den Gründern sprechen