We should say this first, because it changes how the rest reads: we love Claude. We use it every day, across our own tooling and our engagements. That is precisely why we can be blunt about the sentence we hear more than any other when we ask a team how they handle security: “Oh, we just use Claude for that.”
Paste the finding, ask for a fix, apply the diff, move on. It feels fast and it feels responsible — something is being done about security. But “ask the model to fix it” is a single step. A security program is the other nine steps around it, and those are exactly the ones a bare prompt throws away.
The demo is not the program
A model fixing a bug in a chat window is a demo. It is genuinely impressive, and for a throwaway script it may be all you need. But a cybersecurity program is not a sequence of impressive demos. It is the durable answer to a set of questions that outlive the fix — questions an auditor, a customer's security team, or your own future incident review will absolutely ask. A one-shot prompt answers none of them, because it was never asked.
Five things the prompt never captures
1. Business context
The model sees a function. It does not see that the function authorizes refunds, or that the table it queries holds every customer's bank detail, or that this service is the one under a contractual SLA. Severity is not a property of the code; it is a property of what the code touches. Strip the business context and every finding looks like the same medium-priority diff — which is how the one that actually matters gets treated like the one that doesn't.
2. Whether it was already in production
“Fixed” and “never exposed” are completely different states, and only one of them requires you to go look at your logs. If the vulnerable code shipped, the question is no longer “is it fixed” — it is “was it used against us, and by whom, and for how long.” A model handed a diff has no concept of your release history. It cannot tell you the exposure window, and the exposure window is where the actual risk lives.
3. Impact and blast radius
One SQL injection in an internal admin tool behind a VPN is not the same event as the same injection on a public endpoint that shares a database with production. The line of code can be identical; the blast radius is not. Assessing it means reasoning about what an attacker reaches after the first foothold — connected systems, shared credentials, lateral movement — which is a question about your architecture, not about the snippet in the prompt.
4. What the fix does to your architecture
This is the one that quietly hurts. A plausible-looking fix can add a new dependency, introduce a call across a trust boundary, cache something that should never be cached, or move validation to a layer that a second code path skips. You closed a bug and moved a boundary. Without someone asking “what did this change about the shape of the system,” you are trading a known issue for an unknown one — and the model, working one file at a time, is the last thing that will notice.
5. The audit trail
When someone asks “how do you know this was handled” — and in a regulated or enterprise context, someone always asks — you need more than a merged commit. You need to show what the issue was, how its impact was judged, what was changed, who approved it, and the evidence it was verified. That record is the product of a process. A prompt-and-paste loop produces a diff and a vague memory. Those are not the same thing, and the gap between them is exactly what shows up in a SOC 2 audit or a customer security questionnaire.
The missing context is the whole point
Notice that none of the five are about the model being wrong. Claude may well write a better patch than the engineer would have. The failure mode is not a bad fix — it is a fix with no surrounding record of what it was, why it mattered, and whether it worked. Security value does not live in the diff. It lives in the context around the diff, and “just use Claude” is a workflow optimized to discard precisely that context.
Put concretely: every finding worth the name has to answer the same short list of questions. The model can help answer several of them. It will not ask them for you.
Eight questions a program answers — and a bare model call is never asked.
Provenance is not paperwork
It is tempting to treat the audit trail as bureaucracy — the boring part you do for the auditors. It is the opposite. The trail is what lets you answer, months later and under pressure, whether the thing that just got exploited in the news is the thing you fixed in March, or a cousin of it, or something you closed and then quietly reopened with a refactor. Provenance is how a security program remembers. A stateless prompt has no memory by design.
What good actually looks like
The answer is not “stop using AI.” It is AI in the loop, not AI as the loop. Keep the model doing what it is genuinely great at — reading code, proposing fixes, drafting the explanation. Then wrap it in the structure that turns an output into a security outcome: attach the business context, check production exposure, measure blast radius, review the architectural impact, verify by reproducing the attack and proving it now fails, and record all of it so the next person inherits the reasoning instead of re-deriving it.
That is the difference between a tool and a program, and it is the entire reason ZIVIS exists. We put the model in the loop and keep the context, the verification, and the trail around it — so “we handled it” is a statement you can prove, not a hope you can't.
If your honest answer to “how do you handle security” today is “we just use Claude,” you don't have a bad tool. You have a great tool and no program around it. The good news is that the fix is additive — and it's the part we do.