MCP in der Produktion: Sichere Tools für KI-Agenten

Tools sind der Punkt, an dem Agenten gefährlich werden

Lass es mich direkt sagen: Ein Sprachmodell, das nur reden kann, ist sicher und ziemlich nutzlos. Ein Modell, das Tools aufrufen kann, eine Bestellung nachschlagen, eine Rückerstattung auslösen, in eine Datenbank schreiben, ist nützlich und wirklich gefährlich. In dem Moment, in dem du einem Agenten die Fähigkeit gibst zu handeln, musst du die Fragen beantworten, die ein Security-Team über jeden Akteur stellt: Was kann er tun, wer hat ihn autorisiert, und was hat er tatsächlich getan?

Das Model Context Protocol, kurz MCP, ist zum Standardweg geworden, KI-Agenten Tools zu geben. Es ist ein sauberes Protokoll, und genau deshalb ist der schwierige Teil nicht das Anbinden der Tools, sondern deren Governance. Ein MCP-Server, der deine Geschäftsoperationen ohne Autorisierung, Limits und Audit einem Agenten zugänglich macht, ist ein Sicherheitsvorfall auf Abruf. Dieser Leitfaden zeigt dir, wie du MCP in der Produktion betreibst, ohne dass es dazu kommt.

Ein Tool an einen Agenten anzubinden ist eine Sache von fünf Minuten. Sicherzustellen, dass der Agent nicht mehr tun kann als seinen Job, dass jeder Aufruf autorisiert ist und dass du rekonstruieren kannst, was passiert ist, das ist das eigentliche Engineering.

Wir betreiben MCP in der Produktion in unserer eigenen Exfinity-Plattform, wo ein MCP-Server Commerce-, Analytics- und Market-Intelligence-Tools unter strikter Governance für Agenten bereitstellt. Dieser Leitfaden ist genau diese Architektur. Für das größere Agenten-Bild sieh dir unseren Leitfaden zu agentischen KI-Systemen an, und das hier ist Kernarbeit unserer KI-Services.

Wer sich wofür interessiert

Was MCP wirklich ist

MCP ist ein Protokoll, um Tools und Kontext auf standardisierte Weise für KI-Agenten bereitzustellen. Statt für jeden Model-Client eigenen Integrations-Glue zu schreiben, betreibst du einen MCP-Server, der eine Menge von Tools ankündigt, und jeder MCP-fähige Client, ein Coding-Assistent, ein Chat-Agent, deine eigene Runtime, kann sie entdecken und aufrufen.

Der Wert ist die Standardisierung: ein Tool-Server, viele Clients, ein konsistenter Vertrag. Das Risiko ist ebenfalls die Standardisierung: Ein über MCP bereitgestelltes Tool ist für jeden Agenten offen, der sich verbindet, also muss die Governance am Server leben und darf nicht beim Client vorausgesetzt werden. Unser Leitfaden zu Multi-Agent-Architekturen behandelt, wie Agenten und Tools zusammenspielen.

Tools designen, die ein Agent sicher nutzen kann

Ein gutes MCP-Tool ist nicht einfach ein API-Endpoint mit einer Beschreibung. Es ist für einen Akteur designt, der es auf Weisen aufrufen wird, mit denen du nicht gerechnet hast.

In Exfinity sind Tools danach gruppiert, was sie berühren, Commerce, Empfehlungen, Analytics, Market Intelligence, und ein Tenant sieht nur die Tools, die sein Plan und seine Berechtigungen erlauben. Die Designregel: Der Wirkungsradius eines Tools sollte zu seiner Berechtigung passen, sodass ein Lese-Tool offen sein kann, während ein Tool, das Geld bewegt, streng gegatet ist. Unser API-Design-Leitfaden behandelt, wie du diese Verträge langlebig designst.

Policy-Durchsetzung an drei Punkten

Das ist der Kern von sicherem MCP, und genau hier sind die meisten Implementierungen dünn. Du setzt Policy an drei Punkten in jedem Tool-Aufruf durch, nicht an einem.

Agent asks to call a tool
   │
   ▼
[1] Pre-execution   ── is this tenant/agent allowed to call this tool?
   │                    (reject here if not)
   ▼
[2] Runtime         ── guardrails inside the tool: scope constraints,
   │                    "never book without explicit consent"
   ▼
Tool executes
   │
   ▼
[3] Post-execution  ── log the call: who, what, input, output, when

Pre-Execution-Validierung prüft, ob dieser Tenant und dieser Agent dieses Tool überhaupt aufrufen dürfen, bevor irgendetwas läuft. Ein Berechtigungsfehler stoppt hier.

