OpenAI åpner tunnel fra ChatGPT til interne systemer

OpenAI har sluppet en funksjon som flytter en grunnleggende grense i hvordan selskaper kobler skybaserte AI-modeller til sine egne systemer. Secure MCP Tunnel lar ChatGPT, Codex og Responses API nå private MCP-servere som står innenfor bedriftens eget nettverk – uten at IT-avdelingen må åpne en eneste innkommende port i brannmuren.

Modellen er enkel og bevisst kjedelig. En liten programvarekomponent, en tunnel-client, kjøres på en maskin inne i nettverket som allerede når MCP-serveren. Den åpner en utgående HTTPS-forbindelse mot OpenAI, henter kø av oppgaver, sender forespørslene videre lokalt og leverer svarene tilbake gjennom samme tunnel. All trafikk går utover, til api.openai.com:443 eller mtls.api.openai.com:443 ved gjensidig TLS. Ingenting trenger å lytte mot internett.

Hvorfor dette er mer enn en teknisk detalj

MCP, Model Context Protocol, er i ferd med å bli standarden for hvordan AI-agenter kobles til verktøy og data: lagerstatus, ordrehistorikk, interne API-er, kunnskapsbaser, saksbehandlingssystemer. Problemet har vært tilgang. Skal en agent i ChatGPT kunne spørre mot et internt system, har alternativene vært å eksponere systemet mot internett, bygge en omvei via en proxy, eller la være. De fleste seriøse virksomheter har latt være.

Secure MCP Tunnel fjerner den unnskyldningen. Nå kan en agent hos OpenAI nå rett inn i et internt system gjennom en kanal sikkerhetsteamet teknisk sett kan forsvare: utgående, kryptert, uten åpne porter. For mange CIO-er senker det terskelen fra «umulig å få godkjent» til «en konfigurasjonsjobb».

Markedssignalet er tydelig

Dette er ikke en kosmetisk connector. OpenAI gjør det mulig å ta agentene fra demonstrasjon til drift uten å bygge et nytt offentlig API-lag foran hvert internt system. Det treffer et reelt hinder i mange virksomheter: utviklere og forretningssiden vil ha agenter som kan gjøre arbeid, mens sikkerhetsteamet ikke vil åpne interne tjenester mot internett for å få det til.

Tunnelen flytter kompromisset. Bedriften slipper offentlig eksponering av MCP-serveren, men aksepterer en kontrollert kanal der eksterne OpenAI-flater kan sende MCP-kall inn i miljøet. Det er en bedre modell enn tilfeldige proxyer, utviklermaskiner og halvprivate integrasjoner. Men den er ikke risikofri. Den gjør bare risikoen mer eksplisitt.

For CIO-en er dette et tegn på hvor enterprise-AI faktisk går. Verdien ligger ikke lenger bare i modellen, men i hvor trygt modellen kan handle mot systemene som styrer lager, ordre, saksflyt, økonomi og kundedata. Leverandøren som får den integrasjonen godkjent først, får også en sterkere posisjon i virksomhetens operative kjerne.

Det CISO-en faktisk må vurdere

Formuleringen «ingen innkommende porter» er teknisk korrekt og samtidig egnet til å roe feil instinkt. Den reelle endringen er ikke porten, men rekkevidden. Du etablerer en stående utgående kanal som en ekstern leverandørs agent bruker til å stille spørringer mot interne systemer. Trusselmodellen flytter seg fra «hvem kommer inn» til «hva kan agenten gjøre når den først er koblet på, og hvem styrer det».

Konkret bør et styre og en sikkerhetsledelse ha svar på:

• Autorisasjon og scope. Hvem oppretter tunnelen, og hvilke MCP-verktøy eksponeres? Hos OpenAI styres dette med tunnel-ID og API-nøkler med egne Tunnels-rettigheter. Det er nyttig, men bare hvis rettighetsstyringen faktisk forvaltes som privilegert tilgang, ikke som en utviklernøkkel som lever i evig tid.
• Logging og sporbarhet. Hver spørring agenten gjør mot et internt system må kunne revideres. Uten full logg på tunnelnivå mister du innsyn i hva som faktisk ble hentet ut – og av hvilken agent, på hvilket grunnlag.
• Datalokasjon og taushetsplikt. Selv om systemet blir stående internt, forlater svarene perimeteren i det øyeblikket de går gjennom tunnelen til leverandørens modell. For sektorer med taushetsplikt eller datalokaliseringskrav er det her vurderingen ligger, ikke i brannmurkonfigurasjonen.
• Nødbrems. Kan tunnelen kuttes umiddelbart, og vet dere hvem som har den knappen? En stående kobling til en ekstern part bør ha en testet av-bryter.
• Leverandørbinding. Jo dypere agentene veves inn i interne systemer via én leverandørs tunnel, desto dyrere blir det å bytte. MCP er en åpen protokoll, men tunnel-mekanikken og rettighetsmodellen er leverandørspesifikk.

Hva det betyr de neste månedene

For norske virksomheter betyr dette at presset for å koble AI-agenter direkte på interne systemer kommer til å øke – ikke fordi teknologien er ny, men fordi den tekniske unnskyldningen forsvinner. Forretningssiden vil peke på at «sikkerheten er løst, det er bare utgående trafikk». Det stemmer på portnivå og er utilstrekkelig som beslutningsgrunnlag.

Rådet er nøkternt: behandl en MCP-tunnel som en privilegert integrasjon mellom et internt system og en ekstern part, ikke som en brannmurinnstilling. Krev scope, logging, datalokasjonsvurdering og en testet nødbrems før første tunnel settes opp. Da blir dette en kontrollert kapabilitet i stedet for en stille utvidelse av angrepsflaten som ingen i styret har sagt ja til.

Kilder og medier

• Primærkilde: OpenAI, «Secure MCP Tunnel» – source_url: https://developers.openai.com/api/docs/guides/secure-mcp-tunnels (kreditering: OpenAI)
• Thumbnail: OpenAI Image 2 / hogby.ai