Låt AI logga in utan att lämna ut lösenordet – rita åtkomstkartan först

Ett lösenord kan vara osynligt för AI:n och kontot kan ändå vara fel skyddat. Det är den obekväma detaljen bakom nya lösningar som låter agenter logga in åt oss: säker hantering av hemligheten är inte samma sak som säker användning av den inloggade sessionen.

Det första problemet är tekniskt: lösenord, engångskoder och tokens ska inte hamna i modellens kontext. Det andra är operativt: efter inloggningen måste någon fortfarande bestämma vad agenten får läsa, ändra, skicka, köpa eller radera.

Den här guiden hjälper dig att separera de två frågorna och fylla i en delegerad åtkomstkarta före första piloten.

Vad delegerad åtkomst betyder för en AI-agent

Delegerad åtkomst betyder att en agent får tillfällig, avgränsad åtkomst för en bestämd uppgift utan att få en återanvändbar hemlighet. Bra delegation svarar på tre olika frågor:

• Hur levereras inloggningen? Hemligheten ska helst fyllas i eller injiceras utanför modellens vy.
• Vem godkänner autentiseringen? En människa eller en uttrycklig policy måste tillåta rätt konto för rätt session.
• Vad får agenten göra efteråt? Läsning, utkast, skrivning och oåterkalleliga åtgärder behöver egna gränser.

Om de tre svaren ligger i samma ruta – ”agenten har åtkomst” – är kartan för grov.

1Password för Claude visar en lokal överlämning

1Password för Claude är ett tydligt exempel på att hålla själva hemligheten utanför agentens synfält. När Claude behöver logga in visar 1Password vilket valvobjekt som begärs. Användaren kan godkänna, byta konto eller neka. Efter godkännande fyller 1Password i uppgifterna direkt på webbplatsen medan Claude tillfälligt slutar läsa sidan. Lösenord och engångskoder ska enligt dokumentationen inte hamna i Claudes kontext, minne eller Anthropics system.

Källa: 1Password Support – Use 1Password to sign in to websites with Claude

Säkerhetsmodellen använder ett nytt godkännande för varje agentsession. Uppgifterna är sessionsbundna och kortlivade, och misslyckad ifyllning ska rensas innan agenten får tillbaka kontrollen. 1Password beskriver samtidigt en viktig gräns: efter lyckad inloggning styr agentproduktens egna skydd vad agenten gör på webbplatsen. Lösenordshanteraren garanterar inte beteendet i den inloggade sessionen.

Källa: 1Password Support – About the security of 1Password for Claude

Det här är fortfarande en beta med snäv kompatibilitet. Claude anger betalda planer och Claude Desktop på macOS. 1Password kräver Mac-appar och webbläsartillägg, och stödet omfattar användarnamn, lösenord och tidsbaserade engångskoder. Passnycklar och social inloggning stöds inte i den nuvarande lösningen.

Källa: Claude Help Center – Get started with 1Password for Claude

Perplexity SPACE visar samma princip på plattformsnivå

Perplexity beskriver en annan teknisk form i sin SPACE-arkitektur för Computer. Inloggningsuppgifter ligger utanför den isolerade körmiljön och kan fyllas i i webbläsaren eller injiceras i nätverkslagret när de behövs. Arkitekturen beskriver hierarkisk avgränsning, utgångstid, hastighetsgränser och loggning av åtkomst.

Källa: Perplexity – Secure Sandboxes for Agents

Det är ett användbart designmönster, inte en produktgaranti för varje agentverktyg. SPACE driver Perplexity Computer, men den offentliga arkitekturbeskrivningen ska inte läsas som att alla kontroller finns som en separat, köpbar API-funktion. Verifiera alltid vad den tjänst och plan ni faktiskt använder kan begränsa och exportera.

Källa: Perplexity Research – Making SPACE: Secure and Efficient Runtimes for Long-Running Agents

Rita åtkomstkartan i tre lager

Börja inte med produktens inställningssida. Börja med ett arbetsdokument där ni fyller i tre lager var för sig.

Lager 1: hemligheten

Beskriv hur autentiseringsuppgiften hanteras.

• Hemlighet: Lösenord, engångskod, API-token, sessionscookie eller annan metod?
• Förvaring: Var finns hemligheten före körningen?
• Leverans: Autofyllning, nätverksinjektion, kortlivad token eller manuell inloggning?
• Exponering: Kan värdet nå modellkontext, prompt, logg, skärmbild, filsystem eller verktygsresultat?
• Livslängd: När upphör uppgiften eller sessionen att gälla?

