Cole Medin on the security gap in AI coding workflows (17 min, partnered with Sonar; Archon, the harness builder he uses, is his own open-source project). His premise: agents are already better and faster than humans at a lot of code — but security is where they fall short far more than reusability, documentation or performance, and almost nobody is building for it.

Two ways agents introduce vulnerabilities

  • They write the flaw directly — SQL injection, a hard-coded password, the usual catalog
  • They install a dependency with a vulnerability already in it, and don’t think twice about the package or the specific version

Why it keeps happening

  • Transitive dependencies: the library may be clean while a sub-dependency carries one or more CVEs — the agent doesn’t walk the chain
  • The CVE list is enormous: Common Vulnerabilities and Exposures is a huge catalog of documented failure modes no agent can hold in context or check exhaustively
  • The models are tuned for speed: labs are rewarded for fast results, the training data is full of human code that also cut corners, so agents cut them too
  • The quiet failure mode: the agent notices the problem and ships it anyway, mentioning it in the PR description as something to fix in a follow-up pull request. That follow-up often never happens

A prompt is not a gate

  • His first approach, and most people’s current one: after the PR, run another agent whose job is to hunt for vulnerabilities
  • It worked “okay” — it found a real number of things — but it’s a probabilistic process layered on top of a probabilistic process
  • If the implementer agent glossed over something, a fresh review agent tends to run into the same blind spot; the PR looks green and the issues are still in the code

The one idea: make it a gate

  • The fix isn’t better judgment from more agents, it’s determinism: a process that checks for vulnerabilities the same way every single time
  • His workflow (issue → classify → plan or investigate → implement → PR) stays the same; only the verification changes
  • A bash node calls the scanner’s API — deliberately not an agent — because that step must be guaranteed
  • The scan report goes to an agent that fixes what’s red; the workflow then re-scans and asserts that everything is actually green before it releases the PR back to him
  • The probabilistic step remains (an agent does the fixing), but the input and the assertion are both deterministic

What it looks like in practice

  • A real PR example surfaced three issues, including a hard-coded password, each mapped to the CVE-style catalog with enough detail for the agent to correct it
  • After iteration, the dashboard reads security rating A with no issues overall — only then is the PR ready
  • He runs the scan inside the workflow rather than only in CI specifically so the report can be handed to the agent for automatic iteration; running it in CI is a fine starting point but leaves the loop to you
  • The workflow is a YAML file you can read, copy, and hand to whatever agent setup you already use — the pattern transfers even if you don’t use his tools

“What we need in our AI coding workflows, that you cannot skip, is a guarantee that we’re going to check for vulnerabilities in the same way every time.” — Cole Medin

The takeaway

  • You won’t detect every vulnerability — no process will. What a gate buys you is the certainty that detection ran and that red findings were addressed before the code was allowed out
  • If a working session can only add one thing: a deterministic security scan that the agent must answer to, not one more agent with an opinion