Once you've found a real security issue, whether from a self-check, a scan, or someone flagging it, the next decision is whether to fix it yourself with your usual AI coding tool, or bring in someone with more specific expertise. This isn't always an obvious call, and getting it wrong in either direction has real costs.
Fixes that are genuinely fine to handle yourself
- Turning on Row Level Security for a table and writing a straightforward policy: user can only see their own rows. This is a well-documented pattern with clear, checkable correctness.
- Adding standard security headers to your server config. There's a known, correct set, and applying it is close to mechanical.
- Moving a key out of frontend code into a server-side environment variable. The fix is structural and easy to verify: check the browser can no longer see it.
- Adding a rate limit to a login form using your framework's standard library, following its documented pattern.
What these have in common: the correct end state is well-defined and easy to verify yourself, even without deep expertise. You can check the fix worked by testing the exact behavior it was meant to change.
Fixes worth pausing on before doing it yourself
- Anything involving custom authorization logic across multiple interacting features, where a fix in one place could quietly break or bypass a check somewhere else you didn't think to test.
- A finding you don't fully understand the mechanism of. If you can't explain why the bug happens, verifying that a fix actually closes it, rather than just changing its shape, is genuinely hard to do confidently.
- Anything touching payment logic, where a subtle mistake in the fix itself could introduce a new problem while appearing to solve the old one.
- A vulnerability found during, or right before, an active incident, where the pressure to ship a fast fix is highest and the cost of a wrong one is also highest.
Why 'the AI can probably fix this too' is the risky middle ground
An AI coding tool can absolutely write a plausible-looking fix for almost any security finding you describe to it. The question was never whether it could produce something. It's whether you have a reliable way to confirm the fix actually addresses the underlying issue, rather than just making the specific symptom you described go away. For the well-defined fixes above, verifying that yourself is straightforward. For the harder category, a fix that looks right and a fix that is right can differ in ways that aren't obvious from reading the code, and that gap is exactly where outside expertise earns its cost.
A reasonable rule of thumb: if you can clearly state what 'fixed' looks like and test for it yourself afterward, fixing it yourself with AI help is usually fine. If you're not confident you'd actually recognize whether the fix worked, that uncertainty is the signal to bring in someone who would.