Ihr KI-Agent stößt ohne Webzugriff an eine Grenze: warum Teams ein MCP-Gateway statt 20 fragiler Integrationen brauchen

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich betreibe mit DennisCraft AI Studio produktive KI-Systeme auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Der typische Ausfall in der Praxis sieht oft unspektakulär aus: Der Agent formuliert noch sauber, kommt aber nicht mehr an aktuelle Webinformationen, Dokumentation, Ticketstände, Auftragsstatus oder interne Werkzeuge, die er für eine belastbare Ausführung braucht.

Genau dort liegt für viele Teams die eigentliche Grenze. Nicht das Modell ist zuerst das Problem, sondern die Architektur des Werkzeugzugriffs. Wenn Ihr Agent getrennte Anbindungen an CRM, ERP, Helpdesk, Datenbank, interne Wissensquellen und ausgewählte externe Webseiten benötigt, betreiben Sie kein einheitliches Agentensystem, sondern einen Verbund aus fragilen Einzelintegrationen.

Warum fehlender Webzugriff im Produktivbetrieb schnell zum Engpass wird

In einer Vorführung wirkt eingeschränkter Zugriff vernünftig. Im Produktivbetrieb bedeutet er oft veralteten Kontext. Ein Agent ohne Zugriff auf aktuelle Informationen antwortet dann aus alten Abrufen, statischen Prompts oder teilweise gepflegten Speichern. Das funktioniert nur so lange, bis eine Aufgabe von Änderungen abhängt, die heute Morgen eingetreten sind.

Statischer Kontext veraltet schnell

Ein RAG-System kann Dokumentation, interne Prozesse und Richtlinien bereitstellen. Es bildet aber nicht automatisch den aktuellen Stand einer Lieferkette, eine Änderung im API-Schema, einen bearbeiteten Supportfall oder eine neue Preisregel ab. Genau diese Differenz entscheidet in Logistik, Fintech und industrieller Automatisierung über brauchbar oder unbrauchbar.

Direkte Anbindungen scheitern auf unterschiedliche Weise

Ein Skript spricht mit Postgres, ein anderes mit einer REST-API, ein drittes ruft n8n auf, ein viertes liest eine Dokumentationsseite. Jede dieser Verbindungen bringt eigene Authentisierung, Zeitüberschreitungen, Wiederholungslogik, Ratenbegrenzungen und Fehlermeldungen mit. Bei 3 Integrationen ist das noch beherrschbar. Bei 20 kennt meist niemand mehr die gesamte Fehleroberfläche.

Zugriffsrechte wachsen unkontrolliert

