David Mytton, CEO of Arcjet – Intervju-serie

David Mytton, grunnlegger og CEO av Arcjet, leder utviklerfokusert sikkerhetsstartup som hjelper team å innbygge robuste beskyttelser som bot-deteksjon, ratelimit, e-postvalidering, angrepsmitigering og dataredaksjon direkte i applikasjonskoden, etter å ha overtatt stillingen i juni 2023. Han har også medgrunnlagt Console, en godt fulgt devtools-nyhetsbrev og podcast, har hatt rådgivende roller som ekspert i Seedcamp, og tidligere drev produktutvikling i StackPath etter at hans skyovervåkingselskap ble kjøpt, samtidig som han har beholdt en sterk interesse for bærekraftig datadrift og aktiv skriving om tekniske emner.

Arcjet er bygget rundt en “sikkerhet-som-kode”-filosofi som lar utviklere sikre applikasjoner med enkle SDK-integreringer, og plasserer sikkerhetslogikk ved siden av forretningslogikk for lav-latens, kontekst-bevisste beslutninger og eliminerer behovet for separat infrastruktur; plattformen støtter beskyttelser som bot-blokkering, ratelimit og sensitiv datafiltrering og fortsetter å utvikle seg med funksjoner som en lokal AI-sikkerhetsmodell og utvidet rammestøtte, som reflekterer dens misjon om å gjøre in-kode-sikkerhet til standard for moderne apper. (fly.io)

Du grunnla Server Density på et tidspunkt da kjøring av infrastruktur i stor skala var langt mindre standardisert enn det er i dag, og til slutt vokste og solgte selskapet. Ser du tilbake, hva var de viktigste lærdommene du lærte om å bygge for utviklere og drive produksjonssystemer, og hvordan har den erfaringen formet måten du tenker om programvare i dag?

De fleste utviklerverktøy vinner demoen og taper produksjonen. Å få en utvikler til å installere noe nytt er vanskelig, så “rask start” må være friksjonsløs – men det er bare minimumskravene. Det virkelige feilmodusen er hva som skjer etter “det fungerer”: produktet blir begrenset, så alvorlige team blir raskt frustrerte og river det ut.

Det er derfor Arcjets in-kode-applikasjonssikkerhet er designet for to realiteter: du trenger en umiddelbar løsning for oppmeldingsspill, konto-svindel, bot-angrep, API-misbruk osv., og du trenger også en fluktåpning til avanserte kontroller – per-bruker-kvoter, risikobaserte regler og kontekst-bevisste beslutninger – uten å måtte skrive om alt.

Produktet er ikke brukergrensesnittet. Produktet er kjøretidens atferd, kanttilfeller, eksempler og referansedokumenter som utviklere kan stole på.

Kommer ut av den erfaringen, hva ledet deg til å starte Arcjet, og hvorfor følte du at den neste store skiftet i applikasjonssikkerhet måtte skje inne i koden selv og ikke på nettverks- eller infrastrukturnivå?

Perimetersikkerhet optimaliserer det feil thing. Utviklere bygger og sender i kode, ikke i dashboards – og AI-kodeagenter kommer ikke til å “klikke rundt” i en sikkerhets-kontroll til å beskytte en app.

Hvis ditt vern ikke kan uttrykkes som kode, gjennomgås i en pull-forespørsel, testes i CI og deployes sammen med applikasjonen, er det ikke “utvikler-først-sikkerhet”.

Arcjet eksisterer fordi sikkerhet hører hjemme i applikasjonslaget: versjonskontrollert, testbar, observerbar og nær forretningslogikken hvor intensjonen faktisk bor.

Arcjet innbygger AI-drevet trussel-deteksjon direkte i applikasjonsforespørsler. Fra et teknisk perspektiv, hva fordeler har denne lokale, in-kode-tilnærmingen sammenlignet med tradisjonelle perimetersikkerhetsverktøy?

Inne i en forespørselsbehandler har du identitet, sesjonstilstand, kjøpehistorikk, kontoalder, funksjonsflagg og database-sannhet. Du kan ta en beslutning som: “Dette ser merkelig ut, men det er en lojal kunde – øk verifisering i stedet for blokkering.” Et nettverksproxy kan ikke gjøre det fordi det ikke har noen aning om hva en “kunde” er.

Målet er ikke maksimal blokkering. Målet er å minimere feilpositive med kontekst-bevisste sikkerhet fordi den dyreste sikkerhetsfeilen er å blokkere en gyldig betaling eller låse ut en ekte bruker.

AI har dramatisk endret økonomien for misbruk, fra bot-skrapping og spam-oppmelding til automatisert API-utnyttelse. Hva slags angrep ser du oftest i produksjon i dag, og hvordan utvikler de seg når angripere adopterer mer avanserte AI-systemer?

AI sin produktivitetsgevinst hjelper angripere også! Den store skiftet er volum og iterasjonshastighet: mer legitimasjonstetting, mer automatisert oppmeldingsspill, mer bot-skrapping, mer API-sondering og raskere “våpenisering” av ferske sårbarheter.

Vi ser også at angripere kjører tette tilbakemeldingsløkker: de tester forsvar, tilpasser prompter og nyttelaster, roterer infrastruktur og fortsetter til de kommer inn. Det er for tiden alt om hastighet i stedet for sofistikert.

