GitLab 19.5: MCP-palvelimen työkalut voi rajata

GitLabin 19.5-julkaisu toi GitLab MCP serverin yleiseen saatavuuteen 15. lokakuuta 2026 Free-, Premium- ja Ultimate-tasoilla. MCP-yhteensopiva ulkoinen koodausagentti voi sen kautta käyttää GitLabin toimintoja, ja asiakkaalle näkyviä työkaluryhmiä voi valita. Palvelin on tarjolla GitLab.comissa, itse ylläpidetyissä asennuksissa ja GitLab Dedicatedissa.

Samassa versiossa GitLab Secrets Manager tuli yleiseen saatavuuteen Premium- ja Ultimate-tasoilla, mutta ulkoisten agenttien AI Governance -auditointi on vielä beetassa. Kehittäjälle muutos avaa lisää GitLab-toimintoja tutussa asiakasohjelmassa. Ylläpitäjälle olennaista on erottaa toisistaan asiakkaalle palautuva työkaluluettelo, käyttäjän GitLab-oikeudet ja erikseen käyttöönotettava istuntojen tallennus.

Työkaluryhmä valitaan MCP-yhteydessä

GitLab MCP server palauttaa oletusarvoisesti muun muassa perustoimintojen, yhdistämispyyntöjen, työtehtävien, koodivaraston ja CI/CD:n työkalut. Wikiin ja koodin tietoturvaan liittyvät ryhmät vaativat erillisen valinnan. GitLab Duo Agent Platformin työkalut tulevat oletusluetteloon vain silloin, kun kyseinen alusta on käyttäjän saatavilla; pelkkä Free-tason MCP-yhteys ei avaa maksullisia Duo-toimintoja.

Asiakas voi pyytää vain tarvitsemansa ryhmät HTTP-otsakkeella X-Gitlab-Enabled-Mcp-Server-Toolsets. Jos esimerkiksi asiakas tarvitsee työtehtäviä mutta ei CI/CD-toimintoja, sen palautuvaa luetteloa voi supistaa yhteysasetuksessa. Rajaus helpottaa agentin työkalunvalintaa ja säästää sen käyttämää kontekstia. Se ei kuitenkaan muuta käyttäjän oikeuksia projekteihin: listalle päätyväkin työkalu tarkistaa pääsyn, kun sitä kutsutaan.

Version 19.5 laajennettu luettelo on myös aiempaa täsmällisempi. get_artifact_file hakee yksittäisen tiedoston CI/CD-työn artefakteista ilman koko arkiston lataamista, ja list_groups auttaa löytämään ryhmiä sekä aliryhmiä. Yhdistämispyyntöjen ja putkien tietoja on koottu työkaluihin, joista agentti voi pyytää tehtävän tarvitsemat yksityiskohdat. Näin agentin ei tarvitse aina tehdä erillisiä hakuja saman kohteen eri osista.

Näkyvä työkalu ja pakotettu käyttökielto ovat eri asioita

Työkaluryhmien valinta tapahtuu ulkoisen asiakkaan MCP-yhteydessä. Sen avulla määritetään, mitä palvelin luettelee juuri kyseiselle asiakkaalle, mutta asiakkaan asetusta ei pidä käsitellä koko organisaation pakotettuna käyttöpolitiikkana. GitLab Duo Agent Platformin työkaluhallinnan säännöt koskevat Duo-agenttien tekemiä kutsuja; version 19.5 suoraan MCP-palvelimeen liittyvä kolmannen osapuolen asiakas ei kuulu saman työkalukohtaisen kiellon piiriin.

Yhteyden valtuutus perustuu käyttäjän GitLab-tunnukseen. Siksi ryhmän tai projektin oikeudet rajaavat, mitä ulkoinen agentti voi tosiasiassa lukea tai muuttaa, vaikka työkalu näkyisi sen luettelossa. Ylläpitäjän kannalta tässä on kaksi hallintapäätöstä: sallitaanko MCP-yhteys kyseiselle käyttäjäjoukolle ja millä oikeuksilla he toimivat GitLabissa. Asiakkaan työkaluryhmät määrittävät erikseen, millainen toiminnallinen valikoima agentille annetaan.

