Olen nähnyt, miten Model Context Protocol (MCP) mahdollistaa uskomattomia agenttipohjaisia työnkulkuja, mutta kerron asiakkailleni aina yhden karun totuuden: teknisen arkkitehtuurin rakentaminen on helppo osa. Useimmat MCP-projektit kaatuvat kuiluun, joka on ”se toimii demossani täydellisesti” -tilanteen ja sen välillä, että yrityksen tietoturvatiimi hyväksyy sen tuotantokäyttöön.
Eficode
Eficode is the leading DevOps company in Europe, driving and building the future of software development across 10 countries, with 500+ experts in DevOps and sustainable software development. Our Eficode ROOT managed DevOps platform provides centralized access control and real-time visibility of project status, quality, and performance that integrates with 50+ of your preferred tools, including the Atlassian Stack and open-source systems like Jenkins and Kubernetes.
Jotta saat tekoälyagenttisi pois hiekkalaatikosta tuotantoon, tietoturva, hallintamallit ja yritysmaailman käytännön realiteetit on huomioitava suunnittelussa alusta asti. Tässä on käytännönläheinen opas tietoturvan näkökulmiin ja parhaisiin käytäntöihin, joita hyödynnän yritysten MCP-kehityksessä.
1. OAuth-tokenien hallinta tilattomissa arkkitehtuureissa
MCP-palvelin toimii demossa täydellisesti. Sitten konttisi autoskaalautuu yön aikana nollaan, ja kaikki hajoaa.
Ongelman ydin on OAuth-tokenien vanheneminen. Jos ”tilaton” arkkitehtuurisi kadottaa tokenin heti, kun kontti suljetaan, käyttäjän on tunnistauduttava uudelleen joka aamu ilman refresh tokeneita. Yrityksesi tietoturvatiimi ei hyväksy järjestelmää, jossa kitkaa on näin paljon.
Tässä on neljä ratkaisua toteutuksen työläyden mukaan järjestettynä:
Erillinen token-tallennus (vähän vaivaa): Tallenna refresh tokenit kontin ulkopuolelle secrets manageriin tai kevyeen pysyvään tallennuskerrokseen. Kun kontti käynnistyy, se hakee uuden tokenin automaattisesti.
Luku- ja kirjoitusoikeuksien erottaminen (kohtalaisesti vaivaa): Useimmat MCP-käyttötapaukset painottuvat vahvasti lukemiseen. Käytä pitkäkestoista service account -tokenia vain luku -toimintoihin ja edellytä käyttäjätason OAuth-tunnistautumista ainoastaan kirjoitustoiminnoissa.
Pidä kontti käynnissä (korkea kustannus, vähän vaivaa): Poista autoskaalaus nollaan käytöstä. Se on kallista, mutta voi olla oikea ratkaisu, jos tietoturvatiimisi estää tokenien pysyvän tallennuksen.
90 päivän uusimisikkuna (paras tasapaino): Määritä järjestelmä niin, että refresh token pysyy voimassa, jos käyttäjät käyttävät sitä vähintään kerran 90 päivän aikana. Kontti voi sammua joka yö, mutta tunnistautuminen säilyy niin kauan kuin käyttö on säännöllistä.
2. Datan käyttöoikeusrajat: hiekkalaatikkokuvio
Älä koskaan anna tekoälyagenttisi hakea omaa dataansa.
Jos agentilla on suora pääsy tuotantodatalähteisiin, se perii service accountinsa käyttöoikeudet. Useimmissa organisaatioissa service accounteilla on paljon laajemmat oikeudet kuin yhdelläkään yksittäisellä käyttäjällä pitäisi olla. Alkuvuodesta 2026 auditoin asiakkaan ympäristön, jossa ”vain luku” -tekoälyavustaja peri vanhan service accountin, jolla oli edelleen DROP TABLE -oikeudet kolmessa tuotantotietokannassa. Agentti ei ymmärrä IAM-rajoja tai datan luokittelua, vaan tekee mielellään kyselyjä kaikesta, mihin se pääsee käsiksi.
Tämä johtaa usein siihen, että agentti löytää arkaluonteista dataa ja tuo sitä esiin promptin vastauksessa. Estä tämä toteuttamalla hiekkalaatikkokuvio:
Erillinen prosessi hakee dataa asiakkaan todellisilla käyttöoikeuksilla, ei agentin oikeuksilla.
Data ladataan hiekkalaatikkoon rajattuun ympäristöön.
Agentti toimii ainoastaan tässä hiekkalaatikossa.
Agentti ei voi ohittaa IAM-sääntöjä, koska se ei koskaan koske lähdejärjestelmiin.
Kohtele tekoälyagenttiasi kuin hyväntahtoista mutta epäluotettavaa harjoittelijaa. Anna sille täsmälleen tarvitsemansa data käyttäjän käyttöoikeustasolla – ei enempää.
3. Käyttöoikeusmallit ja Human-in-the-Loop
Tiimit antavat agenteille usein laajat käyttöoikeudet, koska asianmukaisten käyttöoikeusrajojen rakentaminen vie aikaa. Tämä aiheuttaa kolme erilaista vikatilaa: dokumentoimattomien API-sopimusten rikkomisen, datan tuhoamisen häikäilemättömällä optimoinnilla ja ketjureaktiona syntyvät järjestelmähäiriöt.
Pienennä näitä riskejä noudattamalla seuraavia kolmea periaatetta:
Rajatut tokenit, ei tunnistetietoja
Jokaisen agentin tuotantoympäristöön kohdistuvan toiminnon on kuljettava tarkoitukseen rakennettujen APIen kautta ja käytettävä vain välttämättömiä käyttöoikeuksia. Agenteilla ei koskaan tulisi olla admin-avaimia, deployment-tunnistetietoja tai tuhoaviin toimiin kykeneviä tokeneita.
Pakolliset ihmisen hyväksynnät
Kaikki, mitä ei voi helposti perua, vaatii ihmisen hyväksynnän. Tietokantamuutokset, tuotantodeploymentit ja ulkoinen viestintä tarvitsevat todellisen tarkistuksen henkilöltä, jolla on tekoälyltä puuttuva liiketoimintakonteksti.
Dokumentoi rajoitteet koodiin
Tekoäly optimoi sille annetun tavoitteen mukaan sen perusteella, mitä kontekstia se pystyy lukemaan. Jos API-sopimus, riippuvuus tai liiketoimintasääntö on olemassa, sen on löydyttävä koodikannasta. Kommentit, konfiguraatiotiedostot ja arkkitehtuuripäätösten tallenteet ovat agentin nähtävillä. SharePointiin haudatut PDF-tiedostot eivät ole.
4. Tekoälytyönkulkujen operatiiviset suojakaiteet
Dynaamiset tekoälytyönkulut sopivat erinomaisesti prototypointiin, mutta tuotannossa ne tuovat mukanaan ennakoimattomuutta. Noudata näitä neljää operatiivista sääntöä:
Älä anna tekoälyn ohittaa tylsiä vaiheita: Tekoäly optimoi työn valmistumista ja ohittaa hitaita vaiheita, kuten koodin skannauksen tai tietoturvatarkastukset. Rakenna laatutarkistukset kiinteäksi osaksi pipelinea, jotta niitä ei voi ohittaa.
Älä koskaan anna kriittisiin järjestelmiin kirjoitusoikeuksia: Jos agentin on tehtävä vaarallinen toimenpide, sen on pyydettävä hyväksyntä human-in-the-loop-portin kautta rajattuja API-rajapintoja käyttäen.
Konteksti on rajallista: Tekoäly ei tiedä sitä, mitä se ei tiedä. Jokainen dokumentoimaton rajoite on aikapommi.
Standardoi dynaamiset työnkulut: Kun tekoäly löytää toimivan dynaamisen työnkulun, lukitse se. Muunna se deterministiseksi, toistettavaksi pipelineksi, aivan kuten neuvon tiimejä tekemään vakiintuneiden DevSecOps-käytäntöjemme kanssa.
5. Toimitusketjun tietoturva: slopsquatting-uhka
Tekoälypohjaiset koodausavustajat hallusinoivat usein pakettien nimiä. Hyökkääjät ovat havainneet tämän ja rekisteröivät näitä väärennettyjä nimiä julkisiin rekistereihin. Tätä kutsutaan nimellä "slopsquatting", ja se on hyvin ennakoitavaa, koska tekoälymallit hallusinoivat samoja väärennettyjä paketteja toistuvasti.
Hyökkäysketju etenee näin:
Tekoälyavustaja ehdottaa koodiesimerkissä pakettia, jota ei ole olemassa.
Hyökkääjä tunnistaa tämän yleisen hallusinaation ja rekisteröi haitallisen paketin npm:ään tai PyPI:hin, kuten Sonathen vuoden 2026 ohjelmistotoimitusketjun tilaa käsittelevässä raportissa dokumentoiduissa viimeaikaisissa toimitusketjuhyökkäyksissä on nähty.
Kehittäjä noudattaa tekoälyn ehdotusta ja asentaa paketin.
CI/CD-putki suorittaa haitallisen koodin täydellä pääsyllä build-ympäristöön.
Pienennä riskiä lukitsemalla riippuvuudet tiukasti hash-varmennuksella, auditoimalla kaikki tekoälyn ehdottamat paketit ennen asennusta ja käyttämällä CI/CD-putkissa sallittujen listoja, jotka hyväksyvät vain ennalta hyväksytyt kirjastot.
6. Tokenien ja käyttöoikeuksien hallinta
Olipa kyse GitHub-integraatioista tai MCP-palvelimista, ohjelmallinen pääsy edellyttää tiukkaa hallintaa. Jokainen yritys tarvitsee nämä neljä perustavanlaatuista dokumenttia välttääkseen loputtoman ongelmien sammuttelun:
PAT- ja SSH-käyttöohjeistus: Määritä käytettävä todennusmenetelmä, käyttöoikeuksien rajaukset ja vanhenemiskäytännöt.
Siirtymäpolku Appseihin: Kuvaa, miten siirrytään vanhoista Personal Access Tokeneista tarkasti rajattuihin Appseihin.
Poikkeamien hallintasuunnitelma: Kuvaa tarkat havaitsemis-, eskalointi- ja korjaustoimet vaarantuneita tokeneita tai salaisuuksia varten.
API-käyttöoikeuksien päätöspuu: Kartoita yksittäiset käyttötapaukset hyväksyttyihin käyttömenetelmiin ja niiden tietoturvakompromisseihin.
7. Kontekstin hallinta yritystasolla
Kontekstitiedostot, kuten AGENTS.md, toimivat erinomaisesti pienissä tiimeissä, joilla on yksi repositorio. Yritystasolla, jossa on satoja repositorioita, tämä lähestymistapa ei enää toimi.
Historiallinen tieto on wikeissä, toimialalogiikka ihmisten päässä ja arkkitehtuuripäätökset hajallaan. Et voi ylläpitää 200 hajautettua Markdown-tiedostoa, kun käytännöt muuttuvat ajan myötä. Repositoriokohtaiset kontekstitiedostot tarjoavat välitöntä arvoa, mutta organisaatiotason kontekstikerroksen on oltava keskitetty ja dynaamisesti haettavissa eri alustoilla.
8. Datan sijainti vs. datasuvereniteetti
Kun yritysarkkitehdit kysyvät MCP-käyttöönottojen "suvereenista tekoälystä", termit on selvennettävä ennen ratkaisun arkkitehtuurin suunnittelua.
Datan sijainti: Datasi säilyy tietyllä maantieteellisellä alueella pilvipalveluntarjoajan infrastruktuurissa. Tämä täyttää GDPR:n vaatimukset ja kattaa 95 % yritysten tarpeista.
Datasuvereniteetti: Hallitset koko teknistä kokonaisuutta. Mikään ulkomainen taho ei voi vaatia pääsyä tietoihin oikeuden päätöksellä.
Käytä tätä päätösmallia MCP-hostingin valintaan:
|
Tier |
Option |
When to Use |
|
1 |
SaaS |
Default choice. Fastest time to value. |
|
2 |
Cloud vendor |
When compliance explicitly requires data residency. |
|
3 |
True on-prem |
Strictly for defense, intelligence, or binding legal requirements. |
Taso
Vaihtoehto
Milloin käytetään
1
SaaS
Oletusvalinta. Nopein tapa saada arvoa.
2
Pilvipalveluntarjoaja
Kun vaatimustenmukaisuus edellyttää nimenomaisesti datan sijaintia tietyllä alueella.
3
Aidosti on-premises
Vain puolustuksen, tiedustelun tai sitovien lakisääteisten vaatimusten tarpeisiin.
Jos et pysty osoittamaan tiettyä lakia tai sopimuskohtaa, joka edellyttää tasoa 3, olet todennäköisesti rakentamassa tarpeettoman monimutkaista ratkaisua.
Yhteenveto: MCP:n tietoturvan tarkistuslista
MCP-projektin vieminen tuotantoon tarkoittaa tietoturvatarkastuksesta selviytymistä. Käytä tätä tarkistuslistaa lähtökohtanasi:
|
Focus area |
Core Best Practice |
|
Authentication |
Separate token storage; plan for expiry; split read/write access. |
|
Data access |
Use the sandbox pattern; fetch data with user privileges outside the agent. |
|
Permissions |
Issue scoped tokens only; mandate human-in-the-loop for write actions. |
|
Workflows |
Hard-code security scans; freeze dynamic AI paths into standard pipelines. |
|
Supply chain |
Verify hashes; audit AI package suggestions; enforce CI/CD allowlists. |
|
Governance |
Define PAT policies, incident response plans, and API decision trees. |
|
Context |
Document constraints in code; centralize organizational knowledge. |
|
Hosting |
Default to SaaS; escalate to sovereign only when legally required. |
Painopistealue
Keskeinen paras käytäntö
Todennus
Säilytä tokenit erillään; varaudu niiden vanhenemiseen; erottele luku- ja kirjoitusoikeudet.
Datankäyttöoikeudet
Käytä sandbox-mallia; hae data käyttäjän oikeuksilla agentin ulkopuolella.
Käyttöoikeudet
Myönnä vain rajatun käyttöalueen tokeneita; edellytä ihmisen hyväksyntää kirjoitustoimille.
Työnkulut
Määritä tietoturvaskannaukset kiinteästi; lukitse dynaamiset tekoälypolut osaksi vakioputkia.
Toimitusketju
Varmista hash-arvot; auditoi tekoälyn ehdottamat paketit; ota käyttöön CI/CD-sallintalistat.
Hallintamalli
Määritä PAT-käytännöt, häiriötilanteiden toimintasuunnitelmat ja API-päätöspuut.
Konteksti
Dokumentoi rajoitteet koodissa; keskitä organisaation tieto.
Hosting
Käytä ensisijaisesti SaaS-ratkaisua; siirry suvereeniin ratkaisuun vain, kun laki sitä edellyttää.
Subscribe to our newsletter
Related blogs
