David Mytton, VD för Arcjet – Intervjuserie

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

Arcjet är byggt kring en “säkerhet-som-kod”-filosofi som låter utvecklare säkra 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 uppdrag att göra in-kod-säkerhet till standard för moderna appar. (fly.io)

Du grundade Server Density när att köra infrastruktur i stor skala var långt mindre standardiserat ä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å “snabb start” måste vara friktionsfri – men det är bara en grundförutsättning. Det riktiga felmodusen är vad som händer efter “det fungerar”: produkten blir begränsad så att allvarliga team snabbt blir 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 teckenspam, kontofusk, botattacker, API-missbruk etc, och du behöver också en flyktväg 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 referensdokumenten som utvecklare kan lita på.

Kommande från 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 saker. Utvecklare bygger och skickar i kod, inte i instrumentpaneler – och AI-kodningsagenter kommer inte att “klicka runt” i en säkerhetsinstrumentpanel 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 “utvecklar-först-säkerhet”.

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

Arcjet införlivar AI-drivna hotdetektering direkt i applikationsbegäranhanterare. 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, sessionsstat, köphistorik, kontotid, funktionflags och databasens sanning. Du kan fatta ett beslut som: “Detta ser konstigt ut, men det är en lojal kund – steg upp verifiering istället för blockering.” 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äkerhetsmisstag är att blockera en legitim check-out eller låsa ut en riktig användare.

AI har dramatiskt förändrat ekonomin för missbruk, från bot-skrapning och spam-tecken 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 också angripare! Den stora förändringen är volym och iterationshastighet: mer credential-stuffing, mer automatiserad signup-spam, mer bot-skrapning, mer API-sondering och snabbare “vapenlisering” av färska sårbarheter.

Vi ser också att angripare kör tajtare återkopplingsloopar: de testar försvar, anpassar prompted och laster, 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ösenordshanterare, 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 alla miljöer, inklusive i kodningsmiljön på en laptop. Det betyder att utvecklare kan testa det utan att ens distribuera till produktion. Detta är en betydande fördel eftersom du kan validera det och demonstrera integrationen utan att behöva specialtillstånd 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 utföra sitt arbete.

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 vara otillräckliga?

Dessa två kategorier delar en likhet där varje missbrukande 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 gratis-nivå-odling. E-handel betalar för bedrägeri, återbetalningar, lagermissbruk och kontotillägnelse. Och båda är hypersensitiva för falska positiva eftersom blockering av riktiga användare är bokstavligen inkomstförlust.

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

Att bygga säkerhetsprogramvara kommer med mycket olika avvägningar än observabilitet eller övervakning. Vad överraskade dig mest om att utveckla en 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örsangrepp.

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

Som applikationer alltmer förlitar sig på AI-agenter som agerar på användarnas vägnar, hur bör utvecklare omdefiniera 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 inloggningsstatus 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 behöver ett färskt förtroendebeslut baserat på kontext – användarhistorik, enhetssignaler, sessionsbeteende och åtgärdsrisk. “Avsikt” är infererad från beteende över tid, inte påstådd i rubriker.

Det betyder att bygga stegupp-moment (verifiering, ratelimit, friktion) runt högriskåtgärder som lösenordsåterställning, check-out och token-skapande – och göra att dessa kontroller borde 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å rollen för in-kod, kontextmedveten säkerhet 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 bäst hanteras på nätverksnivå som DDoS-attacker. De precisa besluten kommer att ske inuti appen, med riktiga sammanhang.

Om inbäddad säkerhet blir 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 föreslå, granska och validera skydd när kontrollerna bor i repo: principer, regler, tester och instrumentering. Om “säkerhetslagret” är en 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 utmärkta intervjun, läsare som vill lära sig mer bör besöka Arcjet.