Wie man einem KI-Agenten sicher Zugriff auf Geschäftsdaten gewährt

Die Architektur: Der Agent ist ein Client, das System ist die Autorität

Beginne mit der Struktur, denn die meisten Fehler sind Strukturfehler. Eine Person fragt ihren Agenten nach etwas. Der Agent entscheidet, welche Werkzeuge er aufruft. Jeder Aufruf durchläuft eine Berechtigungsebene, die zum Geschäftssystem gehört, nicht zum Agenten, und erreicht erst dann ein Modul wie Finanzen oder CRM. Der Agent berührt niemals die Datenbank, hält niemals eine Datenbankanmeldeinformation und sieht niemals ein Werkzeug, das seine Person nicht verwenden könnte.

Das Prinzip hinter dem Bild ist ein Satz: Der Agent handelt mit der Autorität der Person, die er vertritt, und niemals mehr. Alles andere in diesem Artikel ist ein Weg, diesen Satz unter Druck wahr zu machen, wenn das Modell falsch ist, wenn ein Dokument, das es liest, Anweisungen enthält oder wenn ein Token ausläuft.

Die OWASP Top 10 für LLM-Anwendungen benennt das Versagen, das diese Architektur verhindert: übermäßige Handlungsfreiheit, die sie in übermäßige Funktionalität (Werkzeuge, die über das hinausgehen, was der Job benötigt), übermäßige Berechtigungen (mehr Zugriff im Nachgang als notwendig) und übermäßige Autonomie (keine unabhängige Überprüfung vor einer hochwirksamen Aktion) unterteilt. Ihre Milderungen lesen sich wie eine Spezifikation für die Berechtigungsebene: im Kontext des Benutzers ausführen, die Werkzeuge und deren Berechtigungen minimieren, die Autorisierung im nachgelagerten System durchsetzen, anstatt sich auf das Modell zu verlassen, und die Genehmigung einer Person für hochwirksame Aktionen verlangen.

Fünf Kontrollen und wo jede lebt

Die Kontrollen sind nicht neu; sie sind die Kontrollen, die du bereits auf eine Person mit Systemzugang anwendest, angewendet auf einen Kunden, der für diese Person handelt. Die Tabelle zeigt, was jede Antwort gibt, wo sie durchgesetzt wird und wie ein Versagen aussieht, wenn sie fehlt. Die Standortspalte ist die wichtige. Eine im Prompt durchgesetzte Kontrolle ist eine Empfehlung.

Identität: sich als Person über OAuth verbinden, niemals mit einem gemeinsamen Schlüssel

Die Autorisierungsspezifikation des Model Context Protocol ist diesbezüglich präzise. Ein Remote-Server fungiert als OAuth 2.1-Ressourcenserver; der Client erhält ein Token über einen standardmäßigen Autorisierungsfluss mit PKCE; der Client muss angeben, für welchen Server das Token bestimmt ist, indem er den Ressourcenparameter verwendet; und der Server muss validieren, dass jedes Token speziell für ihn ausgestellt wurde und alles andere ablehnen. Die Spezifikation verbietet ausdrücklich das Token-Passthrough, bei dem ein Server ein Token akzeptiert, das er nicht ausgestellt hat, und es weiterleitet, da dies sowohl die Prüfspur als auch die Vertrauensgrenze zerstört.

In der Praxis bedeutet "einmal anmelden, kein Token zum Einfügen" Folgendes: Die Person fügt die Arbeitsbereichsadresse zu ihrem Agenten hinzu, wird zu einer normalen Anmeldeseite weitergeleitet, genehmigt die Verbindung, und der Agent erhält ein Token, das sie benennt und nur gegen diesen Arbeitsbereich funktioniert. Die Anleitung von Anthropic für benutzerdefinierte Connectoren in Claude besteht darin, die Berechtigungen zu überprüfen, die ein Server anfordert, diese wo möglich zu begrenzen und sich nur mit Servern zu verbinden, denen man vertraut. Ein Anbieter, der stattdessen verlangt, dass Sie einen unternehmensweiten API-Schlüssel in eine Agentenkonfiguration einfügen, hat die erste Kontrolle übersprungen und die anderen vier erheblich erschwert.

