Claude får en säkrare väg in till privata system

Claude-nyheten i dag är inte en ny knapp. Den är mer användbar än så: Anthropic visar hur Claude-agenter kan arbeta när systemen de behöver nå inte ska ligga öppna mot internet. För svenska team som vill koppla AI till ärendehantering, databaser, dokument eller interna verktyg är det här ofta den saknade biten mellan demo och riktig drift.

Det senaste: privata kopplingar utan öppna dörrar

Anthropic lade den 19 maj in två viktiga plattformsändringar i Claude Platform: MCP tunnels i research preview och self-hosted sandboxes för Claude Managed Agents. Claude Managed Agents är Anthropics plattform för att köra agentiska arbetsflöden, alltså AI-flöden där modellen planerar, använder verktyg och fortsätter över flera steg. En sandbox är en avgränsad körmiljö där verktyg och kod kan köras utan att få fri tillgång till resten av organisationens system.

Poängen är enkel: agenten kan fortfarande styras via Claude-plattformen, men verktygskörning och privata system kan hållas närmare den egna infrastrukturen. MCP, Model Context Protocol, är den öppna standard som låter AI-appar koppla sig till datakällor, verktyg och arbetsflöden. En MCP-tunnel är en skyddad väg från Claude till privata MCP-servrar utan att servern behöver exponeras publikt.

Källa: Claude Platform API release notes och Model Context Protocol introduction.

Claude Code hade också en ny version, 2.1.150, men den var uttryckligen intern infrastruktur utan ändringar som syns för användare. Därför är dagens praktiska signal bredare än terminalen: hur Claude kopplas till riktiga system på ett sätt som säkerhets- och driftansvariga faktiskt kan leva med.

Källa: Claude Code v2.1.150 release.

Varför detta spelar roll för praktiska team

Många AI-piloter fastnar i kopiera-klistra in-läget. Någon exporterar ett underlag, klistrar in det i chatten, ber Claude skriva ett svar och flyttar sedan resultatet tillbaka för hand. Det fungerar för att lära sig. Det skalar dåligt.

Med MCP och sandboxes blir frågan mer konkret: vilka system får Claude läsa, vilka åtgärder får den föreslå, vilka åtgärder får den utföra, och var ska en människa godkänna? Ett servicebolag kan till exempel börja med att låta Claude läsa ärenden och föreslå svar, men kräva godkännande innan något skickas till kund. En ekonomifunktion kan låta Claude jämföra fakturarader mot avtal, men logga beslut och stoppa allt som ändrar betalningar.

Det är den typen av karta vi bygger i Verktygssmide: inte bara "koppla in AI", utan bestäm vilka kopplingar som är värda att ha, vilka rättigheter de behöver och hur redigering, loggning och stoppknappar ser ut.

Så testar du signalen den här veckan

Välj ett arbetsflöde där Claude redan hjälper till, men där människor fortfarande flyttar data manuellt mellan två system. Bra kandidater är kundärenden, offertunderlag, interna kunskapsartiklar eller rapportutkast.

Gör sedan en enkel integrationsskiss innan du bygger något:

• Vilka system behöver Claude läsa?
• Vilka verktyg behöver Claude använda?
• Vilka hemligheter ska ligga i miljövariabler eller en hemlighetshanterare, inte i chatten?
• Vilka rättigheter kan göras snäva med avgränsade API-nycklar eller en särskild serviceanvändare?
• Vilka steg kräver mänskligt godkännande?
• Vilka loggar ska sparas som metadata utan att spara kundtext, lösenord eller hela prompts?

Det här är en integrationsfråga, inte en moralpredikan om att "inte dela data". Rätt gjort kan Claude få tillgång till mer användbar kontext med mindre slarv: avgränsade behörigheter, redigerade utdrag, godkännandepunkter och granskningsloggar i stället för fria textdumpningar.

Testa den här prompten i veckan

Använd den i Claude-chatt om du vill planera arbetsflödet, eller i Claude Code om du vill gå vidare mot en teknisk skiss. Börja med en process som du förstår väl och där du kan granska resultatet innan något påverkar en kund.

Du är min integrationsarkitekt för ett Claude-arbetsflöde.

Arbetsflöde: [beskriv processen, till exempel "hantera inkommande serviceärenden och föreslå svar"]
System som kan vara relevanta: [ärendesystem, CRM, dokument, databas, e-post, GitHub, Notion eller annat]

Skapa en praktisk karta med:
1. Vilken information Claude behöver läsa och varför.
2. Vilka åtgärder Claude bara får föreslå, och vilka den eventuellt får utföra efter godkännande.
3. Om MCP passar: vilka MCP-servrar eller interna API:er behövs, och bör de vara lokala, privata via tunnel eller publika?
4. Var en sandbox behövs för kod, filer eller verktygskörning.
5. Hur hemligheter hanteras: miljövariabler, hemlighetshanterare, avgränsade API-nycklar och minst möjliga behörighet.
6. Vilka fält som ska redigeras bort innan text skickas till Claude.
7. Vilka granskningsloggar vi behöver: tid, system, åtgärd, beslut, mänskligt godkännande och fel.
8. En första torrkörning utan externa sidoeffekter.

Avsluta med en enkel risklista och en rekommenderad första version som går att testa på en eftermiddag.

Bra resultat ser ut så här:

• Claude ritar upp läsbehörigheter, skrivbehörigheter och godkännanden separat.
• Hemligheter hamnar i miljövariabler eller hemlighetshanterare, inte i prompten.
• MCP används för verkliga systemkopplingar, inte som ett modeord.
• Det finns en torrkörning där inget skickas, ändras eller publiceras.
• En människa har en tydlig punkt där arbetet kan godkännas, ändras eller stoppas.

Vad vi bevakar härnäst

MCP tunnels är fortfarande research preview och self-hosted sandboxes är en plattformsfunktion att utvärdera, inte något varje litet team behöver införa i morgon. Men riktningen är tydlig. Claude rör sig från "smart chatt" mot en arbetsmiljö där agenten kan nå rätt system, använda rätt verktyg och ändå hållas inom tydliga gränser.

För Hammer-läsare är nästa steg inte att jaga varje ny release. Det är att välja ett verkligt arbetsflöde och rita gränserna ordentligt: data in, verktyg ut, mänsklig kontroll på rätt plats.