Developers can finally own security

For most of the last decade, the friction between developers and security has been a knowledge problem. Developers knew their application whereas security engineers knew the threat model. Neither had the full picture, which caused unnecessary friction and frustration.

I started Arcjet to fix that gap. Our JS and Python SDKs gives developers building blocks for the hardest parts that shouldn’t be built in-house - spam signup protection, AI budget control, bot detection, prompt injection - all as code they write alongside their application logic, not config they hand off to another team.

That has worked. But it has never been the whole answer. Using the SDK well still requires knowing which routes to protect, which rules to apply, and how to tune them for a specific app. Our docs, examples, and blueprints exist because that judgment is real work.

The last few months of AI progress makes the rest of the gap closable. The developer's job is no longer primarily writing code - it's orchestrating coding agents and maintaining the scaffolding those agents depend on. Writing a function is cheap now. Knowing which function to write, and whether the code is right, is where experienced engineers need to spend their time.

Security is the next capability to follow that curve. The expertise required to apply security correctly can now live inside the agent, not inside the developer's head or a separate team's backlog. A coding agent with the right context can know which routes in a Next.js or Flask app need bot protection, how to stage rules in dry-run before going live, and how to read traffic patterns and adjust. This merges multiple layers of essential context: the application and business logic with security engineering techniques and the understanding of what your application traffic looks like in real time.

You can see what this looks like in practice today. A developer working in Cursor or Claude Code with the Arcjet plugin installed asks the agent to protect a new signup route. Now the agent can load skills to understand the right SDK patterns for the framework they're in, pick the right combination of Arcjet's security building blocks, and write the rules into the route handler in dry-run mode. The protection lives in the same pull request as the feature it protects.

A week later, the same developer asks for a security briefing before a product launch. The agent queries the Arcjet MCP server, pulls live traffic analysis, flags a cluster of suspicious IPs targeting the new route, estimates false-positive impact, and opens a pull request promoting the dry-run rule to live.

The developer reviews the diff, approves, and ships - without ever becoming a security engineer, and without pulling one away from the work only they can do: threat modeling, incident response, and owning the overall security posture of the business.

Ownership follows capability. Security has lived outside the team that writes the code because the team that writes the code was forced to use tools and workflows that weren't designed to fit into the developer workflow. Separate systems, dashboards, no way to test locally...

That's no longer true for the routine work - the rate limits, the bot rules, the prompt injection checks, the budget caps - which now belongs in the same pull request as the code it protects, written by the same agent, reviewed by the same developer.

What belongs to security engineers is the higher-leverage work: deciding what the threat model is in the first place, building out security practices across the stack, and responding when something gets through.

Developers can finally ship secure code faster and with confidence.