Shahar Man, medstifter og administrerende direktør for Backslash Security – Interview Serie

Shahar Man, medstifter og administrerende direktør for Backslash Security, er en erfaren teknologileder med dyb ekspertise i cloududvikling, cybersikkerhed og virksomhedssoftware. Han leder i øjeblikket Backslash Security, et selskab, der fokuserer på at sikre AI-naturlig softwareudviklingsmiljøer, beskytter alt fra IDE’er og AI-agenter til genereret kode og prompt-workflows. Før dette havde han ledende stillinger i Aqua Security, hvor han fungerede som både vicepræsident for produktledelse og vicepræsident for R&D, og hjalp med at opbygge en af de førende platforme for container-sikkerhed på tværs af udviklingslivscyklussen. Tidligere i sin karriere tilbragte Mand over et årti hos SAP, hvor han ledte udviklings- og produktinitiativer, herunder SAP Web IDE, og arbejdede tæt sammen med globale virksomhedskunder, samt bidrog til væksten af udviklerøkosystemet. Hans karriere begyndte i tekniske og ledende stillinger i både startup-miljøer og Israels forsvarsteknologienheder, hvilket gav ham en solid grund i både ingeniørarbejde og storskalasystemer.

Backslash Security er en opkomment cybersikkerhedsplatform, der er specialdesignet til æraen for AI-dreven softwareudvikling. Selskabet fokuserer på at sikre den samlede AI-naturlige udviklingsstak, herunder AI-agenter, kodegenereringsrørledninger og moderne udviklerworkflows, et område, som traditionelle sikkerhedsværktøjer ofte overser. Ved at give synlighed, styring og realtidsbeskyttelse uden at forstyrre udviklervelocity, sigter Backslash på at imødegå de voksende risici, der introduceres af automatiseret kodning og “vibe coding”-miljøer. Da softwareoprettelse i stigende grad skifter mod AI-assisterede systemer, er platformen designede til at sikre, at sikkerheden udvikler sig parallelt med, snarere end at blive en flaskehals, og positionerer Backslash ved skæringen af DevSecOps og næste generations AI-udvikling.

De har haft ledende stillinger i produkt og R&D hos selskaber som Aqua Security og SAP, før du startede Backslash. Hvad var de tidlige signaler, der overbeviste dig om, at AI-naturlig udvikling og vibe coding ville omdefinere softwareoprettelse, og at sikkerhed skulle genopbygges for at støtte det?

Jeg havde allerede oplevet en stor forandring, da software flyttede ind i cloud-naturlige arkitekturer. Hos SAP og senere hos Aqua så vi førstehånds, at når udvikling forandrer sig så meget, kommer sikkerhed normalt til at ligge efter. AI har taget den sandhed til et helt nyt niveau, ikke kun fordi det kan hjælpe med at skrive kode hurtigere, men fordi det har begyndt at omdefinere det samlede miljø omkring softwareoprettelse.

Sikkerhed af kode er nu mindre om koden i sig selv og mere om miljøet omkring den. På under et år er det, der tidligere var et relativt indhegnet og lavrisiko udviklingsopsætning, udvidet til et spredt, højforbundet angrebsflade med lidt oversigt eller styring. Når det sker, ændrer sikkerheds-spørgsmålene omkring kodevulnerabiliteter sig helt. Det virkelige problem er ikke, om en given kode er sårbar. Problemet er, at ved at aktivere AI-dreven udvikling, har vi introduceret systemer, agenter, integrationer og adgangsveje, der strækker sig langt ud over koden i sig selv. Sikkerhed kan ikke længere fokuserer kun på kodes output. Den skal tage hensyn til det samlede miljø, der gør koden mulig.

De beskriver vibe coding som en udvidelse af angrebsfladen ud over kode til prompts, agenter, MCP-servere og værktøjslag. Hvad er de mest misforståede risici i denne nye stak, som udviklere og sikkerhedsteams i øjeblikket overser?

Den største misforståelse er, at mange teams stadig tror, at risikoen bor primært i den genererede kode. Det er kun ét lag. I AI-naturlig udvikling introduceres risiko tidligere og på mange flere steder. Dette kan være i prompts, i konteksten leveret til modellen, i tilladelserne givet til agenterne, i MCP-serverne de forbinder til, eller i de eksterne værktøjer og plugins, der udvider deres rækkevidde. En enkelt brugers laptop kan tages over og bruges som brohovedet for en bredere angreb. Det er et endpoint-problem, der masquerer som et AI-kodningsproblem. I modsætning til kodevulnerabiliteter kan dette ikke kun sætte dine applikationer i fare – det kan også sætte hele din organisation i fare. Hvis du kun kigger på koden, så overser du det meste af billedet.

Traditionel applikationsikkerhed har fokuseret kraftigt på kodegennemgang. Hvordan skal sikkerhedstænkning udvikle sig, når AI-agenter genererer, ændrer og deployer kode i realtid?

