Når en virksomhed går fra at teste Claude i et enkelt team til at
Når en virksomhed går fra at teste Claude i et enkelt team til at køre det i produktion, test og udvikling på samme tid, bliver adgangsstyring hurtigt det første problem, der rammer infrastrukturen. AWS har beskrevet en arkitektur, der løser netop det: tre forskellige adgangsveje til Claude Platform, der alle kan leve side om side uden at dele en enkelt legitimationsoplysning mellem miljøer eller teams.
Det er ikke en teoretisk øvelse. Vi ser det samme mønster hos stort set alle danske virksomheder, der flytter AI-agenter fra pilotprojekt til drift: et team har en API-nøgle, der ligger i en delt konfigurationsfil, en anden afdeling genbruger den samme nøgle til et helt andet workload, og pludselig har ingen overblik over, hvem der egentlig kalder modellen, og hvad det koster hvem.
Adgang
De tre veje ind i Claude Platform
Arkitekturen, AWS beskriver, bygger på tre adgangsmekanismer, der dækker forskellige behov i en organisation.
Den første er SigV4, AWS' egen signeringsstandard for API-kald. Her bruger kaldende tjenester deres eksisterende AWS-identitet (en IAM-rolle) til at signere requests til Claude Platform. Fordelen er, at der ikke findes en separat hemmelighed at lække. Rollen har allerede sine rettigheder defineret i IAM, og adgangen til Claude følger den samme politik-model, som resten af infrastrukturen allerede bruger. For en virksomhed, der kører sine agenter inde i AWS, fra Lambda-funktioner til containere i ECS eller EKS, er det den mest naturlige vej, fordi der ikke skal distribueres nye nøgler til nye systemer.
Den anden vej er workspace-specifikke API-nøgler. Det er den klassiske model, hvor hver arbejdsplads i Claude Platform får sin egen nøgle, der er bundet til netop det workspace og ingen andre. Det er den rigtige løsning, når kaldende systemer ligger uden for AWS, eller når man har eksterne partnere eller leverandører, der skal have adgang til et isoleret workspace uden at få indsigt i resten af organisationens opsætning.
Den tredje er OIDC, OpenID Connect-baseret føderation. Her kan en identitetsudbyder, virksomhedens eget Okta, Azure AD eller lignende, udstede tokens, der giver adgang til specifikke workspaces uden at Claude Platform behøver kende til langlivede legitimationsoplysninger overhovedet. Det er særligt relevant for virksomheder, der allerede har en etableret identitetsplatform og vil undgå at opbygge en parallel adgangsstyring specifikt til AI-værktøjer.
Det, der gør modellen stærk, er ikke den enkelte mekanisme, men at de tre kan bruges samtidig, afstemt efter hvilket system der ringer op. Et produktionssystem i AWS bruger SigV4. En ekstern integrationspartner bruger en workspace-nøgle. Et internt team, der arbejder fra virksomhedens eget identitetssystem, bruger OIDC. Ingen af dem behøver kende til eller dele de andres legitimationsoplysninger.
Det, der gør modellen stærk, er ikke den enkelte mekanisme, men at de tre kan bruges samtidig, afstemt efter hvilket system der ringer op.
Isolation
Hvorfor isolation på workspace-niveau ændrer risikobilledet
Det centrale designvalg er, at adgangen isoleres på workspace-niveau inde i en dedikeret AI Services-konto, ikke på det overordnede kontoniveau. Det betyder, at en fejlkonfiguration eller en kompromitteret nøgle i ét workspace ikke automatisk giver adgang til et andet. Et testmiljø, der eksperimenterer med en ny agent, kan ikke ved et uheld trække på produktionens kvoter, logs eller data, fordi de to simpelthen lever i forskellige isolerede rum, selv om de teknisk ligger under samme overordnede AWS-opsætning.
For en virksomhed, der har flere forretningsenheder eller flere produktteams, der alle vil bruge Claude, er det forskellen på at skulle bygge sin egen adgangsstyring fra bunden og på at få den leveret som en del af selve platformens arkitektur. Vi har set projekter gå i stå, fordi sikkerhedsafdelingen ikke kunne godkende en løsning, hvor alle teams delte samme nøgle med samme rettigheder. Når isolationen i stedet ligger i selve kontostrukturen, bliver godkendelsesprocessen markant kortere, fordi risikoen ved et enkelt workspace aldrig spreder sig til resten af organisationen.
Skalering
Hvad det betyder, når flere teams for alvor begynder at bruge Claude
Som principal konsulent hos AI Enterprise, hvor vi driver større AI-projekter for danske virksomheder fra problemafklaring til drift, ser vi, at adgangsstyring sjældent er det, der bekymrer en virksomhed i starten af et AI-projekt. Det bliver det derimod hurtigt, så snart mere end et enkelt team er i gang.
Den arkitektur, AWS beskriver her, løser et konkret og meget almindeligt problem: hvordan man skalerer brugen af Claude fra ét team til mange, uden at hver ny bruger bliver en ny sikkerhedsrisiko. Når SigV4, workspace-nøgler og OIDC kan leve side om side, og isolationen sidder i selve kontostrukturen i stedet for i interne regler, der nemt glemmes eller omgås, bliver det muligt at vokse organisk. Et team kan starte i det små i et isoleret testworkspace. Når løsningen er klar til produktion, flytter den til et andet workspace med strammere rettigheder, uden at nogen skal bygge en ny adgangsmodel fra bunden hver gang.
Det er den slags fundament, der afgør, om en virksomheds AI-satsning bliver noget, der kan skaleres roligt over flere afdelinger, eller noget, der hele tiden kræver manuel oprydning, fordi adgang og ansvar er blandet sammen fra starten. For danske virksomheder, der er på vej fra pilotprojekt til bred anvendelse af Claude, er netop den skelnen ofte det, der afgør tempoet i resten af udrulningen.