Udvikling af MCP-servere.
Forbind systemer målrettet.
AI skal kunne mere end at svare: den skal arbejde målrettet med eksisterende systemer. DAXS udvikler passende MCP-servere og adaptere med tydelige værktøjer, begrænsede rettigheder og resultater, der kan kontrolleres.
En MCP-server gør definerede funktioner tilgængelige for AI-applikationer.
En assistent skal kunne hente en ticketstatus, søge i godkendt dokumentation eller oprette et forberedt element. Det kræver en tydeligt beskrevet, begrænset adgang. DAXS udvikler passende MCP-servere og de bagvedliggende API-forbindelser til eksisterende virksomhedssystemer.
Protokollen Model Context Protocol beskriver blandt andet, hvordan AI-applikationer kan bruge værktøjer, dataressourcer og forberedte prompts. En MCP-server er en teknisk adapter. Et godt værktøjsnavn gør den hverken sikker eller til en selvstændigt arbejdende agent.
Klassisk API
En applikation kalder en defineret funktion i et andet system. Datamodel, rettigheder, validering og fejlhåndtering planlægges for denne adgang.
MCP-integration
En kompatibel AI-klient kan bruge beskrevne funktioner og ressourcer gennem en fælles protokol. Den konkrete godkendelse og implementeringen i målsystemet er fortsat særskilte opgaver.
AI-agent
En applikation kombinerer model, tilstand og værktøjer til flere trin. Det kræver en afgrænset opgave, stopbetingelser og sporbar kontrol med handlingerne. En agent kan bruge MCP eller andre API'er.
Klient, grænseflade og målsystem kontrollerer hvert deres område.
AI-applikationen foreslår et værktøjskald. MCP-serveren kontrollerer identitet, tilladt funktion og input. Målsystemet håndhæver desuden sine egne adgangsregler. Ved kritiske handlinger kontrolleres en konkret godkendelse før udførelsen.
Tegningen viser en eksempelarkitektur for en individuel integration. Hvilke klient-, SDK- og protokolversioner der fungerer sammen, fastlægges og testes før gennemførelsen.
Opgaven bestemmer data og handlinger.
En grænseflade til ticketsystemet behøver ikke give adgang til hele databasen. Et værktøj kan eksempelvis levere præcis de felter, der er nødvendige for en tilladt statusforespørgsel. Et andet opretter udelukkende et udkast. Generelle shell-, SQL- eller administrationsfunktioner ville give unødvendigt vide rammer.
| Type | Muligt værktøj | Vigtig kontrol |
|---|---|---|
| Læsning | Hent ticketstatus, søg i godkendt dokumentation, eller forespørg om teknisk tilstand. | Brugeren må se det konkrete objekt; lever kun nødvendige felter, en begrænset resultatmængde og ingen data fra andre tenants. |
| Begrænset skrivning | Forbered et svarudkast eller en struktureret intern note. | Kontroller felter og tilladt indhold, marker udkast tydeligt, håndter gentagelser, og returner et sporbart resultat. |
| Kritisk | Igangsæt en aftalt ændring i et produktionssystem. | Yderligere godkendelse knyttet til handling og målobjekt; kontroller rettigheden igen umiddelbart før udførelse, og fastlæg grænser og tilbagerulningsmulighed. |
Også et læseværktøj kan afsløre fortrolige data. Læseadgang erstatter derfor ikke autorisation. Ved skrivekald planlægger vi desuden idempotens, fejltilstande og håndtering af uklare resultater: en timeout beviser ikke, at handlingen ikke blev udført.
Et vellykket login giver ikke adgang til alle objekter.
Vi skelner mellem login i AI-klienten, autorisation på MCP-serveren og rettigheder i målapplikationen. Bruger-, gruppe- og tenantkontekst kommer fra en betroet identitet. Modellen må ikke selv fastlægge sin rolle eller det tilladte dataområde gennem tekstinput.
En fjernbaseret HTTP-integration kræver et egnet autorisationskoncept. Tokens skal være udstedt til den tilsigtede tjeneste og kontrolleres for gyldighed og omfang. Adgangsoplysninger til efterfølgende systemer beskyttes og begrænses efter det enkelte mål. Et vilkårligt videresendt klienttoken er ikke en universel systemadgang.
En lokal procesforbindelse har andre grænser end en fjernbaseret virksomhedstjeneste: eksempelvis det startede program, dets oprindelse og operativsystemrettigheder. Enkel lokal udførelse erstatter ikke kontrol af programmet eller dets dataadgang. For begge varianter aftaler vi tilladte forbindelser og teknisk ansvar.
MCP er en protokol, ikke en fuldstændig sikkerhedsarkitektur.
Den faktiske afgrænsning håndhæves gennem serverlogik, rettigheder i målsystemet, beskyttede adgangsoplysninger, netværksregler og kontrollerbare godkendelser. Den passende implementering afhænger af klient, data, handlinger og driftsmodel.
Grænserne gælder også ved uhensigtsmæssige modelforslag.
Et dokument, en tickettekst eller et værktøjsresultat kan indeholde manipulerede instruktioner. Sådant indhold behandles som data. Det må hverken tildele nye rettigheder eller retfærdiggøre en ellers blokeret handling. Instruktioner i prompten kan understøtte applikationen; den bindende kontrol ligger uden for modellen.
Input og mål
Valider typer, tilladte værdier, objektrelationer, stier og resultatmængder på serveren. Begræns tilladte API'er og netværksmål; ingen frit sammensatte kommandoer eller ukontrollerede adressekald.
Handlinger og godkendelser
Vis kaldets omfang og sideeffekter forståeligt. Knyt kritiske godkendelser til den konkrete operation, begræns dem i tid, og efterprøv dem før udførelse. Fastlæg regler for stop og gentagelse.
Drift og sporbarhed
Planlæg rate limits, tidsgrænser, fejlhåndtering og formålsbestemte logfiler. Adgangsoplysninger må ikke indgå i modelkontekst eller diagnoseoutput. Sørg for at kunne undersøge mistænkelig adgang og tilbagekalde adgange.
Vi tester både normale forløb og forbudt objektadgang, manipuleret indhold, udløbne rettigheder, dobbelte kald og afvist godkendelse. Det reducerer risici; et generelt løfte om sikkert at forhindre enhver prompt injection ville ikke være seriøst.
Begynd med en overskuelig funktion.
Vi kortlægger målapplikation, eksisterende API'er, brugerroller og nødvendige felter. Det giver et afgrænset værktøjskatalog med tydelige input og resultater. Et læsende pilotprojekt kan vise, om integrationen gavner hverdagen; skrivetrin tilføjes og testes særskilt efter behov.
- Afgræns opgaven: hvilket problem, hvilke objekter og hvilke brugere?
- Udvikl grænsefladen: tilslut mål-API, beskriv værktøjet, og implementer rettigheder og fejlhåndtering.
- Godkend i praksis: test tilladte og forbudte tilfælde, godkendelser og gentagelser.
- Overdrag med løbende support: dokumenter adgangsadministration, versionsvedligeholdelse og ansvar.
DAXS kan varetage arbejdet som individuel udvikling og integration. En ren dataforespørgsel kan også løses fornuftigt med en klassisk API eller et script. Vi drøfter det passende omfang ud fra jeres eksisterende systemer.
En konkret ønsket funktion, den berørte applikation, eksisterende API-dokumentation og et anonymiseret eksempel. Adgangsoplysninger og fortrolige kundedata hører ikke hjemme i en offentlig forespørgsel.
Det afklarer vi i samtalen.
Hvad er forskellen på en API og MCP?
En API stiller funktioner fra et system til rådighed. MCP beskriver en fælles måde at tilbyde værktøjer og kontekst til understøttende AI-applikationer på. En MCP-server kan bruge eksisterende API'er; deres rettigheder og faglige regler er fortsat nødvendige.
Kræver enhver automatisering en AI-agent?
Nej. En fast defineret import eller en entydig beregning er ofte enklere at implementere med et script eller en direkte API-forbindelse. En agent kan komme på tale, når variable opgaver faktisk kræver fleksibelt valg af trin.
Må et MCP-værktøj selv foretage ændringer?
Hvis det er fagligt ønsket og teknisk sikret. Læsefunktioner, begrænsede ændringer og kritiske handlinger behandles hver for sig. Godkendelser, målrettigheder, inputkontrol og sporbare resultater hører med til den enkelte funktion.
Er login i AI-tjenesten tilstrækkeligt som rettighed?
Nej. Serveren skal kontrollere den kaldende part og dennes beføjelser; målsystemet skal også tillade adgang til den konkrete funktion og det konkrete objekt. Et værktøjskald må ikke skabe rettigheder, som brugeren ellers ikke har.
Hvordan begynder et meningsfuldt pilotprojekt?
Med en tydelig nytte og få, afgrænsede værktøjer, helst med læseadgang i begyndelsen. Vi fastlægger succeskriterier og tester ulovlig adgang, problematisk indhold, tidsoverskridelser og gentagne kald, før skrivefunktioner udbygges.
Værktøjsadgang er endnu ikke en tilladelse til drift.
En agent på et Linux-system kan bruge API'er, lokale værktøjer eller eksterne tjenester. Egen tjenesteidentitet, begrænset filadgang, procesisolering, tilladte netværksmål og sikkert administrerede adgangsoplysninger planlægges hver for sig. En lokal agent er dermed ikke automatisk offline; hvert eksternt kald hører med i dataforløbet. Modelskift, værktøjsfejl, runtime- og omkostningsgrænser samt et sporbart stopforløb testes også.
Læs mere om rettigheder og godkendelser for agenter
Script, workflow eller AI-agent: konkrete beslutningsspørgsmål
Lad os tale om jeres anvendelse.
Hvad skal blive lettere, hvilke data indgår, og hvilke systemer findes allerede? Ud fra det udvikler vi en meningsfuld indgang og et overskueligt næste skridt.