Shahar Man, medstifter og administrerende direktør for Backslash Security – Intervju-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, beskytte alt fra IDE’er og AI-agenter til genereret kode og prompt-workflows. Før dette havde han ledende roller i Aqua Security, hvor han fungerede som både vicepræsident for produktledelse og vicepræsident for forskning og udvikling, og hjalp med at opbygge en af de førende platforme for container-sikkerhed på tværs af udviklingslivscyklussen. Tidligere i sin karriere tilbragte Man 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 roller i både startup-miljøer og Israels forsvarsteknologienheder, hvilket gav ham en stærk grundlag i både ingeniørarbejde og storstilede systemer.

Backslash Security er en opkomment cybersikkerhedsplatform, der er specialdesigned 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 mod at imødekomme 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 designet 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 roller 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 grundlæggende ændre softwareoprettelse, og at sikkerhed skulle genopbygges for at støtte det?

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

Sikring af kode er nu mindre om kodens selv og mere om miljøet omkring den. På under et år er det, der tidligere var et relativt indhegnet og lavrisikoudviklingsopsætning, udvidet til et spredt, højtilsluttet 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 selv. Sikkerhed kan ikke længere fokusere kun på kodens output. Den må tage hele miljøet, der gør koden mulig, med i betragtning.

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 hold 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, der leveres til modellen, i tilladelserne, der gives til agenter, 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 overtages og bruges som brohovedet for en bredere angreb. Det er et endpoint-problem, der masquerer som et AI-kodningsproblem. Til forskel fra kodevulnerabiliteter sætter dette ikke kun applikationer, men hele organisationer, på spil. Hvis du kun kigger på koden, så har du overset det meste af billedet.

Traditionel applikationsikkerhed har fokuseret tungt på kodegennemgang. Hvordan skal sikkerhedstænkning udvikle sig, når AI-agenter genererer, ændrer og distribuerer 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 og skabe uventet risiko.

Dette betyder også, at der skal ske en holdningsændring, hvor sikkerhed opererer sideløbende med udviklingsprocessen, mens den sker, og har langt dybere styring, vejledning, beskyttelse og detektion og responsfunktioner inden for det miljø. Det betyder at 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 sikkerhedsgab, når hold 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. Sikkerhedshold kender ofte ikke til, 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 princip, blot hurtigere og mere dynamisk.

Det næststørste gab er manglen på gennemførbare politikker. De fleste organisationer kan have 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 hold at have over-tilståede værktøjer, der ikke møder virksomhedsstandarder. Disse værktøjer er ikke i sig selv dårlige, men at adoptere dem uden styring betyder, at du effektivt skalerer udviklingshastighed uden at skale kontrol.

En tredje opkomment 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 enormt 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ænt inde i et enkelt produkt i din stak. AI-naturlig udvikling er i sig selv et økosystem-problem, fordi den opererer på så mange forskellige steder og bruger så mange forskellige værktøjer. IDE’en, modellen, agenten, MCP-serveren, de eksterne plugins, identiteterne og de forbundne datakilder alle påvirker, hvad der bygges, og hvordan. Organisationer standardiserer bevidst ikke på et enkelt værktøj, fordi deres relative styrker skifter så hurtigt. Hvis du sikrer kun ét punkt i den kæde, så har du stadig overset, hvordan risiko bevæger sig over systemet.

Prompting opstår som et nyt lag af programmerbarhed. Hvordan skal organisationer nærme sig sikring af prompts og forebygge problemer som prompt-injektion, data-lækage eller manipulation?

Prompt’er 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 vejledning ligesom kode eller infrastrukturdefinitioner ville. I praksis begynder det med at begrænse, hvad prompts kan få adgang til, og hvad 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, såsom prompt-injektion eller indirekte instruktions-hijacking. Og det inkluderer også at sikre, at reglerne selv ikke bruges 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 mest betydningsfulde 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 overblik over, hvad deres AI-værktøjer kan og 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 det bliver endnu mere uforudsigeligt, når du kæder dem sammen.

En af dine centrale 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 afkoblet 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 startede, og det betyder endnu mere i AI-dreven udvikling.

I praksis betyder det at fremhæve de få problemer, der repræsenterer reel risiko, og ikke oversvømme udviklere med alt, der ser teoretisk mistænkeligt ud. Det betyder at gennemtvinge politik i IDE og agent-workflow, ikke efterfølgende. Og det betyder at skabe gennemsigtige, deterministiske vejledning, så hold kan bevæge sig hurtigt, mens de stadig ved, hvilke værktøjer der er i brug, hvilke tilladelser de har, og nå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 kontrol. I virkelige termer betyder det, at en udvikler har 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 opkomsten 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 lavfrictionsoplevelse.

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ængighedshygiejne, adgangskontrol eller dataeksponering. Med andre ord udvider angrebsfladen 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ørpraksis. Det gør synlighed og indbyggede sikkerhedsforanstaltninger endnu vigtigere, fordi du ikke længere kan antage sikkerhedsviden på skabelsestidspunktet.

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

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”-værktøjet, 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).

Men jeg forventer værre udfald, når det kommer til eksponeringer på grund af brugen af ugodkendte 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, 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 værktøjerne og forbindelserne, der former processen, og effektivt kompromittere software, før det nogensinde er deployet.

Tak for det fantastiske interview. Læsere, der ønsker at lære mere, kan besøge Backslash Security.