MCP-Server entwickeln.
Systeme gezielt verbinden.
Eine KI soll nicht nur antworten, sondern gezielt mit vorhandenen Systemen arbeiten. DAXS entwickelt passende MCP-Server und Adapter – mit klaren Werkzeugen, begrenzten Rechten und überprüfbaren Ergebnissen.
Ein MCP-Server macht definierte Funktionen für KI-Anwendungen nutzbar.
Ein Assistent soll einen Ticketstatus abrufen, freigegebene Dokumentation durchsuchen oder einen vorbereiteten Eintrag anlegen können. Dafür braucht er einen klar beschriebenen, begrenzten Zugriff. DAXS entwickelt passende MCP-Server und die dahinterliegenden API-Anbindungen für vorhandene Unternehmenssysteme.
Das Model Context Protocol beschreibt, wie KI-Anwendungen unter anderem Werkzeuge, Datenressourcen und vorbereitete Prompts nutzen können. Ein MCP-Server ist dabei ein technischer Adapter. Er wird durch einen guten Werkzeugnamen allein weder sicher noch zu einem selbstständig arbeitenden Agenten.
Klassische API
Eine Anwendung ruft eine festgelegte Funktion eines anderen Systems auf. Datenmodell, Berechtigungen, Validierung und Fehlerbehandlung werden für diesen Zugriff geplant.
MCP-Integration
Ein kompatibler KI-Client kann beschriebene Funktionen und Ressourcen über ein gemeinsames Protokoll nutzen. Die konkrete Freigabe und die Umsetzung im Zielsystem bleiben eigene Aufgaben.
KI-Agent
Eine Anwendung kombiniert Modell, Zustand und Werkzeuge für mehrere Schritte. Dafür braucht sie einen begrenzten Auftrag, Abbruchbedingungen und eine nachvollziehbare Kontrolle ihrer Aktionen. Ein Agent kann MCP oder andere APIs verwenden.
Client, Schnittstelle und Zielsystem prüfen ihren jeweiligen Bereich.
Die KI-Anwendung schlägt einen Werkzeugaufruf vor. Der MCP-Server prüft Identität, erlaubte Funktion und Eingaben. Das Zielsystem setzt seine Zugriffsregeln zusätzlich durch. Für kritische Aktionen wird eine konkrete Freigabe vor der Ausführung geprüft.
Die Zeichnung zeigt eine Beispielarchitektur für eine individuelle Integration. Welche Client-, SDK- und Protokollversionen zusammenspielen, wird vor der Umsetzung festgelegt und getestet.
Der Auftrag bestimmt Daten und Aktionen.
Eine Schnittstelle zum Ticketsystem muss nicht die gesamte Datenbank freigeben. Ein Werkzeug kann beispielsweise genau die für eine erlaubte Statusauskunft benötigten Felder liefern. Ein anderes legt ausschließlich einen Entwurf an. Allgemeine Shell-, SQL- oder Administrationsfunktionen wären dafür ein unnötig großer Rahmen.
| Art | Mögliches Werkzeug | Wichtige Prüfung |
|---|---|---|
| Lesend | Ticketstatus abrufen, freigegebene Dokumentation suchen oder technischen Zustand abfragen. | Benutzer darf das konkrete Objekt sehen; nur benötigte Felder, begrenzte Ergebnismenge und keine fremden Mandantendaten liefern. |
| Schreibend, begrenzt | Einen Antwortentwurf oder eine strukturierte interne Notiz vorbereiten. | Felder und zulässige Inhalte prüfen, Entwurf klar kennzeichnen, Wiederholungen kontrollieren und Ergebnis nachvollziehbar zurückgeben. |
| Kritisch | Eine vereinbarte Änderung an einem produktiven System anstoßen. | Zusätzliche, an Aktion und Zielobjekt gebundene Freigabe; Berechtigung unmittelbar vor Ausführung erneut prüfen, Grenzen und Rückweg festlegen. |
Auch ein lesendes Werkzeug kann vertrauliche Daten offenlegen. „Nur lesen“ ersetzt deshalb keine Autorisierung. Für schreibende Aufrufe planen wir außerdem Idempotenz, Fehlerzustände und den Umgang mit unklaren Ergebnissen: ein Timeout ist kein Beweis, dass die Aktion nicht ausgeführt wurde.
Eine erfolgreiche Anmeldung ist noch keine Erlaubnis für jedes Objekt.
Wir unterscheiden die Anmeldung am KI-Client, die Autorisierung am MCP-Server und die Berechtigungen in der Zielanwendung. Benutzer-, Gruppen- und Mandantenkontext kommen aus einer vertrauenswürdigen Identität. Das Modell darf sich seine Rolle oder den erlaubten Datenbereich nicht selbst als Texteingabe festlegen.
Bei einer entfernten HTTP-Integration gehört ein geeignetes Autorisierungskonzept dazu. Tokens müssen für den vorgesehenen Dienst bestimmt sein und hinsichtlich Gültigkeit und Umfang geprüft werden. Zugangsdaten für nachgelagerte Systeme werden passend zum jeweiligen Ziel geschützt und begrenzt. Ein beliebig weitergereichtes Client-Token ist kein universeller Systemzugang.
Ein lokaler Prozessanschluss hat andere Grenzen als ein entfernter Unternehmensdienst: etwa das gestartete Programm, dessen Herkunft und seine Betriebssystemrechte. Die einfache lokale Ausführung ersetzt keine Prüfung des Programms oder seiner Datenzugriffe. Für beide Varianten vereinbaren wir erlaubte Verbindungen und technische Zuständigkeiten.
MCP ist ein Protokoll, keine vollständige Sicherheitsarchitektur.
Die eigentliche Begrenzung wird durch Serverlogik, Zielsystemrechte, geschützte Zugangsdaten, Netzwerkregeln und überprüfbare Freigaben durchgesetzt. Die passende Umsetzung richtet sich nach Client, Daten, Aktionen und Betriebsmodell.
Die Grenzen gelten auch bei unpassenden Modellvorschlägen.
Ein Dokument, Tickettext oder Werkzeugergebnis kann manipulierte Anweisungen enthalten. Solche Inhalte werden als Daten behandelt. Sie dürfen weder neue Rechte vergeben noch die Ausführung einer eigentlich gesperrten Aktion rechtfertigen. Hinweise im Prompt können die Anwendung unterstützen; die verbindliche Kontrolle liegt außerhalb des Modells.
Eingaben und Ziele
Typen, erlaubte Werte, Objektbezug, Pfade und Ergebnismengen serverseitig validieren. Zulässige APIs und Netzwerkziele begrenzen; keine frei zusammengesetzten Befehle oder unkontrollierten Adressaufrufe.
Aktionen und Freigaben
Aufrufumfang und Seiteneffekte verständlich anzeigen. Kritische Freigaben an die konkrete Operation binden, zeitlich begrenzen und vor der Ausführung nachprüfen. Abbruch- und Wiederholungsregeln festlegen.
Betrieb und Nachvollziehbarkeit
Rate Limits, Zeitlimits, Fehlerbehandlung und zweckgebundene Protokolle vorsehen. Zugangsdaten nicht in Modellkontext oder Diagnoseausgaben aufnehmen. Auffällige Zugriffe untersuchen und Zugänge entziehen können.
Wir prüfen normale Abläufe ebenso wie verbotene Objektzugriffe, manipulierte Inhalte, abgelaufene Berechtigungen, doppelte Aufrufe und eine verweigerte Freigabe. Das reduziert Risiken; eine allgemeine Zusage, jede Prompt Injection sicher zu verhindern, wäre nicht seriös.
Mit einer überschaubaren Funktion beginnen.
Wir nehmen Zielanwendung, vorhandene APIs, Benutzerrollen und benötigte Felder auf. Daraus entsteht ein begrenzter Werkzeugkatalog mit klaren Eingaben und Ergebnissen. Ein lesender Pilot kann zeigen, ob die Integration im Alltag nützt; schreibende Schritte werden bei Bedarf getrennt ergänzt und geprüft.
- Auftrag abgrenzen: welches Problem, welche Objekte und welche Benutzer?
- Schnittstelle entwickeln: Ziel-API anbinden, Werkzeug beschreiben, Rechte und Fehlerfälle umsetzen.
- Praktisch abnehmen: erlaubte und verbotene Fälle, Freigaben und Wiederholungen prüfen.
- Betreut übergeben: Dokumentation, Zugangsverwaltung, Versionspflege und Zuständigkeiten festhalten.
DAXS kann diese Arbeit als individuelle Entwicklung und Integration übernehmen. Eine reine Datenabfrage kann auch mit einer klassischen API oder einem Skript sinnvoll gelöst sein. Den passenden Umfang besprechen wir anhand Ihrer vorhandenen Systeme.
Eine konkrete gewünschte Funktion, die betroffene Anwendung, vorhandene API-Unterlagen und ein anonymisiertes Beispiel. Zugangsdaten oder vertrauliche Kundendaten gehören nicht in eine öffentliche Anfrage.
Das klären wir im Gespräch.
Was unterscheidet eine API von MCP?
Eine API stellt Funktionen eines Systems bereit. MCP beschreibt eine gemeinsame Art, Werkzeuge und Kontext für unterstützende KI-Anwendungen anzubieten. Ein MCP-Server kann dafür vorhandene APIs verwenden; deren Rechte und fachliche Regeln bleiben erforderlich.
Braucht jede Automatisierung einen KI-Agenten?
Nein. Ein fest definierter Import oder eine eindeutige Berechnung lässt sich oft mit einem Skript oder einer direkten API-Anbindung einfacher umsetzen. Ein Agent kommt in Betracht, wenn variable Aufgaben tatsächlich eine flexible Auswahl von Schritten erfordern.
Darf ein MCP-Werkzeug selbst Änderungen durchführen?
Wenn das fachlich gewünscht und technisch abgesichert ist. Lesende Funktionen, begrenzte Änderungen und kritische Aktionen werden getrennt behandelt. Freigaben, Zielrechte, Eingabeprüfung und nachvollziehbare Ergebnisse gehören zur jeweiligen Funktion.
Reicht die Anmeldung beim KI-Dienst als Berechtigung?
Nein. Der Server muss den Aufrufer und seine Befugnisse prüfen; das Zielsystem muss den Zugriff auf die konkrete Funktion und das konkrete Objekt ebenfalls erlauben. Ein Werkzeugaufruf darf keine Rechte erzeugen, die der Benutzer sonst nicht hat.
Wie beginnt ein sinnvoller Pilot?
Mit einem klaren Nutzen und wenigen begrenzten Werkzeugen, möglichst zunächst lesend. Wir legen Erfolgskriterien fest und testen unerlaubte Zugriffe, problematische Inhalte, Zeitüberschreitungen sowie wiederholte Aufrufe, bevor schreibende Funktionen ausgebaut werden.
Ein Werkzeugzugriff ist noch keine Betriebserlaubnis.
Ein Agent auf einem Linux-System kann APIs, lokale Werkzeuge oder externe Dienste verwenden. Eigene Dienstidentität, begrenzte Dateizugriffe, Prozessisolation, erlaubte Netzwerkziele und sicher verwaltete Zugangsdaten werden getrennt geplant. Ein lokaler Agent ist damit nicht automatisch offline; jeder externe Aufruf gehört in den Datenfluss. Modellwechsel, Werkzeugfehler, Laufzeit und Kostenlimits sowie ein nachvollziehbarer Abbruchweg werden mitgetestet.
Rechte und Freigaben für Agenten vertiefen
Skript, Workflow oder KI-Agent: konkrete Entscheidungsfragen
Besprechen wir Ihren Anwendungsfall.
Was soll einfacher werden, welche Daten sind beteiligt und welche Systeme sind bereits vorhanden? Daraus entwickeln wir einen sinnvollen Einstieg und einen überschaubaren nächsten Schritt.