Ny åtkomstmodell, inte ett allmänt upplåst Claude

Anthropic presenterade den 6 oktober ett utökat Cyber Verification Program, CVP. Säkerhetsteam kan ansöka om tre åtkomstnivåer med olika skydd och krav. Nyhetsvärdet ligger i ändrad tillgång till AI för säkerhetsarbete, inte i en ny modellversion eller en ny CVE. Uppgifterna är kontrollerade den 7 oktober; LabOps IT har inte testat programmet.

Lanseringen skiljer mellan Defense Access för försvarsarbete, Red Team Access för auktoriserad säkerhetstestning och Specialized Access för särskilt känsliga system. Den högsta nivån är begränsad till verifierade organisationer. Detta är ett ansökningsprogram, inte generell tillgänglighet utan prövning.

Claude Sonnet 5.5 presenterades redan den 28 september enligt Anthropics nyhetsrum. Modellens produktsida är bakgrund till den nya åtkomstmodellen, inte dagens huvudnyhet. LabOps IT har tidigare behandlat modellsläppen och Enterprise Frontier Safeguards; de återpubliceras inte här.

Välj nivå efter uppdraget

För ett driftteam är det första beslutet vad AI ska hjälpa till med. Incidentanalys och granskning av egna system behöver inte samma befogenheter som ett separat, auktoriserat testuppdrag. LabOps IT rekommenderar att skriva ned mål, systemgräns, informationsklass och ansvarig person innan någon ansökan görs.

Tillgång till ett program innebär inte rätt att testa någon annans system. Ett avtalat uppdrag behöver även lokal avgränsning: vilka miljöer som omfattas, när arbetet får ske och vem som får godkänna avvikelser. Denna artikel beskriver styrning och försvarsarbete, inte exploateringsmetoder.

Help Center beskriver både organisationsansökningar och Defense Access för enskilda forskare. Sidan innehåller samtidigt en äldre hänvisning till ”Tier C” i ansökningsavsnittet. LabOps IT använder därför de nya nivånamnen och rekommenderar att individuella sökande får sin faktiska behörighet bekräftad. Vi lovar ingen viss handläggningstid eller beviljad tillgång.

Börja med minsta åtkomst som täcker det dokumenterade behovet. Om en uppgift blockeras ska teamet kontrollera uppdrag och beviljad nivå, inte försöka kringgå skyddet. Den kontrollen ger också underlag för en saklig supportfråga.

Identitet och nycklar blir ett införandeprojekt

Programmets säkerhetskrav anger att Defense Access ska ha multifaktorautentisering från start. Senast den 15 december 2026 krävs nätfiskeresistent MFA och en övergång bort från långlivade statiska autentiseringsuppgifter. Tillfälligt tillåtna API-nycklar har särskilda förvarings- och rotationskrav.

Red Team Access har skarpare krav redan vid tilldelningen: bland annat nätfiskeresistent MFA, kortlivade autentiseringsuppgifter och styrda enheter. Kravtexten omfattar också avgränsad utgående trafik vid agentarbete. Detaljerna måste kontrolleras för den plattform där modellen används; samma autentiseringslösning ska inte antas fungera överallt.

LabOps IT:s rekommendation är att involvera identitets- och plattformsteam innan piloten bokas. Inventera vilka människor, tjänster och integrationer som faktiskt anropar modellen. Ett användarkonto och en automatiserad arbetslast är olika identiteter och behöver var sin spårbar ägare.

Prova även återkallning. Om en användare lämnar uppdraget eller en autentiseringsuppgift misstänks vara röjd behöver åtkomsten kunna stoppas utan att ett gemensamt konto gör andra användares arbete ospårbart. Registrera hur återkallningen verifieras, inte bara vilken inställning som ändrades.

Beviljad åtkomst måste nå rätt arbetsyta

Claude Consoles arbetsytedokumentation skiljer mellan en organisations beviljade program och vilka arbetsytor som får använda dem. En Admin eller Owner hanterar tilldelningen. Status och kvalifikationskrav behöver kontrolleras för den aktuella arbetsytan; vissa program har ytterligare begränsningar.