Målet är inte ”AI:n lovar att inte läsa lösenordet”. Målet är att agenten tekniskt inte behöver få värdet.

Lager 2: autentiseringen

Skriv vem som får öppna vilken dörr.

• Konto: Vilken exakt användare eller tjänsteidentitet används?
• Godkännare: Vem får godkänna inloggningen?
• Tillfälle: Krävs godkännande per körning, per session eller under ett tidsfönster?
• Miljö: Testkonto, sandlåda eller produktion?
• Återkallelse: Vem kan stänga sessionen och koppla bort integrationen?

Använd inte en ägares privata administratörskonto bara för att det redan finns i lösenordshanteraren. Skapa hellre ett konto vars normala behörigheter redan motsvarar pilotens uppgift.

Lager 3: åtgärden efter inloggning

Det här lagret missas oftast. Lista handlingarna som egna beslut:

• Läsa: Vilka sidor, poster, mappar eller kundärenden får agenten se?
• Skapa utkast: Vad får förberedas utan att skickas eller publiceras?
• Skriva: Vilka fält eller objekt får ändras?
• Verkställa: Får agenten skicka, boka, köpa, radera eller ändra behörigheter?
• Gränsvärde: Vilket belopp, antal mottagare eller dataklass kräver stopp?
• Mänskligt godkännande: Vilka åtgärder måste alltid visas före utförande?
• Bevis: Vilken logg, före- och efterbild eller transaktionsidentifierare sparas?

”Kan logga in” får aldrig vara genvägen till ”får göra allt som kontot kan”.

Kopiera den här delegerade åtkomstkartan

Fyll i ett kort per webbplats, konto och uppgift. Blanda inte flera system i samma första pilot.

• Uppgift: Vad ska agenten leverera?
• Webbplats eller system: Var sker arbetet?
• Konto och kontoägare: Vilken identitet används och vem ansvarar för den?
• Hemlighetsväg: Hur når inloggningen sidan utan att nå modellen?
• Godkännandepunkt: Vem godkänner, när och med vilken information framför sig?
• Sessionsgräns: Hur länge gäller åtkomsten och hur avslutas den?
• Tillåtet att läsa: Exakta objekt och dataklasser.
• Tillåtet att skriva: Exakta fält och destinationer.
• Alltid förbjudet: Köp, radering, publicering, nya mottagare eller andra stoppunkter.
• Tröskel: Belopp, volym eller risknivå som kräver människa.
• Loggbevis: Vad ska finnas efter varje körning?
• Återkallelse: Hur stängs konto, session och integration snabbt?
• Reservväg: Hur utförs uppgiften manuellt om agenten stoppas?
• Beslutsdatum: När väljer ni att stoppa, justera eller utöka piloten?

Kör ett test som försöker bryta mot kartan

Ett normalt lyckat test säger för lite. Lägg in ett avsiktligt nekat fall.

1. Skapa eller välj ett testkonto utan administratörsrättigheter.
2. Ge agenten en liten läsuppgift med ett tydligt godkänt resultat.
3. Godkänn exakt en inloggning för den aktuella sessionen.
4. Be därefter agenten försöka utföra en förbjuden skrivåtgärd mot testdata.
5. Kontrollera att åtgärden blockeras eller kräver det godkännande ni skrev in.
6. Avsluta sessionen och verifiera att åtkomsten inte kan återanvändas.
7. Läs loggen och kontrollera att den visar konto, tid, tillåten åtgärd, nekat försök och slutstatus utan att innehålla hemligheten.

Använd inte riktiga kundposter, betalningar eller produktionsadministration för det första negativa testet. Poängen är att bevisa gränsen utan att skapa en incident.

Godkänn piloten först när båda skydden håller

Piloten är inte godkänd bara för att lösenordet saknas i chatthistoriken. Den behöver klara två separata kontroller:

• Hemlighetsskydd: Ingen återanvändbar inloggningsuppgift syns i kontext, loggar, skärmbilder eller arbetsfiler.
• Handlingsskydd: Kontot och arbetsflödet blockerar förbjudna åtgärder även efter lyckad inloggning.

Justera piloten om godkännandet visas otydligt, sessionen lever längre än uppgiften eller loggen inte går att koppla till ett beslut. Stoppa den om agenten kan byta konto, vidga sitt handlingsutrymme eller verkställa ett förbjudet steg utan ny kontroll.

Om kartan avslöjar oklara konton, sessionsgränser eller skrivregler är nästa steg inte att dela ett lösenord ”bara under testet”. Kartlägg åtkomsten i Verktygssmide och bygg en pilot där både inloggningen och handlingen går att återkalla, testa och förklara.