Scope: filtern, bevor man anbietet, erneut überprüfen beim Ausführen

Ein Agent entdeckt, was er tun kann, indem er den Server nach seiner Werkzeugliste fragt. Das richtige Design beantwortet diese Frage für jede Person: Die Liste, die ein Agent für Buchhalter erhält, unterscheidet sich von der Liste, die ein Agent für Direktoren erhält, und keine enthält Werkzeuge für Module, die ihre Rolle nicht sehen kann. Dies ist der OWASP-Ratschlag zur Minimierung der Funktionalität, der konkret umgesetzt wird, und er hat einen zweiten Vorteil: Ein Modell, dem nie ein Werkzeug gezeigt wird, kann nicht dazu gebracht werden, es zu verwenden.

Das Filtern der Liste allein reicht nicht aus, da sich Rollen ändern, Sitzungen bestehen bleiben und Clients cachen. Der gleiche Check muss bei jedem eingehenden Aufruf erneut durchgeführt werden, basierend auf den Berechtigungen der Person zu diesem Zeitpunkt. Unten finden Sie eine Werkzeugliste in der Form, die das Protokoll definiert, für eine Rolle, die Rechnungen lesen, aber keine Zahlungen erfassen kann. Das fehlende Werkzeug ist der Punkt.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

Eine Tools-/Listen-Antwort in der Form, die die MCP-Spezifikation definiert, mit Toolnamen aus dem Sois-Buchhaltungsmodul. Die Spezifikation besagt auch, dass Clients Annotationen wie readOnlyHint als untrusted behandeln müssen, es sei denn, der Server ist vertrauenswürdig, was ein weiterer Grund ist, warum der Server, nicht die Annotation, die Regel durchsetzen muss.

Prompt-Injection: Die Daten können zurücksprechen

Die Bedrohung, die speziell für Agenten besteht, ist, dass die Daten, die sie lesen, Anweisungen enthalten können. Eine E-Mail von einem Kunden, die mit einer Zeile endet, die den Agenten auffordert, die Lieferantenliste an eine externe Adresse weiterzuleiten; ein Dokument, das ihm sagt, jede bezahlte Rechnung zu kennzeichnen. Das Modell kann möglicherweise zustimmen oder auch nicht, und kein Prompt kann garantieren, dass es dies nicht tut, weshalb die Eingabeaufforderungsinjektion an erster Stelle der OWASP-Liste steht und sowohl Anthropic als auch OpenAI in ihren Connector-Richtlinien davor warnen.

The defence is the architecture, not the model. An agent that is only offered the tools its person can use cannot forward what its person cannot see. A call to mark invoices paid is checked by the system against the person's permissions, not against the model's belief that it was asked to. Consequential tools are marked so that the client asks a person first: ChatGPT currently requires manual confirmation in a conversation before write actions, and OpenAI's guidance is to keep approval on for tools that modify data; Claude asks for approval per tool and advises reserving "allow always" for trusted servers. And the log records the attempt, so an injection that was blocked is visible afterwards rather than silent.

Budget und Protokolle: Mach die Arbeit des Agenten so überprüfbar wie die eines Menschen.

Budget ist aus zwei Gründen wichtig. Der offensichtliche Grund ist die Kosten: Ein Agent, der ein vages Ergebnis erhält, wird so lange Tools aufrufen, bis etwas ihn stoppt, und OWASP listet ungebundene Nutzung als eigenes Risiko auf. Der subtilere Grund ist der Einflussbereich: Eine Obergrenze pro Integration begrenzt, wie viel ein kompromittierter oder verwirrter Agent tun kann, bevor eine Person es bemerkt. Wenn der eigene Agent der Person das Denken übernimmt, trägt sie die Kosten der KI; wenn der Agent des Systems dies übernimmt, sollte die Obergrenze pro Integration festgelegt und pro Aktion sichtbar sein.

