David Mytton, CEO av 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, angrepsreduksjon 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 ledet 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, plasserer sikkerhetslogikk ved siden av forretningslogikk for lav-forsinkelses-, kontekst-bevisste beslutninger og eliminerer behovet for separate infrastruktur; plattformen støtter beskyttelser som bot-blokkering, ratelimit og følsomme datafiltrering og fortsetter å utvikle seg med funksjoner som en lokal AI-sikkerhetsmodell og utvidet rammestøtte, som reflekterer dens misjon om å gjøre innsikts-sikkerhet til standarden 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 minimumskrav. Det virkelige feilmodusen er hva som skjer etter “det fungerer”: produktet blir begrenset så alvorlige team raskt blir frustrert og river det ut.

Dette er hvorfor Arcjets innsikts-applikasjonssikkerhet er designet for to realiteter: du trenger en umiddelbar løsning for oppmeldings-spam, 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 å skrive om alt.

Produktet er ikke brukergrensesnittet. Produktet er kjøretidsatferd, kanter, eksempler og referansedokumenter utviklere kan stole på.

Komment 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 feil ting. Utviklere bygger og sender i kode, ikke i dashboards – og AI-koding-agenter vil ikke “klikke rundt” i en sikkerhetskonsoll for å 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-for-sikkerhet”.

Arcjet eksisterer fordi sikkerhet tilhører applikasjonslaget: versjonskontrollert, testbart, observerbart og nær forretningslogikken hvor intensjonen faktisk bor.

Arcjet innbygger AI-drevet trusseldeteksjon direkte i applikasjonsforespørsler. Fra et teknisk perspektiv, hva er fordelen med denne lokale, innsikts-tilnærmingen sammenlignet med tradisjonelle perimetersikkerhetsverktøy?

Inne i en forespørselshåndterer har du identitet, sesjonsstatus, 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.” En nettverksproxy kan ikke gjøre det fordi den ikke har noen ide om hva en “kunde” er.

Målet er ikke maksimal blokkering. Målet er å minimere feilpositiver med kontekst-bevisste sikkerhet fordi den dyreste sikkerhetsfeilen er å blokkere en legitim kjøpsprosess eller låse ut en ekte bruker.

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

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

Vi ser også angripere kjøre tette tilbakemeldingsløkker: de tester forsvar, tilpasser prompter og nyttelaster, roterer infrastruktur og fortsetter til de kommer inn. Det handler for tiden om hastighet snarere enn sofistikert.

Det er fortsatt for få mennesker som følger beste praksis som å bruke en passordhåndtering, deployere to-faktorautentisering med phish-resistente legitimasjoner som passnøkler eller hardware-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 å bremse 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 bærbar datamaskin. Det betyr at utviklere kan teste det ut uten å deploye til produksjon. Dette er en betydelig fordel fordi du kan validere det og demonstrere integreringen uten å trenge spesielle tillatelser og uten å risikere å påvirke produksjon. Dette løser det klassiske problemet med at sikkerhetsteam tvinger utviklere til å adoptere verktøy som hindrer deres evne til å gjøre jobben.

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

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

AI-produkter betaler for token og inferens – angripere omdanner din margin til deres lekeplass via skraping, automatisering og gratis-nivå-landbruk. E-handel betaler for svindel, chargebacks, varemisbruk og konto- overtakelse. Og begge er hypersensitive for feilpositiver fordi blokkering av ekte brukere er direkte inntektstap.

Legacy-forsvar beskytter hovedsakelig båndbredde og infrastruktur. Moderne angripere målretter forretningslogikk: oppmeldings-flows, kjøps-flows, promo-logikk, konto-gjenopprettelse og API-endepunkter. Det er derfor generiske perimetersikkerhetskontroller og “løs det med en CAPTCHA” øker faller kort.

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 supply-chain-utnyttelse.

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

Som applikasjoner stadig mer avhenger av AI-agenter som handler på vegne av brukere, hvordan bør utviklere tenke om identitet, intensjon og tillit på applikasjonslaget?

Når AI-agenter handler for brukere, stopper identitet å være en binær innloggingstilstand og blir en delefieringsproblem: hvem handler, på hvem sin vegne, med hvilke tillatelser, i hvor lang tid og med hvilke begrensninger.

Utviklere bør skifte til kontinuerlig verifisering: behandle hver forespørsel som om den trenger en fersk tillitsbeslutning basert på kontekst – brukerhistorikk, enhetssignaler, sesjonsatferd og handlingssårbarhet. “Intensjon” er inferert fra atferd over tid, ikke hevdet i header.

Dette betyr å bygge opp trinn-momenter (verifisering, ratelimit, friksjon) rundt høyrisiko-handlinger som passord-tilbakestill, kjøp og token-opprettelse – 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 fremover, hvordan ser du på rollen til innsikts-, kontekst-bevisste sikkerhet utvikle seg 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 det 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: sikkerhetsenhetstester, gjentakbare angreps-simulatorer og CI-sjekker for risikofylte endepunkter.

Den større skiftet er at AI-koding-agenter vil implementere sikkerhet som kode, ikke som dashboard-konfigurasjon. Agenter kan bare pålitelig foreslå, gjennomgå og validere beskyttelser når kontrollene bor i repoet: politikker, regler, tester og instrumentering. Hvis “sikkerhetslaget” er et web-grensesnitt, kan agenten ikke teste endringene for å deploye 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.