Det er fortsatt for få mennesker som følger beste praksis som å bruke en passordbehandler, deployere 2-faktorautentisering med fiske-resistente legitimasjoner som passnøkler eller maskin-nøkler og holde avhengigheter oppdatert. Med økende angrepsvolum vil det bli viktigere og viktigere.

En av de største spenningene i sikkerhet er å beskytte applikasjoner uten å sakke utvikling. Hvordan har team som bruker Arcjet kunnet integrere sikkerhet i sine arbeidsflyter samtidig som de opprettholder raske utgivelser?

Arcjet kjører i enhver miljø, inkludert i kode-miljøet på en laptop. Det betyr at utviklere kan teste det ut uten å måtte deploye til produksjon. Dette er en betydelig fordel fordi du kan validere det og demonstrere integreringen uten å måtte ha spesielle tillatelser og uten å risikere å påvirke produksjonen. Dette løser det klassiske problemet med at sikkerhetsteam tvinger utviklere til å adoptere verktøy som hemmer deres evne til å gjøre jobben.

Arcjet har fått tidlig grep med AI-naturlige produkter og e-handelsplattformer. Hva gjør disse miljøene spesielt sårbare for moderne automatiserte angrep, og hvorfor tendrer legacy-forsvar til å svikte?

Disse to kategoriene deler en likhet hvor hver misbruk-forespørsel har en direkte kostnad.

AI-produkter betaler for token og inferens – angripere gjør om din margin til deres lekeplass via skrapping, automatisering og gratis-nivå-utnyttelse. E-handel betaler for svindel, chargebacks, varemisbruk og konto- overtakelse. Og begge er hypersensitive for feilpositive fordi blokkering av ekte brukere er direkte inntekts-tap.

Legacy-forsvar beskytter hovedsakelig båndbredde og infrastruktur. Moderne angripere målretter forretningslogikk: oppmeldingsflyter, betalingsflyter, promo-logikk, konto-gjenoppretting og API-endepunkter. Det er derfor generiske perimetersikkerhetskontroller og “løs det med en CAPTCHA” i økende grad svikter.

Bygging av sikkerhetsprogramvare kommer med helt andre avveininger enn overvåkning eller overvåking. Hva overrasket deg mest om å utvikle et sikkerhetsprodukt sammenlignet med din tidligere erfaring med infrastruktur-verktøy?

Med overvåkning stoler kundene på at du er tilgjengelig. Med sikkerhet stoler kundene på at du er trygg og ikke blir deres nyeste forsyningskjede-utnyttelse.

Bygging av et sikkerhetsprodukt betyr å kjøre et sikkerhets-selskap. Vi bruker rammer som SOC 2, minimiserer våre tredjeparts-avhengigheter og behandler utvikler-laptoper og tilgang til verktøy som produksjons-aktiva. Dette betyr mye overvåking og raske reaksjoner på potensielle problemer.

Som applikasjoner i økende grad avhenger av AI-agenter som handler på vegne av brukere, hvordan bør utviklere tenke om identitet, intensjon og tillit på applikasjonsnivå?

Når AI-agenter handler for brukere, stopper identitet å være en binær innloggings-tilstand og blir en delegasjons-problem: hvem handler, på hvis vegne, med hva tillatelser, i hvor lenge og med hva begrensninger.

Utviklere bør skifte til kontinuerlig verifisering: behandle hver forespørsel som om den trenger en fersk tillits-beslutning basert på kontekst – bruker-historikk, enhetssignaler, sesjons-atferd og handling-risiko. “Intensjon” er innferert fra atferd over tid, ikke hevdet i header.

Dette betyr å bygge opp økende øyeblikk (verifisering, ratelimit, friksjon) rundt høyrisiko-handlinger som passord-tilbakestill, betaling og token-oppasjon – og gjøre at disse kontrollene bor i koden, hvor applikasjonen kan skille en lojal kunde fra en bot med en stjålet cookie.

Ser du fremover, hvordan ser du på rollen til in-kode, kontekst-bevisste sikkerhet utvikler seg over de neste årene mens AI-generert trafikk fortsetter å vokse?

Perimetersikkerhetsverktøy vil ikke forsvinne – men de vil være det grove filteret for ting som best håndteres på nettverksnivå som DDoS-angrep. De presise beslutningene vil skje inne i appen, ved å bruke ekte kontekst.

Hvis innbygd sikkerhet blir standardmodellen for moderne applikasjoner, hva betyr denne skiftet for hvordan utviklere tester, deployer og tenker om sikkerhet i produksjonssystemer?

Hvis innbygd sikkerhet blir standard, vil team test misbruk på samme måte som de tester riktighet: sikkerhets-enhetstester, replayable angreps-simulatorer og CI-sjekker for risikable endepunkter.

Den større skiftet er at AI-kodeagenter vil implementere sikkerhet som kode, ikke som dashboard-konfigurasjon. Agenter kan bare pålitelig foreslå, gjennomgå og validere beskyttelser når kontrollene bor i repo: politikker, regler, tester og instrumentering. Hvis “sikkerhetslaget” er et web-grensesnitt, kan agenten ikke teste endringene for å sende trygt.

Det er den virkelige grunnen til at “sikkerhet i kode” vinner – det passer hvordan moderne programvare (og moderne AI-assistert utvikling) faktisk bygges.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Arcjet.