Protokolle verwandeln all dies von einem Versprechen in etwas, das Sie prüfen können. Jeder Anruf sollte festhalten, für wen der Agent gehandelt hat, welches Tool verwendet wurde, die Eingaben, das Ergebnis und die Zeit, an dem Ort, an dem das System aufzeichnet, was die Menschen getan haben. Der Test ist, ob ein Finanzleiter herausfinden kann, was der Agent letzten Monat mit dem Konto eines Kunden gemacht hat, ebenso einfach wie bei einem Kollegen. Die MCP-Spezifikation fordert die Kunden auf, die Nutzung von Tools für Prüfungen zu protokollieren; ein Geschäftssystem sollte sich nicht auf den Kunden dafür verlassen, da der Kunde nicht das System der Aufzeichnung ist.

Eine Checkliste, die du gegen jedes System verwenden kannst.

Bringen Sie diese zu jedem Anbieter, einschließlich uns. Jedes ist ein Ja oder Nein, und jedes hat einen Test anstelle einer Frage.

1. Der Agent verbindet sich als benannte Person über OAuth, ohne einen unternehmensweiten Schlüssel zum Einfügen. Test: Verbinden Sie sich von einem externen MCP-Client und sehen Sie, was die Anmeldeseite verlangt.
2. Die Werkzeugliste variiert je nach Rolle. Test: Verbinden Sie sich als eingeschränkter Benutzer und als Administrator und vergleichen Sie, was dem Agenten angeboten wird.
3. Die Überprüfung wird wiederholt, wenn das Werkzeug ausgeführt wird. Test: Entfernen Sie eine Berechtigung von einem verbundenen Benutzer während der Sitzung und versuchen Sie die Aktion erneut.
4. Der Zugriff wird verweigert. Test: Rufen Sie ein Werkzeug auf, das die Rolle nicht haben sollte, und bestätigen Sie, dass Sie eine Ablehnung und kein Ergebnis erhalten.
5. Die Ausgaben können pro Integration begrenzt werden und pro Aktion angezeigt werden. Test: Setzen Sie eine kleine Obergrenze und beobachten Sie, wie sie bindet.
6. Jede Aktion wird der Person zugeordnet, mit Eingaben und Ergebnis, wo das System alles andere protokolliert. Test: Lesen Sie das Protokoll für einen Lauf, den Sie gerade durchgeführt haben.
7. Folgenreiche Werkzeuge sind zur Bestätigung gekennzeichnet daher fragt der Kunde eine Person. Test: Bitte den Agenten, Geld zu senden oder einen Datensatz zu löschen, und bestätige, dass du zuerst gefragt wirst.

Sois ist ein System, das entwickelt wurde, um diese Liste zu übermitteln, und die Form oben im Artikel ist seine Form. Ein Arbeitsbereich ist ein MCP-Server; jeder MCP-Client verbindet sich, indem er die Arbeitsbereichsadresse hinzufügt und sich einmal über OAuth anmeldet; Werkzeuge werden vor der Bereitstellung nach Rolle gefiltert und bei der Ausführung erneut überprüft; der Zugriff wird geschlossen verweigert; Ausgaben können pro Integration begrenzt werden; jede Aktion wird protokolliert; und Netzwerke, die auf der Plattform aufgebaut sind, haben ihre eigene Datenbank, Speicherung, Domains und Schlüssel. Führe trotzdem die Checkliste dagegen aus. Der Wert einer Checkliste besteht darin, dass sie niemandes Wort akzeptiert.

Fragen, die Menschen stellen

Dieser Artikel wird überprüft, wenn sich die beschriebenen Produkte ändern. Nächste geplante Überprüfung: 4. Dezember 2026.