MCP-servers ontwikkelen.
Systemen gericht verbinden.
AI moet niet alleen antwoorden, maar ook gericht met bestaande systemen werken. DAXS ontwikkelt passende MCP-servers en adapters, met duidelijke hulpmiddelen, begrensde rechten en toetsbare resultaten.
Een MCP-server maakt gedefinieerde functies bruikbaar voor AI-applicaties.
Een assistent moet een ticketstatus kunnen ophalen, vrijgegeven documentatie doorzoeken of een voorbereide invoer kunnen aanmaken. Daarvoor is duidelijk beschreven, begrensde toegang nodig. DAXS ontwikkelt passende MCP-servers en achterliggende API-koppelingen voor bestaande bedrijfssystemen.
Het Model Context Protocol beschrijft hoe AI-applicaties onder meer hulpmiddelen, gegevensbronnen en voorbereide prompts kunnen gebruiken. Een MCP-server is daarbij een technische adapter. Een goede toolnaam maakt die op zichzelf niet veilig of tot een zelfstandig werkende agent.
Klassieke API
Een applicatie roept een vastgelegde functie van een ander systeem aan. Gegevensmodel, rechten, validatie en foutafhandeling worden voor deze toegang gepland.
MCP-integratie
Een compatibele AI-client kan beschreven functies en bronnen via een gezamenlijk protocol gebruiken. De concrete goedkeuring en uitvoering in het doelsysteem blijven afzonderlijke taken.
AI-agent
Een applicatie combineert model, toestand en hulpmiddelen voor meerdere stappen. Daarvoor zijn een begrensde opdracht, stopvoorwaarden en inzichtelijke controle van de acties nodig. Een agent kan MCP of andere API's gebruiken.
Client, interface en doelsysteem toetsen elk hun eigen gebied.
De AI-applicatie stelt een toolaanroep voor. De MCP-server toetst identiteit, toegestane functie en invoer. Het doelsysteem handhaaft daarnaast zijn eigen toegangsregels. Voor kritieke acties wordt concrete goedkeuring vóór uitvoering getoetst.
De tekening toont een voorbeeldarchitectuur voor een individuele integratie. Welke client-, SDK- en protocolversies samenwerken, wordt vóór de uitvoering vastgelegd en getest.
De opdracht bepaalt gegevens en acties.
Een interface met het ticketsysteem hoeft niet de hele database vrij te geven. Een hulpmiddel kan bijvoorbeeld precies de velden leveren die nodig zijn voor een toegestane statusvraag. Een ander maakt uitsluitend een concept aan. Algemene shell-, SQL- of beheerfuncties vormen daarvoor een onnodig ruim kader.
| Type | Mogelijk hulpmiddel | Belangrijke toetsing |
|---|---|---|
| Lezend | Ticketstatus ophalen, vrijgegeven documentatie zoeken of technische toestand opvragen. | De gebruiker mag het concrete object zien; alleen benodigde velden, een begrensde resultaatset en geen gegevens van andere tenants leveren. |
| Begrensd schrijvend | Een antwoordconcept of gestructureerde interne notitie voorbereiden. | Velden en toegestane inhoud toetsen, concept duidelijk markeren, herhalingen beheersen en het resultaat inzichtelijk teruggeven. |
| Kritiek | Een afgesproken wijziging aan een productiesysteem in gang zetten. | Aanvullende goedkeuring gebonden aan actie en doelobject; rechten direct vóór uitvoering opnieuw toetsen en grenzen en terugvalroute vastleggen. |
Ook een lezend hulpmiddel kan vertrouwelijke gegevens blootleggen. Alleen lezen vervangt daarom geen autorisatie. Voor schrijvende aanroepen plannen we daarnaast idempotentie, fouttoestanden en omgang met onduidelijke resultaten: een time-out bewijst niet dat de actie niet is uitgevoerd.
Een geslaagde aanmelding geeft nog geen toestemming voor elk object.
We onderscheiden aanmelding bij de AI-client, autorisatie op de MCP-server en rechten in de doelapplicatie. Gebruikers-, groeps- en tenantcontext komen uit een betrouwbare identiteit. Het model mag niet zelf zijn rol of toegestane gegevensgebied via tekstinvoer bepalen.
Bij een externe HTTP-integratie hoort een geschikt autorisatieconcept. Tokens moeten bestemd zijn voor de voorziene dienst en op geldigheid en reikwijdte worden getoetst. Toegangsgegevens voor achterliggende systemen worden passend bij het doel beschermd en begrensd. Een willekeurig doorgestuurd clienttoken is geen universele systeemtoegang.
Een lokale proceskoppeling heeft andere grenzen dan een externe bedrijfsdienst, zoals het gestarte programma, de herkomst en de besturingssysteemrechten. Eenvoudige lokale uitvoering vervangt geen toetsing van het programma of de gegevenstoegang. Voor beide varianten spreken we toegestane verbindingen en technische verantwoordelijkheden af.
MCP is een protocol, geen volledige beveiligingsarchitectuur.
De werkelijke begrenzing wordt afgedwongen door serverlogica, doelsysteemrechten, beschermde toegangsgegevens, netwerkregels en toetsbare goedkeuringen. De passende uitvoering volgt uit client, gegevens, acties en beheermodel.
De grenzen gelden ook bij ongeschikte modelvoorstellen.
Een document, tickettekst of toolresultaat kan gemanipuleerde instructies bevatten. Zulke inhoud wordt als gegevens behandeld. Die mag geen nieuwe rechten toekennen of uitvoering van een geblokkeerde actie rechtvaardigen. Promptinstructies kunnen de applicatie ondersteunen; de bindende controle ligt buiten het model.
Invoer en doelen
Typen, toegestane waarden, objectrelatie, paden en resultaatsets aan de serverkant valideren. Toegestane API's en netwerkdoelen begrenzen; geen vrij samengestelde commando's of ongecontroleerde adresaanroepen.
Acties en goedkeuringen
Aanroepomvang en neveneffecten begrijpelijk tonen. Kritieke goedkeuringen aan de concrete operatie binden, in tijd begrenzen en vóór uitvoering controleren. Stop- en herhalingsregels vastleggen.
Beheer en traceerbaarheid
Rate limits, tijdslimieten, foutafhandeling en doelgebonden logboeken voorzien. Toegangsgegevens niet in modelcontext of diagnose-uitvoer opnemen. Verdachte toegang kunnen onderzoeken en toegangsrechten kunnen intrekken.
We toetsen normale processen en verboden objecttoegang, gemanipuleerde inhoud, verlopen rechten, dubbele aanroepen en geweigerde goedkeuring. Dat vermindert risico's; een algemene belofte om elke promptinjectie veilig te voorkomen zou niet verantwoord zijn.
Beginnen met een overzichtelijke functie.
We inventariseren doelapplicatie, bestaande API's, gebruikersrollen en benodigde velden. Daaruit ontstaat een begrensde toolcatalogus met duidelijke invoer en resultaten. Een lezende pilot kan aantonen of de integratie in de praktijk nuttig is; schrijvende stappen worden waar nodig apart toegevoegd en getoetst.
- Opdracht afbakenen: welk probleem, welke objecten en welke gebruikers?
- Interface ontwikkelen: doel-API koppelen, hulpmiddel beschrijven en rechten en foutscenario's uitwerken.
- Praktisch accepteren: toegestane en verboden gevallen, goedkeuringen en herhalingen toetsen.
- Beheerst overdragen: documentatie, toegangsbeheer, versieonderhoud en verantwoordelijkheden vastleggen.
DAXS kan dit werk als maatwerkontwikkeling en integratie verzorgen. Een zuivere gegevensopvraag kan ook zinvol met een klassieke API of script worden opgelost. De passende omvang bespreken we aan de hand van uw bestaande systemen.
Een concreet gewenste functie, de betrokken applicatie, beschikbare API-documentatie en een geanonimiseerd voorbeeld. Toegangsgegevens of vertrouwelijke klantgegevens horen niet in een openbare aanvraag.
Dat verduidelijken we in het gesprek.
Wat onderscheidt een API van MCP?
Een API stelt functies van een systeem beschikbaar. MCP beschrijft een gezamenlijke manier om hulpmiddelen en context aan ondersteunende AI-applicaties aan te bieden. Een MCP-server kan daarvoor bestaande API's gebruiken; hun rechten en inhoudelijke regels blijven nodig.
Heeft elke automatisering een AI-agent nodig?
Nee. Een vast gedefinieerde import of eenduidige berekening is vaak eenvoudiger uit te voeren met een script of directe API-koppeling. Een agent komt in aanmerking wanneer variabele taken werkelijk om een flexibele keuze van stappen vragen.
Mag een MCP-hulpmiddel zelf wijzigingen uitvoeren?
Wanneer dat inhoudelijk gewenst en technisch beveiligd is. Lezende functies, begrensde wijzigingen en kritieke acties worden apart behandeld. Goedkeuringen, doelrechten, invoercontrole en inzichtelijke resultaten horen bij de betreffende functie.
Volstaat aanmelding bij de AI-dienst als autorisatie?
Nee. De server moet de aanroeper en zijn bevoegdheden toetsen; het doelsysteem moet toegang tot de concrete functie en het concrete object eveneens toestaan. Een toolaanroep mag geen rechten creëren die de gebruiker anders niet heeft.
Hoe begint een zinvolle pilot?
Met een duidelijk nut en enkele begrensde hulpmiddelen, bij voorkeur eerst lezend. We leggen succescriteria vast en testen ongeoorloofde toegang, problematische inhoud, tijdsoverschrijdingen en herhaalde aanroepen voordat schrijvende functies worden uitgebreid.
Tooltoegang is nog geen toestemming voor inzet.
Een agent op een Linux-systeem kan API's, lokale hulpmiddelen of externe diensten gebruiken. Een eigen dienstidentiteit, begrensde bestandstoegang, procesisolatie, toegestane netwerkdoelen en veilig beheerde toegangsgegevens worden apart gepland. Een lokale agent is daarmee niet automatisch offline; elke externe aanroep hoort in de gegevensstroom. Modelwissels, toolfouten, looptijd, kostenlimieten en een inzichtelijke stoproute worden meegetest.
Laten we uw toepassing bespreken.
Wat moet eenvoudiger worden, welke gegevens zijn betrokken en welke systemen zijn al aanwezig? Daaruit ontwikkelen we een zinvolle start en overzichtelijke vervolgstap.