OWASP führte 2021 Broken Access Control auf Platz 1 der Top-10-Risiken und nannte 94% der getesteten Anwendungen als betroffen (OWASP Top 10, 2021, https://owasp.org/Top10/). Für Agentensysteme ist das besonders relevant, weil jeder Werkzeugaufruf eine weitere Berechtigungsgrenze darstellt. Werden diese Grenzen einzeln und ohne zentrales Regelwerk umgesetzt, entsteht schleichend zu viel Zugriff.

Warum ein zentrales MCP-Gateway besser ist als viele Einzelintegrationen

Entscheidend ist hier nicht ein Schlagwort, sondern ein Architekturprinzip. Ein MCP-Gateway bildet eine standardisierte Zugriffsschicht zwischen Modell und Werkzeugen. Das Modell erhält eine einheitliche Schnittstelle. Das Gateway übernimmt Weiterleitung, Authentisierung, Autorisierung, Protokollierung und Vereinheitlichung der Antworten.

In regulierten DACH-Umgebungen ist das besonders hilfreich. DSGVO, ISO 27001, BSI Grundschutz oder NIS2 verlangen keine bestimmte KI-Architektur, aber sie belohnen Systeme mit klaren Verantwortlichkeiten, nachvollziehbaren Zugriffspfaden und prüfbarer Protokollierung. Ein zentrales Gateway ist dafür deutlich einfacher zu bewerten als ein unübersichtlicher Werkzeugverbund.

So sieht eine praxistaugliche Architektur aus

Die minimale Struktur ist einfach: Claude erhält eine Aufgabe, fordert ein Werkzeug über eine standardisierte Schnittstelle an, das Gateway prüft die Berechtigung, ruft das Zielsystem auf und liefert eine vereinheitlichte Antwort zurück. Die Modellseite bleibt klein und stabil. Die Komplexität liegt dort, wo sie hingehört: in der Infrastruktur.

Einfache Berechtigungsprüfung vor der Ausführung

from typing import Dict

ALLOWED_TOOLS = {
    "support_agent": {"search_docs", "get_order_status"},
    "ops_agent": {"search_docs", "get_order_status", "update_ticket"},
}

def can_call(agent_role: str, tool_name: str) -> bool:
    return tool_name in ALLOWED_TOOLS.get(agent_role, set())

def execute_tool(agent_role: str, tool_name: str, args: Dict):
    if not can_call(agent_role, tool_name):
        raise PermissionError(f"{agent_role} cannot call {tool_name}")
    return {"tool": tool_name, "args": args, "status": "accepted"}

print(execute_tool("support_agent", "get_order_status", {"order_id": "A-441"}))

Das Beispiel ist absichtlich schlicht. Genau diese Schicht fehlt jedoch oft in eilig gebauten Agentensystemen. Es wird geprüft, ob ein Werkzeug technisch funktioniert. Nicht geprüft wird, ob der Agent es überhaupt aufrufen darf, unter welchen Bedingungen und mit welcher Nachvollziehbarkeit.

Schlankes HTTP-Gateway für interne Werkzeuge

import express from "express";

const app = express();
app.use(express.json());

app.post("/tool/get_order_status", async (req, res) => {
  const { orderId } = req.body;
  if (!orderId) return res.status(400).json({ error: "missing orderId" });

  res.json({
    orderId,
    status: "in_transit",
    source: "postgres",
    checkedAt: new Date().toISOString()
  });
});

app.listen(3000, () => console.log("gateway on :3000"));

Schon diese kleine Schicht schafft einen zentralen Ort für Protokollierung, Ratenbegrenzung, Maskierung personenbezogener Daten und Geheimnisverwaltung über Doppler. Außerdem erhalten Sie ein einheitliches Fehlermodell gegenüber dem Agenten statt vieler unterschiedlicher Antworten.

Wo Webzugriff wirklich nötig ist und wo nicht

Nicht jeder Agent braucht offenen Internetzugang. Viele brauchen aber kontrollierten Webzugriff. Ich trenne das in 3 Kategorien.

Ausgewählter externer Webzugriff

Dokumentation von Anbietern, öffentliche Regelseiten, Änderungsprotokolle oder Statusseiten. Solche Quellen sollten über eine Positivliste, Zwischenspeicherung und Protokollierung eingebunden werden. Es geht nicht um freies Surfen, sondern um aktuellen, begrenzten Kontext.

Interne Web- und Dienstzugriffe

Supportportale, interne Dokumentationen, Verwaltungsoberflächen, Kundenbereiche und Workflow-Endpunkte. Dieser Zugriff ist oft wichtiger als das öffentliche Web, weil dort die operative Wahrheit liegt.

Kein Webzugriff

Für eng umrissene Aufgaben wie Dokumentklassifikation, SQL-Auswertung auf festen Tabellen oder interne Ticketvorsortierung reicht ein geschlossenes System aus. Der Fehler besteht darin, diese Ausnahme zum allgemeinen Architekturprinzip zu machen.

Was Sie vor der Bereitstellung prüfen sollten

Die Dokumentation von Anthropic zur Werkzeugnutzung betont strukturierte Schnittstellen und klar definierte Verträge zwischen Modell und externer Aktion (Anthropic Dokumentation, abgerufen 2026, https://docs.anthropic.com/). Genau darauf sollte auch Ihr Gateway ausgelegt sein: klein, explizit und prüfbar.

export TOOL_GATEWAY_URL=http://localhost:3000
export ALLOWLIST_DOMAIN=docs.example.com
export LOG_LEVEL=info

curl -X POST "$TOOL_GATEWAY_URL/tool/get_order_status" \
  -H "Content-Type: application/json" \
  -d '{"orderId":"A-441"}'

Meine kurze Prüfliste für den Produktivbetrieb ist in fast allen Projekten gleich:

• Minimalrechte pro Werkzeug;
• zentrale Protokollierung jedes Aufrufs;
• Geheimnisse außerhalb des Anwendungscodes;
• vereinheitlichte Antwortformate an das Modell;
• Ersatzverhalten, wenn eine Webquelle nicht erreichbar ist.

Wenn Sie bereits n8n einsetzen, müssen Sie es nicht ersetzen. Ich nutze n8n meist weiterhin für die Prozessorchestrierung und setze das MCP-Gateway davor als Zugriffs- und Richtlinienebene. Diese Trennung vereinfacht beide Seiten.

FAQ

Ersetzt ein MCP-Gateway RAG?

Nein. RAG dient dem Abruf bekannter Inhalte aus einem definierten Bestand. Ein Gateway dient dem kontrollierten Zugriff auf aktuelle Werkzeuge und laufende Systeme.

Kann man vollständig auf Webzugriff verzichten?

Ja, wenn die Aufgabe vollständig lokal ist und nicht von veränderlichen Zuständen abhängt. Sobald aktuelle Betriebsdaten nötig sind, wird fehlender Webzugriff schnell zum geschäftlichen Problem.

Warum nicht einfach alle APIs direkt anbinden?

Weil das nur am Anfang schnell ist. Danach steigen Wartungskosten durch doppelte Authentisierung, uneinheitliche Fehlerbehandlung, verteilte Protokolle und unklare Berechtigungen.

Ist das nur für große Konzerne relevant?

Nein. Gerade mittelständische Unternehmen stoßen früh darauf, weil genug Systeme vorhanden sind, aber selten ein großes Plattformteam zur Vereinheitlichung bereitsteht.

Wie beginnt man, wenn bereits viele Provisorien im Einsatz sind?

Verschieben Sie zuerst die 3 wichtigsten Werkzeuge hinter ein zentrales Gateway. Zentralisieren Sie zunächst den Kontrollpunkt und nicht sofort das gesamte System.

An welcher Stelle stößt Ihr Agentensystem derzeit tatsächlich an die Grenze: beim fehlenden Live-Kontext aus dem Web, bei ausufernden Berechtigungen oder bei zu vielen Einzelintegrationen für einen sicheren Produktivbetrieb? Ich würde das gerne konkret wissen.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.