Slik gir du en KI-agent tilgang uten å gi slipp på kontrollen

Snarveien — gi agenten administratortilgang og rydde opp i detaljene senere — skaper akkurat den sprengningsradien som svir team. Her er den lagdelte modellen som unngår det, linje for linje sjekket mot det som faktisk er levert.

Den raskeste måten å koble en KI-agent til et virkelig system på, er å gi den samme tilgangen du ville gitt en nyansatt dag én: full administrator, hvert verktøy, detaljene får vente. Å avgrense tilgangen skikkelig tar tid — noen må avgjøre hvilke verktøy agenten kan røre, hvilke data den kan lese, og hva den får gjøre uten å spørre først. I et lite team som allerede er strukket tynt, vil ingen være den som sinker det. Så standarden blir «gi den bare tilgang», og alle går videre til neste ting.

Den instinkten er feil, og grunnen har ingenting med om agenten virker pålitelig i dag å gjøre. Det handler om hva som skjer den dagen den ikke er det. En agent med rekkevidden til en administrator som gjør en rutinefeil, blir matet med en forgiftet instruksjon gjemt i et dokument den ble bedt om å lese, eller rett og slett er sikker og feil om hva et verktøykall vil gjøre, har nå rekkevidden til en administrator. Feilen er ikke et dårlig chatbotsvar man kan trekke på skuldrene av — det er sprengningsradien til en kompromittert administratorkonto, bare at den kan handle i maskinhastighet, på tvers av hvert system den berører, uten at noen ser på i sanntid og fanger det før skaden hoper seg opp.

Stabelen som faktisk holder sprengningsradien inne

God tilgangsdesign for en KI-agent er ikke én bryter man slår om. Det er seks separate beslutninger, stablet oppå hverandre, der hvert lag finnes for å stoppe en bestemt måte den første feilen blir en mye større på. Å hoppe over et lag forenkler ingenting — du har bare flyttet feilpunktet til et sted som er mindre synlig.

Ingen av disse seks lagene er eksotiske. Hvert av dem lukker et hull laget over lar stå vidåpent — identitet alene stopper ikke for bred verktøytilgang, og en verktøyliste alene stopper ikke en stille, ugjenkallelig handling. De virker bare stablet.

Identitet: én innlogging, ikke en skyggeinnlogging

Begynn med identitet, fordi alt over den arver fra den. Hvis en agents tilgang er knyttet til en innlogging IT ikke vet finnes, betyr de senere lagene ingenting — du kan ikke tilbakekalle en tildeling du aldri visste var der. FabricLoops Enterprise-plan kobler arbeidsområdet til organisasjonens identitetsleverandør via SSO og SAML, samme mekanisme som allerede styrer pålogging for e-post og resten av selskapets programvare. Det betyr noe spesielt for agenttilgang, fordi KI-tilkoblinger og vanlig samarbeidstilgang da går gjennom én identitetshistorie i stedet for to. Når IT deprovisionerer noen i identitetsleverandøren, fjerner den ene handlingen personens FabricLoop-tilgang og, med den, alle MCP-tilkoblinger knyttet til innloggingen — i stedet for å etterlate en foreldreløs agentlegitimasjon som ingen husker å rydde bort.

En tildeling per person, i begge retninger

FabricLoops KI-tilkoblinger går i to retninger, og samme prinsipp — ingen delt, teamomfattende legitimasjon — gjelder begge.

Inngående er når et eksternt verktøy som Cursor, Claude eller ChatGPT kobler seg til FabricLoop som MCP-klient, slik at det kan lese eller skrive oppgaver, notater og meldinger med noens faktiske tillatelser. FabricLoops egne oppsettsinstruksjoner er tydelige på at dette er en prosess per person: hver person åpner samtykkeskjermen på app.fabricloop.com/oauth/consent, velger arbeidsområdet og godkjenner de konkrete verktøyomfangene klienten får — ikke en bryter for hele arbeidsområdet som en administrator slår om én gang for alle. Veiledningen til team nevner feilmodusen dette er bygget for å hindre, rett ut: ikke del én persons tilgangstoken i teamet, for hver person skal fullføre sitt eget samtykke. Resultatet er en liste over tilkoblede klienter som er synlig per person og kan tilbakekalles per person, ikke et tilgangstoken begravd i en konfigurasjonsfil som overlever grunnen til at det ble opprettet.

