Oppdatert 22. august 2026: Microsoft har gjort fleire viktige avklaringar rundt MCP, DLP og connectors i Copilot Studio. Eg har oppdatert posten med kva dette faktisk betyr for styring og risiko i praksis.
«Agenten følgjer alle våre policyar.»
Det er ofte sant heilt til agenten får tilgang til ein MCP-server.
Copilot Studio har gjort det enkelt å kople agentar mot ekstern data. Det er kraftig. Det er òg ei governance-flate som fort blir vanskeleg å styre i praksis.
Utfordringa er at ein agent ser ut som ein vanleg Copilot-prompt for sluttbrukaren. Teknisk fungerer han annleis. Microsoft dokumenterer no fleire separate tilkoplings- og registreringsvegar for MCP som du må halde frå kvarandre, ikkje éin samla governance-flyt:
- onboarding-wizard for eksisterande MCP-serverar i Copilot Studio
- connector-baserte MCP-oppsett, inkludert custom connectors som styringsflate for fleire dokumenterte scenario
- registrering via Agents 365
- registrering via Microsoft 365 Admin Center
I nokre av desse dokumenterte scenaria går tilkopling og styring gjennom Power Platform/custom connectors, mellom anna ved tilkopling til eksisterande MCP-serverar i Copilot Studio og i enterprise-scenariet for Microsoft MCP Server for Enterprise. Det er altså ikkje berre eit Power Apps-spor, men ein viktig governance-flate for dei MCP-scenaria der connectoren og autentiseringsmodellen faktisk er del av oppsettet.
Det viktigaste å forstå: I dei dokumenterte MCP-scenaria der Microsoft brukar Power Platform connectors for tilkopling, er connectoren eit sentralt transport- og styringspunkt. Det betyr at data policyar for agentar blir handheva i sanntid i Copilot Studio, og at blokkering av Power Platform connectors også kan blokkere MCP-tools som er avhengige av desse i dei dokumenterte scenaria.
DLP er likevel berre éin del av styringa. Når ein MCP-server tilbyr fleire verktøy, kan du også avgrense kva av desse agenten får tilgang til. Det er ikkje DLP. Enkelt sagt: DLP styrer om vegen er lov. Tool-utvalet styrer kva agenten får gjere når vegen først er open.
Tre konkrete grep som hjelper i dag:
🔹 Vurder korleis connectorane som gir MCP-tilgang er plasserte i DLP-policyen din i dei dokumenterte scenaria der MCP-tilkoplinga går via Power Platform connectors. Som med custom connectors bør dei plasserast på «Business», «Non-business» eller «Blocked»-sida. I Microsoft sitt dokumenterte scenario for Microsoft MCP Server for Enterprise gjeld dette eit oppsett med Power Platform environment, custom connector, app registration med MCP-relaterte API permissions, rolla Cloud Application Administrator og relevante directory roles. Microsoft rår her til Developer- eller Sandbox-miljø dersom tenant-level DLP blokkerer custom connectors.
🔹 Lag eit eige miljø for agentar med eksterne connectors. Ikkje del det med standard Copilot Studio-arbeidsflytar. Det gjev deg eit tydeleg konsekvensomfang dersom noko går gale, og gjer det enklare å innføre strengare connector-policyar der det faktisk trengst.
🔹 Ver medviten om tool-utvalet når du koplar til ein MCP-server, men ikkje forveksl dette med ein eigen DLP-mekanisme per tool. Data policyar blir handheva i sanntid via connector-policy i dei dokumenterte scenaria som brukar Power Platform connectors, medan kva tools som er tilgjengelege for agenten, må vurderast og avgrensast i agentoppsettet.
Microsoft har blitt tydelegare på kvar governance faktisk skjer. Utfordringa oppstår når agenten kryssar denne grensa og byrjar å arbeide mot eksterne system gjennom MCP-serverar og connectorar. Det er ofte her den reelle governance-utfordringa startar.
Ein agent som kallar ein tredjeparts-MCP-server bør ha ein tydeleg eskaleringsmodell. Hovudregelen min er enkel: Lesetilgang fyrst. Skrivetilgang berre etter ein dokumentert testperiode med menneskeleg gjennomgang av alle handlingane agenten har utført.
Kven i organisasjonen din eig risikoen når ein Copilot Studio-agent kallar ein tredjeparts-MCP-server – sikkerheit, plattformteam eller forretningseigaren?
Tillegg: Det vi no veit sikkert om DLP, transport og sertifisering
Det nye her er ikkje at governance er vanskeleg. Det visste vi. Det nye er at Microsoft no er langt tydelegare på kvar styringa faktisk skjer.
For det første: Microsoft skriv no eksplisitt at data policyar for agentar blir handheva i sanntid i Copilot Studio, og at blokkering av Power Platform connectors òg blokkerer MCP-tools som er avhengige av desse connectorane i dei dokumenterte scenaria der MCP-tilkoplinga går via slike connectors. Det styrkjer hovudpoenget over: Dersom connector-styringa di er slapp i desse scenaria, har du eit reelt governance-problem.
Kva agenten faktisk får tilgang til, blir derimot også påverka av agentoppsettet. Det er ein annan mekanisme enn DLP, sjølv om dei to verkar saman i praksis.
For det andre: Microsoft dokumenterer no at Copilot Studio sitt MCP-scenario støttar Streamable transport, og at SSE ikkje lenger er støtta der etter august 2025. Det er først og fremst eit teknisk faktum for Copilot Studio sitt MCP-scenario, men det har ein governance-konsekvens òg: eldre oppskrifter og demoar kan gi eit feil bilete av kva som faktisk er støtta i produksjon no.
For det tredje: Microsoft har ei oversiktsside for MCP-sertifisering som er merka preview. Ho er nyttig for retning, overgangsinformasjon og overordna rammer, men preview-statusen gjeld denne oversikta og bør ikkje åleine brukast som styringsgrunnlag for produksjon.
For det fjerde: Den operative sertifiseringsdokumentasjonen skildrar det dokumenterte innsendingløpet der MCP-serverar blir pakka og sende inn som ein Power Platform connector. Nye innsendingar går via Apps and Agents for M365 and Copilot i Partner Center. Det er dette operative løpet du bør sjå på når du vurderer governance, publisering og leverandørrisiko.
For governance er poenget uansett det same: «sertifisert» betyr ikkje at Microsoft har teke over risikoen din. Sertifisering kan vere eit nyttig minimumssignal, men det endrar ikkje ansvaret ditt for identitet, datatilgang, logging, avgrensing av tools og miljøstyring.
Praktisk konsekvens: Ikkje avgrens governance til Copilot Studio-grensesnittet
Den kanskje viktigaste praktiske utviklinga er at governance ikkje kan avgrensast til sjølve Copilot Studio-grensesnittet. Microsoft dokumenterer fleire separate tilkoplings- og registreringsvegar du må ta omsyn til, mellom anna onboarding av eksisterande MCP-serverar i Copilot Studio, connector-baserte oppsett, registrering via Agents 365 og registrering via Microsoft 365 Admin Center. Dette er ikkje dokumentert som éin felles governance-flyt, men som fleire inngangsvegar du må ha oversikt over.
I det dokumenterte enterprise-scenariet for Microsoft MCP Server for Enterprise føreset Microsoft mellom anna Power Platform environment, custom connector, relevante directory roles, app registration med MCP-relaterte API permissions og rolla Cloud Application Administrator. I dette konkrete scenariet er oppsettet dessutan read-only, og Microsoft rår eksplisitt til Developer- eller Sandbox-miljø dersom tenant-level DLP blokkerer custom connectors.
Det betyr i praksis at plattformteamet må følgje med på meir enn «kva agentar finst». Dei må òg ha kontroll på kvar connectorane blir oppretta, i kva miljø dei ligg, kvar MCP-serverar blir registrerte, og kva autentiseringsmønster dei brukar.
Kvifor dette gjer den gamle hovudregelen endå viktigare
Den nye dokumentasjonen gjer meg ikkje meir avslappa. Ho gjer meg meir sikker på at hovudregelen bør vere streng:
- les før skriv
- eige miljø før delt miljø
- connector-styring før agentdesign
- sertifisering som signal, ikkje som frikort
Det er særleg verd å merke seg at Microsoft sitt dokumenterte Microsoft MCP Server for Enterprise-scenario i Copilot Studio er read-only. Det gjeld dette konkrete enterprise-scenarioet, ikkje MCP generelt, men det er likevel eit godt ankepunkt for norske verksemder som treng ein konservativ startmodell.
Heilt ærleg?
Denne oppdateringa peikar i same retning som før, ikkje i ei ny.
Microsoft har gjort MCP lettare å ta i bruk, men ikkje enklare å eige risikoen for. Ny dokumentasjon gjer det berre tydelegare at custom connectors, miljøgrenser og DLP-policyar er der governance faktisk lever eller døyr.
Så det enkle spørsmålet står framleis att:
Har de eigentleg kontroll på agenten – eller berre på prompten?