Runtime-Guardrails leben im Tool selbst und kodieren Constraints, die die Policy nicht als einfaches Ja oder Nein ausdrücken kann, etwa niemals eine irreversible Aktion ohne explizite Zustimmung des Users auszuführen.

Post-Execution-Audit protokolliert jeden Aufruf mit Tenant, Akteur, Tool, Input, Output und Zeitpunkt, sodass das Ganze im Nachhinein rekonstruierbar ist.

Exfinity setzt alle drei bei jedem Tool-Aufruf durch. Ein Check reicht nicht, denn ein Tool, das laufen darf, kann trotzdem gebeten werden, etwas zu tun, was es nicht soll, und eine Aktion, die gelaufen ist, muss trotzdem aktenkundig sein. Unser KI-Governance-Leitfaden behandelt diese Defense-in-Depth-Haltung.

Capability-Scopes: Nicht alle Tools sind gleich

Ein Refund-Tool und ein Such-Tool sollten nicht dieselbe Berechtigung tragen. Der Weg, das real zu machen, sind Capability-Scopes: Gruppiere Tools nach der Art von Macht, die sie halten, und gate jede Gruppe separat.

Exfinity gatet Write-Tools, Content-Tools und Crawl-Tools separat von Read-Tools, sodass ein Agent, der auf das Beantworten von Fragen gescopet ist, nicht plötzlich eine Buchung ausführen kann. Das Prinzip: Je irreversibler oder teurer die Aktion, desto enger das Gate. Das ist dasselbe Least-Privilege-Denken wie in unserem Leitfaden zum Härten von Cloud-Security, angewandt auf Agenten-Tools.

Ein durchgespieltes Beispiel: ein Tool-Aufruf unter Governance

Verfolge einen einzelnen Tool-Aufruf durch die Governance, denn das Drei-Punkte-Modell ist in Bewegung am klarsten.

Ein Kunde sagt einem Chat-Agenten: „Storniere meine Buchung XFt-55231 und erstatte mir das Geld.“ Der Agent entscheidet sich, das cancelBooking-Tool aufzurufen. Das macht der MCP-Server.

1. Discover   the agent's tenant only sees tools its plan allows; cancel
              is present because this tenant has it
2. Pre-check  is this tenant and this agent permitted to call cancelBooking?
              cancel is a write, monetary-adjacent tool, tightly scoped.
              permitted -> continue; not -> reject here, nothing runs
3. Runtime    the tool's own guardrail: cancellation over a value threshold
              requires explicit confirmation, so it pauses for consent
              rather than cancelling immediately
4. Execute    on consent, the cancellation runs, scoped to this tenant's
              booking only, never able to touch another tenant's data
5. Audit      the call is logged: tenant, actor, tool, input, output, time,
              and the policy decision, all reconstructable later

Drei separate Gates haben drei separate Jobs erledigt. Der Pre-Check hat entschieden, ob der Aufruf überhaupt erlaubt war. Der Runtime-Guardrail hat das abgefangen, was eine Ja-oder-Nein-Berechtigung nicht ausdrücken kann, dass eine Stornierung mit hohem Wert Zustimmung braucht. Das Audit hat das Ganze rekonstruierbar gemacht. Nimm eines davon weg und du hast ein Loch: Ohne Pre-Check handelt ein nicht autorisierter Agent, ohne Runtime-Guardrail tut ein autorisierter Agent etwas Unüberlegtes, ohne Audit kannst du nicht beweisen, was passiert ist. Alle drei, bei jedem Aufruf. Unser KI-Governance-Leitfaden behandelt, warum diese Schichtung zählt.

Rate Limits und Timeouts: einen Ausreißer eindämmen

Ein Agent in einer Schleife kann ein Tool hunderte Male hämmern, und ein langsames Tool kann einen Agenten-Turn hängen lassen. Beides braucht Grenzen.

Rate Limits pro Session begrenzen, wie viele Tool-Aufrufe ein Agent in einem Zeitfenster machen kann, und Timeouts pro Tool stoppen einen langsamen Aufruf, bevor er den Turn hängen lässt. In Exfinity ist eine Session auf eine begrenzte Zahl von Tool-Aufrufen pro Minute gedeckelt, mit einem Ausführungs-Timeout pro Tool, sodass ein fehlverhaltender oder kompromittierter Agent deinen Tool-Server nicht in einen Denial-of-Service auf deine eigenen Systeme verwandeln kann. Kombiniert mit den Grenzen pro Agenten-Turn aus unserem Leitfaden zu Agenten-Gedächtnis sind diese Limits das, was dich echte Operationen einem autonomen Agenten zugänglich machen und trotzdem ruhig schlafen lässt. Unser Leitfaden zum Designen von Systemen für den Fehlerfall behandelt diese Eindämmungs-Denkweise.

Custom Tools: erweitern, ohne die Kontrolle zu verlieren

Echte Plattformen brauchen Tools pro Tenant, den eigenen Endpoint eines Kunden, der seinen Agenten zugänglich gemacht wird. Die Falle ist, das zu einem Loch ohne Governance werden zu lassen.

Das sichere Muster ist Registrierung plus dieselbe Governance. Ein Tenant registriert einen externen Endpoint mit einem Allowed-Host und einem Parameter-Schema, und der MCP-Server stellt ihn dynamisch neben den eingebauten Tools bereit, unter derselben Policy-Durchsetzung an drei Punkten. In Exfinity werden Custom-Connector-Tools zentral definiert und pro Tenant bereitgestellt, mit Policy-Durchsetzung exakt wie bei eingebauten Tools, sodass das Erweitern des Toolsets die Governance nicht schwächt. Unser Leitfaden zu Enterprise-Integration behandelt das sichere Anbinden externer Systeme.

Erste Schritte

1. Designe Tools eng. Ein Job pro Tool, idempotente Writes, Lesen und Schreiben getrennt.
2. Setze an drei Punkten durch. Pre-Execution-Berechtigung, Runtime-Guardrails, Post-Execution-Audit.
3. Scope nach Capability. Gate Write-Tools und irreversible Tools deutlich enger als Reads.
4. Begrenze jede Session. Rate Limits und Timeouts pro Tool, um einen Ausreißer einzudämmen.
5. Governe Custom Tools identisch. Registrierung plus dieselbe Policy, keine Löcher ohne Governance.

Das ist etappenweise angelegt und passt zu unserer Methodik. Unsere Teams für Individualsoftware und Consulting bauen MCP-Server mit Governance. Starte über Kontakt oder hol dir ein gescopetes Angebot.

Wie das typischerweise schiefgeht

1. Tools ohne Autorisierung bereitstellen. Ein Tool über MCP ist für alles offen, was sich verbindet. Gate am Server.
2. Ein Check statt drei. Laufen zu dürfen ist nicht die ganze Geschichte. Setze pre, runtime und post durch.
3. Gleiche Berechtigung für alle Tools. Ein Refund ist keine Suche. Scope nach Capability.
4. Keine Rate Limits. Ein loopender Agent wird zum selbstverschuldeten Denial-of-Service. Begrenze jede Session.
5. Custom Tools ohne Governance. Tools pro Tenant brauchen dieselbe Policy wie eingebaute. Keine Ausnahmen.

Wer das baut

Oronts ist ein gründergeführtes Softwareunternehmen in München. Refaat Al Ktifan, unser Gründer und Solution Architect, führt ein Senior-Team über Backend, KI und Security hinweg. Wir betreiben einen MCP-Server mit voller Governance in unserer eigenen Exfinity-Plattform und stellen Agenten echte Operationen unter Policy-Durchsetzung an drei Punkten, Capability-Scopes und Audit bereit. Wir designen die Tools, bauen die Governance und übergeben dir eine MCP-Oberfläche, die du Agenten zugänglich machen kannst, ohne die Kontrolle zu verlieren. Sieh dir unsere Seiten zu Services und Lösungen an.

Das Wichtigste

• MCP standardisiert Agenten-Tools. Der schwierige Teil ist die Governance, nicht das Anbinden.
• Designe Tools eng, mit idempotenten Writes und Lesen getrennt von Schreiben.
• Setze Policy an drei Punkten durch: Pre-Execution-Berechtigung, Runtime-Guardrails, Post-Execution-Audit.
• Scope Tools nach Capability und gate irreversible Aktionen deutlich enger als Reads.
• Begrenze jede Session mit Rate Limits und Timeouts, und governe Custom Tools identisch.

Einem Agenten Tools zu geben heißt, ihm die Macht zu geben zu handeln. Behandle den MCP-Server wie jeden anderen privilegierten Akteur: Least Privilege, jede Aktion autorisiert, jede Aktion geloggt. Dann ist Autonomie sicher statt beängstigend.

Du willst KI-Agenten echte Operationen zugänglich machen? Erzähl uns, was sie tun müssen. Starte über Kontakt oder hol dir ein gescopetes Angebot.