MCP-asiakkaasta voidaan lisäksi käynnistää GitLab Duo Agent Platformin agentteja ja työnkulkuja, jos käyttäjällä on niiden käyttöoikeus ja ne on otettu käyttöön. Tässä tapauksessa ulkoinen asiakas toimii työn käynnistäjänä, mutta itse Duo-työnkulku suoritetaan GitLabin puolella. Ero vaikuttaa siihen, mistä toiminnan hallintasäännöt ja auditointijälki syntyvät.

Auditointibeta tallentaa kehotteita ja työkalukutsuja

Ulkoisten agenttien liittäminen AI Governanceen on Premium- ja Ultimate-tasojen beetaominaisuus GitLab.comissa, itse ylläpidetyissä asennuksissa ja GitLab Dedicatedissa. Se koskee esimerkiksi Claude Codea, Cursoria ja Codexia, jotka toimivat GitLabin ulkopuolella. GitLab CLI:n glab govern setup ottaa istuntojen keruun käyttöön käyttäjän koneella, kun projektin ja ryhmän edellytykset täyttyvät.

GitLabin agenttiauditoinnin ohjeessa kerrotaan, että Allow external agents on oletusarvoisesti käytössä, mutta työkalutapahtumien tallennukseen tarvittava Store AI audit events on oletusarvoisesti pois käytöstä. Ilman jälkimmäistä istunto voi näkyä, mutta sen tapahtumat ja työkalukutsut eivät tallennu. Käyttäjällä on oltava vähintään Developer-rooli projektissa, ja paikallinen keruu on dokumentoitu macOS:lle ja Linuxille.

Kun tallennus on käytössä, istuntoon liittyvät käyttäjä, agentti, projekti ja ajankohta sekä työkalukutsujen aikajana. GitLab CLI lähettää myös käyttäjän kehotteet ja työkalukutsujen argumentit, kuten komennot, tiedostopolut ja muokkaukset. Lisäksi se välittää kutsun tuloksen tilan, keston ja virheilmoituksen sekä mallin ja tokenien käytön, jos agentin istuntotiedot sisältävät nämä tiedot. Tämä on huomattavasti laajempi tietosisältö kuin pelkkä merkintä siitä, että agentti oli käynnissä.

Työkalujen varsinaista tulostetta ja agentin vastaustekstiä ei lähetetä; epäonnistuneen työkalukutsun tulosteesta voidaan lähettää enintään 255 ensimmäistä merkkiä virheilmoituksena. Keruun tarkkuus vaihtelee agentin mukaan: Cursorin istunnoista lähetetään vain kehotteet ja työkalukutsut, ja Codexin kutsujen tulokset merkitään valmistuneiksi, koska niiden onnistumistietoa ei tallennu samalla tavalla. Raportissa näkyvät istunnot ja kutsut voidaan välittää myös organisaation SIEM-järjestelmään auditointitapahtumien suoratoistolla.

Secrets Managerin saatavuus ja loki muodostavat oman kokonaisuutensa

GitLab Secrets Managerin yleinen saatavuus koskee GitLab.comia ja itse ylläpidettyjä asennuksia Premium- ja Ultimate-tasoilla. Se on erillinen lisäosa, jonka käyttö kuluttaa GitLab Credits -krediittejä. GitLab Dedicated ei kuulu tämän julkaisun ilmoittamiin saatavuusympäristöihin, vaikka MCP-palvelin ja ulkoisten agenttien auditointibeta ovat siellä tarjolla.

OpenBaoon perustuva palvelu käyttää GitLabin nykyisiä ryhmä- ja projektioikeuksia. CI/CD-salaisuuden käyttö voidaan rajata sitä tarvitsevaan työhön ympäristön, haaran ja suojatun haaran sääntöjen mukaan. Salaisuuden luonnista, lukemisesta, muuttamisesta ja poistamisesta syntyy auditointimerkintä. Tämä loki kertoo salaisuuden käsittelystä, kun taas ulkoisen agentin auditointi kuvaa istuntoa ja sen työkalukutsuja.

Jos Store AI audit events otetaan käyttöön vasta myöhemmin, sitä edeltävien istuntojen työkalutapahtumat eivät ilmesty raporttiin jälkikäteen. Käyttöönottopäivä määrää siten, mistä alkaen ulkoisen agentin kutsuista syntyy tutkittava aikajana.

Lue myös: