David Mytton, VD för Arcjet – Intervjuserie

David Mytton, grundare och VD för Arcjet, leder den utvecklarspecifika säkerhetsstartuppen som hjälper team att integrera robusta skydd som botdetektering, ratelimitering, e-postverifiering, attackmitigation och dataredigering direkt i applikationskoden, efter att ha tagit över i juni 2023. Han har också medgrundat Console, en väl följd devtools-nyhetsbrev och podcast, har haft rådgivande roller som Expert in Residence på Seedcamp och tidigare lett produktutveckling på StackPath efter att hans molnövervakningsföretag förvärvades, samtidigt som han har ett starkt intresse för hållbar datorkraft och aktivt skriver om teknikämnen.

Arcjet byggs kring en “säkerhet-i-kod”-filosofi som låter utvecklare skydda applikationer med enkla SDK-integrationer, placerar säkerhetslogik bredvid affärslogik för låglatens, kontextmedvetna beslut och eliminerar behovet av separat infrastruktur; plattformen stöder skydd som botblockering, ratelimit och känslig datafiltrering och fortsätter att utvecklas med funktioner som en lokal AI-säkerhetsmodell och utökat ramverksstöd, vilket speglar dess mission att göra in-kod-säkerhet standarden för moderna appar. (fly.io)

Du grundade Server Density när det var mycket mindre standardiserat att köra infrastruktur i stor skala än det är idag, och till slut växte och sålde företaget. När du ser tillbaka, vad var de viktigaste lärdomarna du lärde dig om att bygga för utvecklare och driva produktionsystem, och hur formade den erfarenheten hur du tänker om programvara idag?

De flesta utvecklarverktyg vinner demon och förlorar produktion. Att få en utvecklare att installera något nytt är svårt, så “snabbstart” måste vara friktionsfritt – men det är bara en grundförutsättning. Det verkliga felmodusen är vad som händer efter “det fungerar”: produkten blir begränsad så allvarliga team blir snabbt frustrerade och river ut den.

Det är därför Arcjets in-kod-applikationssäkerhet är utformad för två verkligheter: du behöver en omedelbar lösning för registrerings-spam, kontofusk, botattacker, API-missbruk etc, och du behöver också en nödutgång till avancerade kontroller – per-användar-kvoter, riskbaserade regler och kontextmedvetna beslut – utan att skriva om allt.

Produkten är inte användargränssnittet. Produkten är körningsbeteendet, kanterna, exemplen och referensdokumentationen som utvecklare kan lita på.

Kommande ut ur den erfarenheten, vad ledde dig att starta Arcjet, och varför kände du att den nästa stora förändringen i applikationssäkerhet behövde hända inuti koden själv snarare än på nätverks- eller infrastrukturlagret?

Perimetersäkerhet är att optimera fel saken. Utvecklare bygger och skickar i kod, inte i instrumentpaneler – och AI-kodningsagenter kommer inte “klicka runt” ett säkerhetskontroll för att skydda en app.

Om ditt skydd inte kan uttryckas som kod, granskas i en pull-begäran, testas i CI och distribueras tillsammans med applikationen, är det inte “utvecklarspecifik säkerhet”.

Arcjet existerar eftersom säkerhet tillhör applikationslagret: versionskontrollerat, testbart, observerbart och nära affärslogiken där avsikten faktiskt bor.

Arcjet integrerar AI-drivna hotdetektering direkt i applikationsbegärandehanterare. Från ett tekniskt perspektiv, vilka fördelar ger denna lokala, in-kod-approach jämfört med traditionella perimetersäkerhetsverktyg?

Inuti en begäranhanterare har du identitet, sessionsstatus, inköpshistorik, kontålder, funktionsflaggor och databasens sanning. Du kan fatta ett beslut som: “Detta ser konstigt ut, men det är en lojal kund – öka verifieringen istället för att blockera.” En nätverksproxy kan inte göra det eftersom den inte har någon aning om vad en “kund” är.

Målet är inte maximal blockering. Målet är att minimera falska positiva med kontextmedveten säkerhet eftersom den dyraste säkerhetsmisstaget är att blockera en legitim checkout eller låsa ut en riktig användare.

AI har dramatiskt förändrat ekonomin för missbruk, från bot-skrapning och spamsignup till automatiserad API-utnyttjande. Vilka typer av attacker ser du oftast i produktion idag, och hur utvecklas de när angripare antar mer avancerade AI-system?

AI:s produktivitetsvinster hjälper angripare också! Den stora förändringen är volym och iterationshastighet: mer lösenordsfyllning, mer automatiserad spamsignup, mer bot-skrapning, mer API-sondering och snabbare “vapenlisering” av färska sårbarheter.

Vi ser också att angripare kör tätare återkopplingsloopar: de testar försvar, anpassar prompter och nyttolaster, roterar infrastruktur och fortsätter tills de kommer in. Det handlar för närvarande om hastighet snarare än sofistikation.