Utgående er speilbildet: FabricLoop som kobler seg ut til en tredjepartsapp i sin egen MCP-katalog, for eksempel en prosjektoppfølging eller et kalenderverktøy. Her er skillet bevisst. En administrator aktiverer appen for hele arbeidsområdet — en beslutning om verktøyet i det hele tatt skal få finnes i organisasjonen — og deretter kobler hver person som vil bruke den, sin egen individuelle konto. En administrator som slår om den bryteren, gir ikke hver ansattes identitet til appen; det gjør bare alternativet tilgjengelig, og hver person må fortsatt autentisere seg som seg selv før tilkoblingen gjør noe.

Omfang: skrivebeskyttet, eller en liste — ikke alt eller ingenting

Identitet svarer på hvem. Tildelinger per person svarer på hvem sin konto. Ingen av dem svarer på spørsmålet som faktisk avgjør hvor stor en feil blir: hva tilkoblingen kan gjøre når den er live. Det er det tredje lagets jobb.

På detaljskjermen for en tilkoblet app kan en administrator sette et visningsnavn, slå på skrivebeskyttet modus og velge en verktøypolicy — enten hvert tilgjengelige verktøy, eller en bestemt liste. Det er forskjellen mellom «denne agenten kan lese oppgavetavlen vår» og «denne agenten kan lese oppgavetavlen vår og også slette poster, tildele eiere på nytt og publisere i hver kanal». De fleste tilkoblinger trenger ikke den andre versjonen, og de fleste historiene om at en agents tilgang går galt på den måten folk frykter, begynner med en tilkobling som fikk hvert verktøy som standard, fordi ingen kom på å krysse av boksen som begrenser den.

FabricLoops sikkerhetsside beskriver de resulterende tildelingene som «avgrenset» og uttrykkelig «ikke permanent, usynlig tilgang» — revidert og tilbakekallelig, samme språk selskapet bruker på siden som forklarer Lesbarhet, ideen om at KI-tilgang skal være noe du kan navngi og inspisere, i stedet for taus kunnskap om hvilket gammelt bot-token som fortsatt virker.

Kjøreatferd: agenten utformer, en person sender

Alt over dette laget styrer hva en agent kan nå. Dette styrer hva den får gjøre når den er fremme — og det er laget de fleste team hopper over, fordi det er det som føles tregest.

FabricLoops innebygde assistent, Loop, er bygget rundt en begrensning selskapet sier rett ut i sin egen produktdokumentasjon: «Loop utformer; du sender. Den publiserer ikke i en kanal eller varsler noen på egen hånd.» Be den oppsummere en tråd, så oppsummerer den. Be den skrive en oppdatering, så skriver den et utkast — og en person må fortsatt gjennomgå og sende det før noen andre ser det. Samme mønster gjelder agenter som lever i en kanal som lagkamerater: når en av dem venter på en beslutning fra en person, gjetter den ikke og går ikke videre. Den dukker opp under «Venter på deg» på den kanalens fane Apper og agenter — akkurat flaten teamet allerede sjekker, ikke en egen konsoll ingen husker finnes.

Det er den praktiske formen av det agentrammeverk-litteraturen kaller et ask_human / resume-mønster: agenten pauser der skjønn kreves, spør, og fortsetter først når en person svarer. FabricLoop rammer inn den underliggende ideen som Menneskelig intervensjonsrate — ikke «hvor ofte trenger agenten et menneske», behandlet som en feil man skal konstruere bort, men et tall hvert team som kjører agenter faktisk bør måle og utforme for, i stedet for å oppdage det for første gang under en hendelse.

Sikringen: en forbruksgrense som faktisk stopper kjøringer

Tilgangskontroll handler ikke bare om hva en agent kan lese eller endre. Det handler også om hva den kan koste — og en løpsk agent trenger ikke røre noe sensitivt for å gjøre reell skade hvis den gjør dyre modellkall i en løkke ingen ser på.

