När AI-agenten kan styras på distans: bygg en device gate först

Det som började som en bekväm idé håller på att bli en ny säkerhetsfråga: AI-agenten kör lokalt på datorn, men kan följas och styras från mobilen eller webben.

Det låter oskyldigt. Du sitter på tåget och godkänner ett steg. En kollega ser hur långt agenten har kommit. En utvecklare fortsätter ett jobb från telefonen. Men samma bekvämlighet ändrar också ytan för ansvar: vilken enhet får se sessionen, vem får trycka godkänn, vilka projekt får aldrig öppnas på distans, och hur stoppar ni allt om en telefon försvinner?

Claude Code och OpenAI Codex pekar nu mot samma arbetsmönster från två håll. Anthropic har lagt till Trusted Devices för Remote Control i Team och Enterprise, där administratörer kan kräva att medlemmar verifierar sin enhet innan de ser eller styr lokala Claude Code-sessioner. OpenAI beskriver Codex Remote som allmänt tillgängligt, med ChatGPT-mobilen som väg för att starta eller fortsätta Codex-arbete på parade Mac- eller Windows-värdar.

Källa: Claude release notes: Trusted Devices for Remote Control och OpenAI Codex changelog

Poängen är inte att Claude Remote Control och Codex Remote har samma säkerhetsmodell. Det har de inte. Poängen är att fjärrstyrning flyttar agentarbete från “jag sitter vid min dator och ser allt” till “flera godkännanden, skärmar och enheter kan hamna i samma körning”. Då räcker det inte med vanlig inloggning. Ni behöver en device gate, en enkel enhetsgrind för agentjobb.

Vad en remote agent device gate är

En remote agent device gate är en liten kombination av policy, konfiguration och vana. Den svarar på en fråga innan tekniken sprids: vilka enheter får visa, fortsätta eller godkänna lokala agentjobb?

Den behöver inte vara ett stort säkerhetsprojekt. För ett första Hammer-upplägg räcker ofta sex beslut:

• Parade enheter: vilka telefoner, webbläsare eller datorer får kopplas till lokala agent-sessioner?
• Projektgränser: vilka mappar, kodarkiv, kunder eller ärenden får aldrig öppnas via fjärrstyrning?
• Godkännanden: vilka åtgärder får godkännas från mobilen, och vilka kräver att ägaren sitter vid arbetsdatorn?
• Logg: vad sparas när någon fjärrstyr, godkänner, stoppar eller byter enhet?
• Koppla bort: hur kopplar ni bort en enhet snabbt?
• Nödstopp: vem får stoppa sessioner om en enhet tappas bort, ett konto lämnar organisationen eller ett projekt visar sig vara känsligare än väntat?

Det här är nära släkt med behörigheter, men inte samma sak. En användare kan vara rätt person och ändå sitta på fel enhet, fel nätverk eller fel plats för just den här agentkörningen.

Varför vanlig inloggning inte räcker

Claude Remote Control-dokumentationen beskriver att Claude Code-sessionen fortsätter att köra lokalt på användarens maskin. Den lokala miljön kan innehålla filsystem, MCP-servrar, verktyg, projektkonfiguration och lokala sökvägar. Anthropic skriver också att Remote Control är en research preview, finns på alla planer, men är avstängt som standard i Team och Enterprise tills en ägare slår på det i administratörsinställningarna.

Källa: Claude Code Remote Control docs

Det gör fjärrstyrning användbar. Det gör den också annorlunda än en vanlig webbapp. Om agenten kan se lokala filer, föreslå terminalsteg eller använda projektspecifika verktyg, då blir den fjärranslutna enheten en del av arbetsytan. En mobiltelefon är inte längre bara en notifieringsskärm. Den kan bli en godkännandeyta.

Claude Code-säkerhetsdokumentationen beskriver ett permission-baserat arbetssätt: läsrätt som standard, uttryckligt godkännande för känsliga åtgärder, och möjlighet att sätta regler på användar-, projekt- eller organisationsnivå. Det är bra. Men godkännandeprompten är bara så stark som sammanhanget runt den. Om någon godkänner från en liten skärm utan att se kodarkiv, diff, logg eller risk är godkännandet svagare än det ser ut.

Källa: Claude Code security docs

Därför bör en device gate inte bara fråga “är användaren inloggad?”. Den bör fråga “är den här enheten och den här situationen rimlig för den här typen av beslut?”.

Codex Remote gör samma fråga mer vardaglig