Sikkerhed skal flytte sig fra periodisk inspektion til kontinuerlig oversigt. Begrebet om tillid er fuldstændigt brudt — du kan have tillidsfulde modeller og tillidsfulde MCP-servere, men på grund af AI’s ikke-deterministiske natur kan de stadig manipuleres eller blot opføre sig uventet for at skabe uventet risiko.

Dette betyder også, at der skal være en holdningsændring, hvor sikkerhed opererer side om side med udviklingsprocessen, mens den sker, og har langt dybere styring, guardrails og detektions- og responsfunktioner inden for det miljø. Det betyder, at man skal tænke kritisk over, hvilke værktøjer der bruges, hvilken kontekst de forbruger, hvilke politikker der skal styre dem, og hvilke handlinger de udfører i realtid.

Værktøjer som Cursor, Claude Code og GitHub Copilot bliver standard i udviklerworkflows. Hvor ser du de største sikkerhedsgapper, når teams adopterer disse værktøjer uden en ordentlig styringslag?

Det største gab er synlighed. I mange organisationer spreder disse værktøjer sig hurtigt uden en formel gennemgang. Sikkerhedsteams kender ofte ikke, hvilke agenter der bruges, hvordan de er konfigureret, hvilke data de kan få adgang til, eller hvilke eksterne systemer de er forbundet til. Det skaber et skygge-AI-problem, der ligner skygge-IT i princippet, blot hurtigere og mere dynamisk.

Det andet største gab er manglen på gennemførbare politikker. De fleste organisationer har retningslinjer, men retningslinjer alene hjælper ikke meget, når en udvikler bevæger sig hurtigt inde i IDE’en. Uden styring på værktøjs- og workflow-laget risikerer teams at have over-berettigede værktøjer, der ikke opfylder virksomhedsstandarder. Disse værktøjer er ikke i sig selv dårlige, men at adoptere dem uden styring betyder, at man effektivt skalerer udviklingshastighed uden at skale kontrol.

Et tredje opstående gab er, at alle potentielt kan blive udviklere – det, vi kalder borger-udviklere, der bruger vibe coding-værktøjer. Når den finansielle person bruger Claude Code til at automatisere processer og forbinde til interne systemer, skaber det potentiel risiko og er et stort blindt punkt, selv i dag.

Backslash fokuserer på at sikre den samlede AI-udviklingsøkosystem i stedet for enkeltværktøjer. Hvorfor er denne fuld-stak-tilgang nødvendig, og hvad sker der, hvis organisationer fortsætter med at behandle disse risici i isolation?

Fordi risiko ikke bor på én bestemt punkt i din stak. AI-naturlig udvikling er en økosystem-problem, da den opererer på så mange forskellige steder og bruger så mange forskellige værktøjer. IDE’en, modellen, agenten, MCP-serveren, de eksterne plugins og de forbundne datakilder alle påvirker, hvad der bliver bygget og hvordan. Organisationer standardiserer ikke bevidst på ét enkelt værktøj, fordi deres relative styrker skifter så hurtigt. Hvis du sikrer kun ét punkt i den kæde, så overser du stadig, hvordan risiko flytter sig over systemet.

Sikkerhedstænkning skal udvikle sig fra periodisk inspektion til kontinuerlig oversigt. Begrebet om tillid er fuldstændigt brudt — du kan have tillidsfulde modeller og tillidsfulde MCP-servere, men på grund af AI’s ikke-deterministiske natur kan de stadig manipuleres eller blot opføre sig uventet for at skabe uventet risiko.

Prompting opstår som et nyt lag af programmerbarhed. Hvordan skal organisationer tilgå at sikre prompts og forhindre problemer som prompt-injektion, data-lækage eller manipulation?

Prompting former i stigende grad logik og adfærd. I mange tilfælde er de effektivt et nyt kontrolplan for softwareoprettelse. Det betyder, at de kræver politik, overvågning og guardrails ligesom koden eller infrastrukturbeskrivelser ville. Praktisk set begynder det med at begrænse, hvad prompts kan få adgang til, og hvilke nedstrøms-handlinger de kan udløse. Det betyder også at definere prompt-regler, der er i overensstemmelse med sikkerheds- og kvalitetsforventninger, forhindre følsomme data i at blive eksponeret gennem kontekstvinduer og overvåge forsøg på manipulation som prompt-injektion eller indirekte instruktions-hijacking. Og det inkluderer også at sikre, at reglerne i sig selv ikke bliver brugt som bagdøre til prompt-injektion. Det bredere punkt er, at du ikke sikrer prompting ved at instruere udviklere og agenter om at “være forsigtige”. Du sikrer det ved at indbygge kontroller i miljøet, hvor prompting faktisk sker.

MCP-servere og agent-færdigheder introducerer dynamiske forbindelser mellem systemer. Set fra et sikkerhedsperspektiv, repræsenterer de den største nye risikovektor i AI-dreven udvikling?

