David Mytton, administrerende direktør for Arcjet – Intervju-serie

David Mytton, grundlægger og administrerende direktør for Arcjet, leder det udviklerfokuserede sikkerhedsstartup, der hjælper hold med at integrere robuste beskyttelser som bot-detektion, rate-begrænsning, e-mail-validering, angrebs-mildning og data-redaktion direkte i applikationskoden, efter at have overtaget posten i juni 2023. Han har også co-grundlagt Console, en velkendt devtools-nyhedsbrev og podcast, har fungeret i rådgivende roller som f.eks. Ekspert i Seedcamp, og tidligere ledede produkt-ingeniørerne i StackPath efter, at hans cloud-overvågningsvirksomhed var blevet købt, mens han fastholdt en stærk interesse for bæredygtig computing og aktivt skriver om tekniske emner.

Arcjet er bygget op omkring en “sikkerhed-i-kode”-filosofi, der giver udviklere mulighed for at sikre applikationer med simple SDK-integrationer, hvilket placerer sikkerhedslogik sammen med forretningslogik for lav-forsinkelses-, kontekst-bevidste beslutninger og eliminerer behovet for separat infrastruktur; platformen understøtter beskyttelser som f.eks. bot-blokering, rate-grænser og følsomme data-filtrering og fortsætter med at udvikle funktioner som f.eks. en lokal AI-sikkerhedsmodel og udvidet ramme-understøttelse, hvilket afspejler dens mission om at gøre in-kode-sikkerhed til standarden for moderne apps. (fly.io)

Du grundlagde Server Density på et tidspunkt, hvor kørsel af infrastruktur i stor skala var langt mindre standardiseret, end det er i dag, og voksede og solgte virksomheden. Kigging tilbage, hvad var de vigtigste lærdomme, du lærte om at bygge til udviklere og operere produktions-systemer, og hvordan formede den oplevelse din måde at tænke om software i dag?

De fleste udvikler-værktøjer vinder demoen og taber i produktion. At få en udvikler til at installere noget nyt er svært, så “hurtig start” skal være fri for friktion – men det er bare minimumskravene. Det virkelige fejl-mode er, hvad der sker efter “det virker”: produktet bliver begrænset, så alvorlige hold bliver hurtigt frustrerede og river det ud.

Derfor er Arcjets in-kode-applikations-sikkerhed designed til to realiteter: du har brug for en øjeblikkelig løsning til tilmeldings-spam, konto-svindel, bot-angreb, API-misbrug osv., og du har også brug for en undvigelsesmulighed til avancerede kontroller – per-bruger-kvoter, risiko-baserede regler og kontekst-bevidste beslutninger – uden at skulle omskrive alt.

Produktet er ikke brugergrænsefladen. Produktet er runtime-opførslen, kant-tilfælde, eksempler og reference-dokumenter, som udviklere kan stole på.

Kommenterne fra den oplevelse, hvad førte dig til at starte Arcjet, og hvorfor følte du, at den næste store ændring i applikations-sikkerhed skulle ske inde i koden selv og ikke på netværks- eller infrastruktur-niveau?

Perimeter-sikkerhed optimerer det forkerte. Udviklere bygger og sender i kode, ikke i dashboards – og AI-kodnings-agenter vil ikke “klikke rundt” i en sikkerheds-konsol for at beskytte en app.

Hvis din beskyttelse ikke kan udtrykkes som kode, gennemgås i en pull-anmodning, testes i CI og deployes sammen med applikationen, er det ikke “udvikler-først-sikkerhed”.

Arcjet eksisterer, fordi sikkerhed hører hjemme i applikations-laget: version-kontrolleret, testbart, observerbart og tæt på forretnings-logikken, hvor intentionen faktisk bor.

Arcjet integrerer AI-drevet trussels-detektion direkte i applikations-anmodnings-håndterere. Fra et teknisk synspunkt, hvad er fordelene ved denne lokale, in-kode-tilgang sammenlignet med traditionelle perimeter-baserede sikkerhedsværktøjer?

Inde i en anmodnings-håndterer har du identitet, session-tilstand, købs-historik, konto-alder, funktion-flags, database-sandhed. Du kan træffe en beslutning som: “Dette ser underligt ud, men det er en loyal kunde – trin op validering i stedet for at blokere.” En netværks-proxy kan ikke gøre det, fordi den ikke har nogen idé om, hvad en “kunde” er.

Målet er ikke maksimal blokering. Målet er at minimere falske positiver med kontekst-bevidst sikkerhed, fordi den dyreste sikkerheds-fejl er at blokere en gyldig checkout eller låse en rigtig bruger ud.

AI har dramatisk ændret økonomien for misbrug, fra bot-scraping og spam-tilmeldinger til automatiseret API-udnyttelse. Hvad slags angreb ser du oftest i produktion i dag, og hvordan udvikler de sig, når angribere adopterer mere avancerede AI-systemer?

AI’s produktivitets-gevinster hjælper angribere også! Den store ændring er volumen og iterations-hastighed: mere credential-stuffing, mere automatiseret spam-tilmelding, mere bot-scraping, mere API-afprøvning og hurtigere “våbenisering” af friske sårbarheder.

Vi ser også, at angribere kører tættere feedback-løkker: de tester forsvar, tilpasner prompts og payloads, roterer infrastruktur og bliver ved, indtil de kommer ind. Det handler i øjeblikket mere om hastighed end om sofistikation.

