David Mytton, CEO of Arcjet – Interview Series

David Mytton, founder and CEO of Arcjet, leads the developer-focused security startup that helps teams embed robust protections like bot detection, rate limiting, email validation, attack mitigation, and data redaction directly into application code, having taken the helm in June 2023. He also co-founded Console, a well-followed devtools newsletter and podcast, has served in advisory roles such as Expert in Residence at Seedcamp, and previously ran product engineering at StackPath after his cloud monitoring company was acquired, while maintaining a strong interest in sustainable computing and active writing on tech topics.

Arcjet is built around a “security-as-code” philosophy that lets developers secure applications with simple SDK integrations, placing security logic alongside business logic for low-latency, context-aware decisions and eliminating the need for separate infrastructure; the platform supports protections such as bot blocking, rate limits, and sensitive data filtering and continues to evolve with features like a local AI security model and expanded framework support, reflecting its mission to make in-code security the default for modern apps. (fly.io)

You founded Server Density at a time when running infrastructure at scale was far less standardized than it is today, and ultimately grew and sold the company. Looking back, what were the most important lessons you learned about building for developers and operating production systems, and how did that experience shape the way you think about software today?

Most developer tools win the demo and lose production. Getting a developer to install anything new is difficult, so “quick start” has to be frictionless – but that’s table stakes. The real failure mode is what happens after “it works”: the product becomes constrained so serious teams quickly get frustrated and rip it out.

That’s why Arcjet’s in-code application security is designed for two realities: you need an immediate fix for signup spam, account fraud, bot attacks, API abuse, etc, and you also need an escape hatch into advanced controls – per-user quotas, risk-based rules, and context-aware decisions – without rewriting everything.

The product isn’t the UI. The product is the runtime behavior, the edge cases, the examples, and the reference docs developers can trust.

Coming out of that experience, what led you to start Arcjet, and why did you feel the next major shift in application security needed to happen inside the code itself rather than at the network or infrastructure layer?

Perimeter security is optimizing the wrong thing. Developers build and ship in code, not in dashboards – and AI coding agents won’t “click around” a security console to protect an app.

If your protection can’t be expressed as code, reviewed in a pull request, tested in CI, and deployed alongside the application, it’s not “developer-first security”.

Arcjet exists because security belongs in the application layer: version-controlled, testable, observable, and close to the business logic where intent actually lives.

Arcjet embeds AI-powered threat detection directly into application request handlers. From a technical perspective, what advantages does this local, in-code approach provide compared to traditional perimeter-based security tools?

Inside a request handler you have identity, session state, purchase history, account age, feature flags, and database truth. You can make a decision like: “This looks weird, but it’s a loyal customer – step up verification instead of blocking.” A network proxy can’t do that because it has no idea what a “customer” is.

The goal isn’t maximum blocking. The goal is to minimize false positives with context-aware security because the most expensive security mistake is blocking a legitimate checkout or locking out a real user.

AI has dramatically changed the economics of abuse, from bot scraping and spam signups to automated API exploitation. What kinds of attacks are you seeing most often in production today, and how are they evolving as attackers adopt more advanced AI systems?

AI’s productivity gains are helping attackers as well! The big shift is volume and iteration speed: more credential stuffing, more automated signup spam, more bot scraping, more API probing, and faster “weaponization” of fresh vulnerabilities.

We’re also seeing attackers run tighter feedback loops: they test defenses, adapt prompts and payloads, rotate infrastructure, and keep going until they get in. It’s currently all about speed rather than sophistication. 

There are still too few people following best practices like using a password manager, deploying 2-factor authentication with phish resistant credentials like passkeys or hardware keys, and keeping dependencies up to date. With attack volumes increasing that is going to become more and more important.

One of the biggest tensions in security is protecting applications without slowing development. How have teams using Arcjet been able to integrate security into their workflows while maintaining fast release cycles?

Arcjet runs in any environment, including in the coding environment on a laptop. That means developers can test it out without even deploying to production. This is a significant advantage because you can validate it and demonstrate the integration without needing special permissions and with no risk of affecting production. This solves the classic problem of security teams forcing developers to adopt tools that impair their ability to get their job done. 

Arcjet has gained early traction with AI-native products and e-commerce platforms. What makes these environments especially vulnerable to modern automated attacks, and why do legacy defenses tend to fall short?

These two categories share a similarity where every abusive request has a direct cost.

AI products pay for tokens and inference – attackers turn your margin into their playground via scraping, automation, and free-tier farming. E-commerce pays for fraud, chargebacks, inventory abuse, and account takeover. And both are hypersensitive to false positives because blocking real users is literally revenue loss.

Legacy defenses mostly protect bandwidth and infrastructure. Modern attackers target business logic: signup flows, checkout flows, promo logic, account recovery, and API endpoints. That’s why generic perimeter controls and “solve it with a CAPTCHA” increasingly fall short.

Building security software comes with very different trade-offs than observability or monitoring. What surprised you most about developing a security product compared to your earlier experience with infrastructure tooling?

With observability, customers trust you to be available. With security, customers trust you to be safe and to not become their newest supply-chain exploit.

Building a security product means running a security company. We use frameworks like SOC 2, minimize our third-party dependencies, and treat developer laptops and access to tools as production assets. This means a lot of monitoring and quick reactions to potential problems.

As applications increasingly rely on AI agents acting on behalf of users, how should developers rethink ideas like identity, intent, and trust at the application layer?

As AI agents act for users, identity stops being a binary login state and becomes a delegation problem: who is acting, on whose behalf, with what permissions, for how long, and with what constraints.

Developers should shift to continuous verification: treat every request as needing a fresh trust decision based on context – user history, device signals, session behavior, and action risk. “Intent” is inferred from behavior over time, not claimed in headers.

This means building step-up moments (verification, rate limits, friction) around high-risk actions like password reset, checkout, and token creation – and make those controls live in-code, where the application can distinguish a loyal customer from a bot with a stolen cookie.

Looking ahead, how do you see the role of in-code, context-aware security evolving over the next few years as AI-generated traffic continues to grow?

Perimeter tools won’t disappear – but they’ll be the coarse filter for things best dealt with at the network like DDoS attacks. The precise decisions will happen inside the app, using real context.

If embedded security becomes the default model for modern applications, what does that shift mean for how developers test, deploy, and reason about safety in production systems?

If embedded security becomes standard, teams will test abuse the way they test correctness: security unit tests, replayable attack simulations, and CI checks for risky endpoints.

The bigger shift is that AI coding agents will implement security as code, not as dashboard configuration. Agents can only reliably propose, review, and validate protections when the controls live in the repo: policies, rules, tests, and instrumentation. If the “security layer” is a web UI, the agent can’t test the changes to ship safely.

That’s the real reason “security in code” wins – it fits how modern software (and modern AI-assisted development) actually gets built.

Thank you for the great interview, readers who wish to learn more should visit Arcjet.