Administratorer på FabricLoops betalte planer setter en månedlig forbruksgrense for agentbruk i Bruk og fakturering, og kan slå på et hardt stopp som pauser nytt agentarbeid automatisk når forbruket treffer tallet. Det er en ekte sikring, ikke et overvåkingsdashbord: forskjellen mellom å merke at fakturaen var høy i slutten av måneden, og nye agentkjøringer som stopper seg selv i det øyeblikket de krysser tallet noen satte. Gratis arbeidsområder får ingen dollargrense, fordi det ikke finnes produksjonsforbruk å begrense — de kjører på inkluderte kreditter som bare er til test, noe som i seg selv er en omfangsgrense, bare håndhevet på en annen måte. På en betalt plan er å heve grensen den eneste måten å gjenoppta på etter at et hardt stopp slår inn, og det er akkurat friksjonen du vil ha i det øyeblikket: noen må aktivt bestemme seg for å bruke mer, i stedet for at systemet stille faller tilbake til ubegrenset.

Revisjon og tilbakekall: én person, eller alle, på én gang

Det siste laget antar at de fem første til slutt svikter et sted, for noen, og spør hva som skjer deretter.

FabricLoop skiller mellom to typer tilbakekall, og skillet betyr noe. «Trekk tilbake tilkoblingen min» er tilgjengelig for enhver person og kobler umiddelbart fra bare den personens tilgang — verktøyet slutter å virke for dem uten å røre noen andre på teamet som også er tilkoblet. «Deaktiver appen for arbeidsområdet» er bare for administratorer og er den videre handlingen: den arkiverer appen helt og tilbakekaller hver tilkobling til den på én gang, for tilfellet der problemet ikke er én persons konto, men appen selv. Samme skille finnes på den inngående siden, der enhver person kan tilbakekalle en MCP-klient de koblet til, umiddelbart, fra Innstillinger → KI / MCP.

Ingenting av det betyr noe uten innsyn i hva som skjedde før noen trakk ut kontakten. FabricLoops Enterprise-revisjonslogger er ikke bare en innloggingshistorikk — selskapet beskriver dem som å dekke administrator- og agentaktivitet, og de egne materialene om begrepet Lesbarhet navngir «MCP-revisjonshendelser» spesifikt som noe sikkerhetsteam kan gjennomgå, ikke bare slutte seg til ut fra konteksten. Det er forskjellen mellom et sikkerhetsteam som spør «rørte noen dette?» og får et ekte svar, og å rekonstruere en tidslinje fra gamle meldinger og noens minne om hva en agent syntes å gjøre den ettermiddagen.

Det FabricLoop sier ikke er sant ennå

Hver påstand ovenfor er noe FabricLoop faktisk har levert. Det er verdt å være like tydelig på hva som ikke er levert, for et selskap som bare forteller den første halvdelen, ber deg stole på det i blinde — og blind tillit er ikke det en lesbar sikkerhetsholdning betyr.

FabricLoops egen sikkerhetsside lister opp hva som er sant i dag, og deretter en egen del, rett ut titulert «Ennå ikke på plass», som navngir tre konkrete hull: SOC 2- eller ISO 27001-sertifisering, penetrasjonstesting av tredjepart og SCIM-provisjonering. Sidens ramme er uvanlig direkte for en leverandørs sikkerhetsside: i stedet for å liste hver sertifisering andre leverandører har, sier den: her er nøyaktig hva som er sant akkurat nå — og hva som ennå ikke er på plass, fordi selskapet heller sier det rett ut enn å la en kunde finne det ut senere.

For et team som veier om det skal koble en agent til ekte selskapsdata, er det ikke vage risikoer — det er tre navngitte, sjekkbare punkter du kan ta opp i en sikkerhetsgjennomgang, følge og ta opp igjen før fornyelse. En uttalt liste over hull er mer verdt enn en vag forsikring om at alt er i orden, nettopp fordi den kan sjekkes. Det er samme argumentet bak Lesbarhet som begrep: tilgang og holdning du kan navngi og verifisere, slår tilgang og holdning du bare blir bedt om å stole på.