Det finns fortfarande för få människor som följer bästa praxis som att använda en lösenordschef, distribuera 2-faktorsautentisering med phish-resistenta autentiseringsuppgifter som passnycklar eller hårdvarunycklar och hålla beroenden uppdaterade. Med ökande attackvolymer kommer det att bli allt viktigare.

En av de största spänningarna i säkerhet är att skydda applikationer utan att sakta ner utvecklingen. Hur har team som använder Arcjet kunnat integrera säkerhet i sina arbetsflöden samtidigt som de upprätthåller snabba utgivningscykler?

Arcjet körs i vilken miljö som helst, inklusive i utvecklingsmiljön på en laptop. Det betyder att utvecklare kan testa det utan att ens distribuera till produktion. Det är en betydande fördel eftersom de kan validera det och demonstrera integrationen utan att behöva särskilda behörigheter och utan risk för att påverka produktion. Det löser det klassiska problemet med att säkerhetsteam tvingar utvecklare att anta verktyg som försämrar deras förmåga att göra sitt jobb.

Arcjet har fått tidig dragkraft med AI-nativa produkter och e-handelsplattformar. Vad gör dessa miljöer särskilt sårbara för moderna automatiserade attacker, och varför tenderar äldre försvar att misslyckas?

Dessa två kategorier delar en likhet där varje missbrukad begäran har en direkt kostnad.

AI-produkter betalar för token och inferens – angripare förvandlar din marginal till deras lekplats via skrapning, automatisering och gratisnivå-odling. E-handel betalar för bedrägeri, återbetalningar, varumissbruk och kontotillägnelse. Och båda är hypersensitiva för falska positiva eftersom blockering av riktiga användare är direkt förlust av intäkter.

Äldre försvar skyddar främst bandbredd och infrastruktur. Moderna angripare riktar sig mot affärslogik: registreringsflöden, köpflöden, kampanjlogik, kontoåterställning och API-slutpunkter. Det är därför generiska perimeterskydd och “lös det med en CAPTCHA” alltmer misslyckas.

Att bygga säkerhetsprogramvara kommer med mycket olika avvägningar än observabilitet eller övervakning. Vad överraskade dig mest om att utveckla ett säkerhetsprodukt jämfört med din tidigare erfarenhet av infrastrukturverktyg?

Med observabilitet litar kunderna på att du är tillgänglig. Med säkerhet litar kunderna på att du är säker och inte blir deras nya leverantörsexploatering.

Att bygga ett säkerhetsprodukt innebär att driva ett säkerhetsföretag. Vi använder ramverk som SOC 2, minimerar våra tredjepartsberoenden och behandlar utvecklarnas laptops och åtkomst till verktyg som produktionsresurser. Det innebär en hel del övervakning och snabba reaktioner på potentiella problem.

När applikationer alltmer förlitar sig på AI-agenter som agerar på användarnas vägnar, hur bör utvecklare ompröva idéer som identitet, avsikt och förtroende på applikationslagret?

När AI-agenter agerar för användare slutar identitet vara en binär inloggningstillstånd och blir ett delegeringsproblem: vem agerar, på vars vägnar, med vilka behörigheter, hur länge och med vilka begränsningar.

Utvecklare bör skifta till kontinuerlig verifiering: behandla varje begäran som kräver ett färskt förtroendebeslut baserat på kontext – användarhistorik, enhetssignaler, sessionsbeteende och åtgärdsrisk. “Avsikt” är härledd från beteende över tid, inte påstådd i rubriker.

Det betyder att bygga stegvisa ögonblick (verifiering, ratelimit, friktion) runt högriskåtgärder som lösenordsåterställning, köp och token-skapande – och göra att dessa kontroller bor i koden, där applikationen kan skilja en lojal kund från en bot med en stulen cookie.

Om man ser framåt, hur ser du på den roll som in-kod, kontextmedveten säkerhet kommer att utvecklas under de närmaste åren när AI-genererad trafik fortsätter att växa?

Perimeterverktyg kommer inte att försvinna – men de kommer att vara det grova filtret för saker som hanteras bäst på nätverksnivå som DDoS-attacker. De precisa besluten kommer att ske inuti appen, med riktigt sammanhang.

Om inbäddad säkerhet blir den standardmodellen för moderna applikationer, vad betyder den förändringen för hur utvecklare testar, distribuerar och resonerar om säkerhet i produktionsystem?

Om inbäddad säkerhet blir standard, kommer team att testa missbruk på samma sätt som de testar korrekthet: säkerhetsenhetstester, återuppspelbara attack-simulationer och CI-kontroller för riskfyllda slutpunkter.

Den större förändringen är att AI-kodningsagenter kommer att implementera säkerhet som kod, inte som instrumentpanelskonfiguration. Agenter kan bara pålitligt föreslå, granska och validera skydd när kontrollerna bor i repot: principer, regler, tester och instrumentering. Om “säkerhetslagret” är ett webbgränssnitt kan agenten inte testa ändringarna för att leverera säkert.

Det är den riktiga anledningen till att “säkerhet i kod” vinner – det passar hur modern programvara (och modern AI-assisterad utveckling) faktiskt byggs.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Arcjet.