Det betyder att ett godkänt ansökningsbesked inte ensamt bevisar att en integration använder rätt åtkomst. Kontrollera användare, arbetsyta, programstatus och vilken identitet API-trafiken faktiskt kommer från. Dokumentationen anger också att vissa program inte kan tilldelas standardarbetsytan; detta ska kontrolleras, inte antas vara ett universellt CVP-krav.

LabOps IT rekommenderar en separat pilotarbetsyta med namngivna deltagare och syntetiska testdata. Kontrollflödet nedan är vår rekommenderade införandeordning, inte en garanti om att leverantören automatiskt granskar varje resultat.

LabOps IT:s rekommenderade kontrollflöde. Animationen visar överlämning mellan kontroller, inte angrepp eller automatiska garantier.

Ett säkert prov kan vara att analysera en anonymiserad incidentrapport med känt facit. Låt en ansvarig granskare jämföra slutsatserna med underlaget. Tillgång till mer avancerade funktioner ska inte göra agentens egen förklaring till enda acceptanskriterium.

Datalagring måste avgöras före känsligt underlag

Lanseringen anger datalagring som grundregel för organisationer i CVP, med särskilda befintliga undantag. Enterprise Frontier Safeguards, EFS, beskrivs fortfarande som kommande senare under hösten. Artikeln ger därför inget besked om att alla deltagare redan kan använda programmet med zero data retention.

EFS-beskedet från den 1 september beskriver lagring i kundkontrollerad molninfrastruktur, egna åtkomstregler och en modell där kunden granskar signaler om missbruk. Det är bakgrund till en planerad arkitektur, inte bekräftelse på generell leverans den 7 oktober.

LabOps IT:s rekommendation är att behandla lagring, granskning och informationsåtkomst som separata beslut. Incidentunderlag kan innehålla kontonamn, interna adresser, känsliga loggutdrag och kundinformation. Bestäm vad som får skickas och hur materialet ska minimeras innan det läggs i en modellförfrågan.

En egen lagringsplats avgör inte ensam alla frågor om tjänstens behandling av information. Be om underlag för den faktiska kombinationen av avtal, molnplattform och programnivå. För en pilot är syntetiskt material en tydligare startpunkt än att försöka efterlikna produktion med verkliga hemligheter.

Mät granskat resultat, inte leverantörens räckvidd

Anthropic redovisar egna utvärderingar i lanseringen. De är leverantörsresultat, inte LabOps IT:s tester eller en garanti för ett enskilt säkerhetsteam. Här används inga benchmarktal som argument för att införa programmet.

Vår rekommendation är att mäta korrekta slutsatser, missade viktiga uppgifter, felaktiga påståenden, granskningstid och behov av kompletterande underlag. Använd samma testfall för befintligt arbetssätt och pilot. Spara också de fall där modellen korrekt uttrycker osäkerhet.

Låt piloten börja med läsning och förslag. Ändringar av konton, nätverksregler eller produktionssystem bör ligga bakom en separat mänsklig kontrollpunkt. Att en modell får en viss programnivå säger inget om vilka lokala verktygsbehörigheter den bör tilldelas.

LabOps IT:s bedömning

Det utökade CVP har konkret praktiskt värde eftersom det kopplar AI-åtkomst till olika säkerhetsuppdrag och dokumenterade införandekrav. För svenska teknikteam är identitet, arbetsytor och hantering av incidentdata minst lika viktiga som modellvalet.

LabOps IT:s åtgärdsprioritet är Planerad utvärdering. Det finns ingen CVE, exploateringsstatus eller akut patchåtgärd kopplad till själva programnyheten. Ansvariga bör först avgränsa behovet, kontrollera kraven och prova en liten granskningsbar arbetsgång. Varken ansökan eller leverantörens testresultat ersätter verifiering i den egna miljön.

Källor