MCP-servere og agent-færdigheder repræsenterer et større nyt lag af risiko, fordi de definerer, hvordan AI-systemer forbinder til og interagerer med den virkelige verden. Færdigheder definerer, hvad en agent er bemyndiget til at gøre, mens MCP udvider dens adgang til kontekst og systemer. Sammen former de agentens faktiske adfærd. Hvis disse lag ikke er tæt kontrolleret, mister organisationer synlighed i, hvad deres AI-værktøjer er i stand til, og hvad de faktisk gør. Skiftet fra at generere kode til at udføre handlinger er, hvad der gør dette til et kritisk område for sikkerhed, og de bliver endnu mere uforudsigelige, når du kæder dem sammen.

En af dine kerne-temaer er “at være afdelingen for Ja” – at aktivere sikkerhed uden at bremse udviklere. Hvordan balancerer du realtidsbeskyttelse med udviklerhastighed i miljøer, hvor hastighed er kritisk?

Sikkerhed skaber friktion, når den sker sent eller er frakoblet fra, hvordan udviklere faktisk arbejder. Den bliver langt mere effektiv, når den er indbygget direkte i workflow og fokuserer på, hvad der virkelig betyder noget. Det har været en del af vores tænkning, siden Backslash begyndte, og det betyder endnu mere i AI-dreven udvikling.

I praksis betyder det, at man kun viser de få problemer, der repræsenterer rigtig risiko, og ikke oversvømmer udviklere med alt, der ser teoretisk mistænkeligt ud. Det betyder at gennemtvinge politik i IDE og agent-workflow, og ikke efterfølgende. Og det betyder at skabe gennemsigtige, deterministiske guardrails, så teams kan flytte hurtigt, mens de stadig ved, hvilke værktøjer der er i brug, hvilke tilladelser de har, og hvornår noget usædvanligt sker. Målet er ikke at bremse AI-adopteringshastighed, men at hjælpe organisationer med at adoptere det med tillid uden at miste kontrollen. I virkelige termer betyder det, at en udvikler vil have mindre mulighed for at begå fejl fra starten, men hvis de gør, så vil det blive fanget og håndteret hurtigt.

Vi ser ikke-tekniske brugere i stigende grad bygge software ved hjælp af AI-værktøjer. Hvordan ændrer opblomstringen af ikke-udvikler-vibe-udviklere trusselslandskabet?

Det udvider trusselslandskabet på to måder. Først udvider det dramatisk antallet af personer, der kan producere software-lignende output uden at forstå sikkerhedsimplikationerne. For det andet skaber det en falsk fornemmelse af sikkerhed, fordi værktøjerne gør udvikling til en konversations- og lav-frictionsoplevelse.

Det betyder, at organisationer vil se flere applikationer, automatiseringer og integrationer skabt af personer, der ikke er trænet til at overveje tillidsgrænser, input-validering, afhængighygiejne, adgangskontrol eller dataeksponering. Med andre ord udvider angrebsfladen sig ikke kun, fordi AI skriver mere kode, men fordi flere personer kan generere workflows og systemer, der opfører sig som software uden at anvende grundlæggende, hygiejnisk ingeniør-disciplin. Det gør synlighed og indbyggede sikkerhedsforanstaltninger endnu vigtigere, fordi man ikke længere kan antage sikkerhedsviden på skabelsestidspunktet.

Set fremad 12 til 24 måneder, hvilke typer af angreb eller sårbarheder forventer du at opstå specifikt på grund af AI-naturlig udviklingsworkflow?

Vi forventer, at mange af de almindelige kode-sårbarheder vil undgås fra starten gennem forbedringer i LLM’erne selv eller gennem bedre indbyggede prompt-regler i “harness”, der omgiver disse værktøjer. Hvis vi nu ser en stigning i antallet af sårbarheder på grund af øget hastighed, vil dette korrigere sig selv. Og hvad der ikke korrigeres, vil blive jaget af AI-aktiveret SAST og SCA (nogle af disse vil også blive leveret af AI-platformsleverandørerne, f.eks. Claude Code Security og projekt Glasswing).

Derimod forventer jeg værre udfald, når det kommer til eksponeringer på grund af brug af uvurderede og usupervisede AI-værktøjer i applikationsudvikling – såsom open-source-agenter (OpenClaw er et godt eksempel), der har meget dårlige sikkerhedsstandarder kombineret med en brugerbase, hvis viden om sikkerhed langt overgås af deres entusiasme for vibe-coding.

Som følge heraf tror jeg, at vi vil se en skiftning mod angreb, der rammer udviklingsøkosystemet selv snarere end kun produktions-systemer. Da AI bliver en del af, hvordan software skabes, vil angribere fokusere på at manipulere med værktøjerne og forbindelserne, der former processen, og effektivt kompromittere softwaren, før den nogensinde deployes.