Der er stadig for få mennesker, der følger bedste praksis som at bruge en adgangskode-manager, deployere 2-faktor-autentificering med phish-resistente legitimationer som f.eks. passkeys eller hardware-nøgler og holde afhængigheder opdateret. Med øgende angrebs-volumen vil det blive mere og mere vigtigt.

En af de største spændinger i sikkerhed er at beskytte applikationer uden at sænke udviklingstempo. Hvordan har hold, der bruger Arcjet, kunnet integrere sikkerhed i deres arbejdsprocesser, mens de fastholder hurtige udgivelses-cykler?

Arcjet kører i enhver miljø, herunder i kodnings-miljøet på en laptop. Det betyder, at udviklere kan teste det ud uden at skulle installere det i produktion. Dette er en betydelig fordel, fordi de kan validerer og demonstrere integrationen uden at skulle have særlige tilladelser og uden at risikere at påvirke produktion. Dette løser det klassiske problem med sikkerheds-hold, der tvinger udviklere til at adoptere værktøjer, der forringrer deres evne til at gøre deres arbejde.

Arcjet har opnået tidlig traction med AI-native produkter og e-commerce-platforme. Hvad gør disse miljøer særligt sårbare over for moderne automatiserede angreb, og hvorfor tenderer legacy-forsvar til at svigte?

Disse to kategorier deler en lighed, hvor hver misbrugs-anmodning har en direkte omkostning.

AI-produkter betaler for tokens og inference – angribere omdanner din margin til deres legeplads via scraping, automation og free-tier-landbrug. E-commerce betaler for svindel, chargebacks, varemisbrug og konto-overtagelse. Og begge er over-sensitiv over for falske positiver, fordi blokering af rigtige brugere er lig med indtægts-tab.

Legacy-forsvar beskytter primært båndbredde og infrastruktur. Moderne angribere målretter forretnings-logik: tilmeldings-flows, checkout-flows, promo-logik, konto-genoprettelse og API-endpoints. Det er derfor, generiske perimeter-kontroller og “løs det med en CAPTCHA” i stigende grad svigter.

At bygge sikkerheds-software kommer med meget forskellige kompromiser end overvågning eller monitoring. Hvad overraskede dig mest om udvikling af et sikkerheds-produkt sammenlignet med din tidligere erfaring med infrastruktur-værktøjer?

Med overvågning stoler kunderne på, at du er tilgængelig. Med sikkerhed stoler kunderne på, at du er sikker og ikke bliver deres nyeste supply-chain-udnyttelse.

At bygge et sikkerheds-produkt betyder at køre et sikkerheds-firma. Vi bruger rammer som f.eks. SOC 2, minimere vores tredjeparts-afhængigheder og behandle udvikler-laptops og adgang til værktøjer som produktions-aktiver. Dette betyder en masse overvågning og hurtige reaktioner på potentielle problemer.

Som applikationer i stigende grad afhænger af AI-agenter, der handler på vegne af brugere, hvordan bør udviklere omforme idéer som identitet, intention og tillid på applikations-laget?

Når AI-agenter handler for brugere, stopper identitet med at være en binær login-tilstand og bliver et delegerings-problem: hvem handler, på hvis vegne, med hvilke tilladelser, i hvor lang tid og med hvilke begrænsninger.

Udviklere bør skifte til kontinuerlig validering: behandle hver anmodning som krævende en frisk tillids-beslutning baseret på kontekst – bruger-historik, enhedssignaler, session-adfærd og handling-risiko. “Intention” er underforstået fra adfærd over tid, ikke krævet i headers.

Dette betyder at bygge trin-op-øjeblikke (validering, rate-grænser, friktion) omkring høj-risiko-handlinger som f.eks. adgangskode-genoprettelse, checkout og token-tilblivelse – og gøre, at disse kontroller bor i-koden, hvor applikationen kan skelne mellem en loyal kunde og en bot med en stjålet cookie.

Kigging fremad, hvordan ser du på udviklingen af in-kode, kontekst-bevidst sikkerhed over de næste par år, mens AI-genereret trafik fortsætter med at vokse?

Perimeter-værktøjer forsvinder ikke – men de bliver det grove filter for ting, der bedst håndteres på netværks-niveau som f.eks. DDoS-angreb. De præcise beslutninger vil ske inde i appen, ved hjælp af rigtig kontekst.

Hvis indbygget sikkerhed bliver den standard-model for moderne applikationer, hvad betyder denne ændring for, hvordan udviklere tester, deployer og tænker om sikkerhed i produktions-systemer?

Hvis indbygget sikkerhed bliver standard, vil hold teste misbrug på samme måde, som de tester korrekthed: sikkerheds-unit-tests, replayable angrebs-simulationer og CI-checks for risikable endpoints.

Den større ændring er, at AI-kodnings-agenter vil implementere sikkerhed som kode, ikke som dashboard-konfiguration. Agenter kan kun pålideligt foreslå, gennemgå og validerer beskyttelser, når kontrollerne bor i repoet: politikker, regler, tests og instrumentation. Hvis “sikkerheds-laget” er en web-brugergrænseflade, kan agenten ikke teste ændringerne for at sende dem sikkert.

Det er den rigtige grund til, at “sikkerhed-i-kode” vinder – det passer til, hvordan moderne software (og moderne AI-assisteret udvikling) faktisk bliver bygget.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Arcjet.