I recently joined James Governor at RedMonk to talk about why security tooling still feels years behind the rest of the developer ecosystem and
I recently joined James Governor at RedMonk to talk about why security tooling still feels years behind the rest of the developer ecosystem and what it would take to treat security as just another feature that developers build rather than a bolt-on afterthought.
You can listen to the full conversation as a podcast or watch it on YouTube.
Over the past few years, the tools developers rely on every day have improved dramatically. Platforms like Vercel, Netlify, Fly, Render, and Railway make deployment trivial. Frameworks iterate quickly and focus on developer experience. Editors now come with AI baked in. Most parts of the workflow are fast, consistent, and fun.
Security did not make that leap. Once code goes into production, developers are asked to adopt systems that live completely outside their application. They rely on dashboards, agents, or proxies that understand packets but not users, sessions, or business logic. These tools interrupt development rather than fitting into it.
Traditional WAFs and reverse proxies operate low down in the stack (typically at the network level) and only observe HTTP semantics and packet headers. They lack application-level context such as session identity, business events, and typed payload semantics (JSON schemas, GraphQL types). This makes it impossible to express rules like “rate limit only unverified accounts on POST /checkout” without extra telemetry and brittle configuration glue.
It’s not that developers don’t care about security. They do. They just haven’t been given tools that match the way they already write and ship software. Good security decisions depend on knowing what the application is trying to do. A traditional WAF can block a request, but it has no idea whether:
Without application context, systems default to coarse heuristics (IP block, global rate limits) which increase false positives; instead we aim for contextual policy primitives that evaluate on session state, route semantics and field-level signals. Otherwise the “safest” thing to do is block broadly, which leads to terrible user experience and frustrated engineers. What worked fine locally breaks in prod.
This is similar to how databases worked in the past. You needed a separate specialist to manage them. Today, platforms like Supabase let developers treat the database as a feature of their application rather than an external system. Security should be heading in the same direction.
When I talk to developers, they rarely say, “I need a WAF.” They say:
These are concrete problems. But solving them today usually involves integrating multiple products, wiring them together, and dealing with configuration formats that don’t match how applications are built. Arcjet’s approach is to provide small, composable primitives you import directly into your application. For something like a signup form, you might combine:
You drop in a few lines of code, get the result immediately, and move on. If you need to tune things later, everything lives in the same codebase where you’re already working.
Most new applications today are written in JavaScript or TypeScript. Frontend and backend code share patterns, and the ecosystem moves quickly. Meanwhile, serverless runtimes spin up and down on demand, run in constrained environments, and sit behind integrated CDNs.
Serverless platforms have two properties that break traditional agents/proxies: short-lived containers (cold starts), and execution environments that disallow sidecars/long-lived agents or arbitrary local network redirects. Any solution that requires persistent agents or an inbound proxy adds latency and brittleness. Running as an in-process SDK avoids these problems and supports cold starts because the Wasm module can be hot-cached in the runtime.
Developers don’t need to know about this level of detail, but for Arcjet it gives us the safety properties of a secure sandbox and native performance. It also lets us support multiple languages & platforms using the same core.
Running detection locally enablesPII detection without egress. Our local PII scanner uses deterministic detectors that run inside Wasm. This lets teams satisfy privacy constraints (no production request bodies sent to third-party APIs) and reduces latency.
I’ve taken to calling this “local first” security. It’s a pretty bad slogan because nobody is searching for it, but it has become an important design principle:
The result is that common decisions return in under a millisecond, and developers can run everything locally during development. Unlike RASP approaches that instrument or monkey-patch running code, the Wasm sandbox executes isolated code with explicit boundaries. This avoids dynamic bytecode patching, preserves stack traces for developers, and keeps integration explicit and reproducible.
Cloud platforms are adding more security features. Vercel has a WAF and bot protection. Cloudflare covers a broad surface area. These can work well if you commit entirely to one platform. Most teams don’t. It’s common to see:
Each platform handles security differently, with different configuration models and capabilities. That leads to inconsistent enforcement and, frankly, a lot of the vulnerabilities you read about are misconfigurations rather than zero-days.
Arcjet takes the opposite approach: the code you write locally behaves the same way on any platform. In-code security means you can move an application from Vercel to Fly without rewriting your security layer. Security is versioned, reviewed, and included as another feature in your SDLC.
The developer experience is intentionally simple. You sign in with GitHub or Google, install the SDK, and start protecting the routes you care about. The free tier covers enough for open source, side projects, or initial prototyping.
In early-stage companies, this is entirely a developer-led decision. Once the first security hire joins, they usually have a long checklist to get through. Later, as a company grows, the security team becomes a separate function with concerns around risk, consistency, and compliance.
The challenge is making sure developers don’t lose momentum when those layers appear. My goal is to provide something developers want to use because it solves their problems in a way that matches how they build software, while giving security teams the visibility and consistency they need across environments.
Developers already have great tools that make complex tasks simple: Tailwind for design, Supabase for databases, Clerk for auth, Tailscale for networking, Fly for global deployments. Security should fit into that same category. It should be something you import, configure, and reason about in code, rather than a separate box running somewhere else.
If you’d like to hear the full discussion with James, it’s here: RedMonk conversation on developer-first security
Announcing Arcjet’s local AI security model, an opt-in AI security layer that runs expert security analysis for every request entirely in your environment, alongside our Series A funding.
Arcjet filters let you block requests using expressions over HTTP headers, IP addresses, and other request fields.
How do you design a security product for developers when they allegedly don't care about security?
Get the full posts by email every week.