OpenAI:s Codex changelog beskriver Codex Remote som allmänt tillgängligt den 25 juni 2026. Användare kan använda ChatGPT-mobilappen för att starta eller fortsätta arbete på en ansluten Mac- eller Windows-värd, granska framsteg och godkänna åtgärder från telefonen. Changeloggen nämner också en-till-en-parning med QR-kod, uppdatering av både mobilapp och Codex App, och att vissa äldre inaktiva anslutningar behöver paras igen.

Källa: OpenAI Codex changelog

För organisationer utan stor IT-avdelning är det här den praktiska risken: funktionen känns som en produktivitetsdetalj, inte som ett nytt styrningsområde. Men om teamet använder Codex, Claude Code, MCP-servrar, lokala repo:n och fjärrgodkännanden i samma vecka har ni redan en agentisk arbetsyta. Den behöver driftsvanor.

Det betyder inte att man ska stänga av allt. Remote-styrning kan vara rimlig för lågriskjobb: följa en lång testkörning, läsa status, godkänna ett ofarligt nästa steg eller fortsätta ett isolerat experiment. Men kunddata, produktionskod, ekonomiflöden, HR-underlag och juridiska dokument ska inte smyga in i samma standardläge.

Sätt gränsen vid beslutet, inte vid verktyget

Det är lätt att göra listan verktygsbaserad: Claude får detta, Codex får detta, telefonen får detta. Börja hellre med beslutstyper.

En enkel första indelning:

• Visa status: okej på fjärrenhet för de flesta lågriskjobb.
• Svara agenten med ny instruktion: okej om projektet är låg risk och instruktionen inte ger nya behörigheter.
• Godkänna läsning eller analys: ofta okej, men logga källa och projekt.
• Godkänna filändring: kräver diff, testplan och tydlig rollback.
• Godkänna terminalkommando: kräver extra försiktighet, särskilt om kommandot påverkar filer, nätverk, credentials eller deploy.
• Godkänna extern åtgärd: e-post, faktura, CRM, kalender, publicering, kundsystem och beställningar bör normalt kräva arbetsdator, större skärm eller separat mänsklig kontroll.

Det här gör policyn lättare att leva med. Ingen behöver minnas varje produktdetalj. Teamet behöver veta vilka beslut som är tillräckligt små för mobilen och vilka som ska vänta.

30-minuterschecken innan ni aktiverar fjärrstyrning

Innan fjärrstyrning blir vardag, samla ägare för workflow, IT/teknisk person och den som faktiskt använder agenten. Gå igenom detta på 30 minuter:

1. Välj ett pilotprojekt. Välj inte hela repo:t, hela kundmappen eller hela verksamheten. Välj ett avgränsat agentjobb.

2. Skriv vilka enheter som får paras. Personlig mobil? Jobbmobil? Webbläsare på privat dator? Bara hanterade enheter? Bestäm innan länkar och QR-koder börjar cirkulera.

3. Bestäm maxnivå för fjärrbeslut. Till exempel: mobilen får visa status och godkänna läsning, men inte filändring, terminalkommando eller extern åtgärd.

4. Skapa en stoppregel. Om agenten ber om ny credential, öppnar oväntad mapp, vill köra nätverkskommando eller föreslår deploy: stoppa och flytta beslutet till arbetsdatorn.

5. Testa avparning. Para en enhet, kör ett lågriskjobb, koppla bort enheten och kontrollera att den verkligen inte längre kan styra sessionen.

6. Spara ett kvitto. Logga session, projekt, parad enhet, beslut, godkännanden, fel, stopp och vem som följde upp.

Det är inte byråkrati. Det är det som gör att fjärrstyrning kan användas utan att bli ännu en osynlig genväg.

Hammer-vinkeln: bygg grinden runt ett riktigt arbetsflöde

I Verktygssmide börjar vi inte med en policy-PDF. Vi börjar med ett verkligt flöde där fjärrstyrning faktiskt sparar tid: ett långkörande test, en intern rapportkörning, en kodagent som väntar på review, eller en AI-assistent som förbereder ett ärende men inte får skicka något externt.

Sedan ritar vi grinden:

• vem äger sessionen,
• vilken enhet får styra,
• vad får godkännas på distans,
• vad måste vänta,
• vilken logg behövs,
• och hur backar ni om något känns fel.

Om rutinen behöver läras ut till fler personer blir det Tekniksmide: korta instruktioner, exempel på stoppregler, övningar med testdata och en tydlig vana för att inte godkänna för mycket från en för liten skärm.

Remote AI-agenter är användbara just för att de minskar friktion. En device gate ser till att friktionen försvinner på rätt ställen, inte där beslutet faktiskt behöver en människa som tittar ordentligt.