MCP-bridge AgentCore lokale MCP-værktøjer

Model Context Protocol (MCP) er blevet standardmåden at give AI-agenter adgang til værktøjer på. En MCP-server kan eksponere alt fra filsystemadgang til interne API-kald, og en agent taler med serveren over en fast forbindelse. Problemet opstår, når agenten kører et sted, og MCP-serveren kører et andet.

AgentCore-agenter hostes i AWS. De lokale MCP-servere, mange udviklere bruger dagligt, kører derimod på en bærbar bag NAT og en firewall, uden en offentlig IP-adresse og uden nogen indgående port åbnet. Den klassiske løsning har været en VPN-tunnel eller en reverse proxy med et åbent lyttende endpoint. Begge dele øger angrebsfladen markant og kræver, at nogen i IT-afdelingen vedligeholder en tunnel, ingen rigtig har lyst til at eje.

Løsningen vender relationen om. I stedet for at cloud-agenten forsøger at oprette forbindelse ind til din maskine, er det din maskine, der opretter en udgående forbindelse ud til en central bro-tjeneste. Broen fungerer som et omdrejningspunkt: AgentCore-agenten sender et MCP-kald til broen, broen videresender det til den lokale klient, som allerede har en åben, udgående forbindelse stående, og svaret sendes samme vej tilbage.

Det betyder, at ingen porte skal åbnes på din maskine, og der er ingen VPN at konfigurere. Din lokale klient initierer forbindelsen, ligesom din browser gør, når den besøger en hjemmeside. Fra et netværkssikkerhedsperspektiv er det den samme model, de fleste virksomheder allerede stoler på for al anden udgående trafik.

Transportlaget er en WebSocket-forbindelse, som den lokale klient etablerer udgående til broen. WebSocket er valgt, fordi det holder forbindelsen åben og lav-latency, hvilket passer godt til MCP's request-response-mønster, uden det polling-overhead, en almindelig HTTP-baseret løsning ville kræve.

Det, der gør løsningen sikkerhedsmæssigt forsvarlig, er ikke kun den udgående forbindelse, men hvordan beskederne autentificeres. Hver besked, der sendes gennem broen, er kryptografisk signeret, så broen selv aldrig kan læse eller manipulere indholdet af et MCP-kald, den bare videreformidler bytes mellem to parter, der har etableret tillid til hinanden på forhånd. Det er en vigtig detalje for enhver virksomhed, der overvejer at bygge noget lignende: broen skal designes som et blindt relæ, ikke som en tjeneste, der får indsigt i, hvad der rent faktisk sendes.

Det sidste stykke af puslespillet er, hvordan den lokale klient overhovedet taler med de MCP-servere, der kører på maskinen. Her har AgentCore-teamet brugt Chrome native messaging, en mekanisme, der oprindeligt er bygget til at lade en browserudvidelse kommunikere med et program installeret lokalt på maskinen.

Det er et pragmatisk valg. De fleste udviklere har allerede Chrome installeret, og native messaging-protokollen er velafprøvet, dokumenteret og understøttet på tværs af Windows, macOS og Linux. I stedet for at opfinde en ny lokal transportmekanisme, genbruger broen noget, browseren allerede løser sikkert: at lade en webkontekst tale med en lokal proces uden at give webkonteksten fri adgang til resten af maskinen. En lille lokal helper-proces modtager beskederne fra native messaging-laget og videresender dem til den relevante MCP-server, hvad enten det er en filsystem-server, en database-connector eller et internt værktøj.

For teams, der allerede har investeret i AgentCore som platform, løser en MCP-bro et konkret og tilbagevendende problem: hvordan man giver produktionsagenter adgang til data og værktøjer, der af gode grunde aldrig skal eksponeres direkte på internettet. Det gælder interne kodebaser, følsomme kundedatabaser og legacy-systemer, som mange danske virksomheder stadig kører på egne servere.