Is prevention essentially a solved problem?

What it is

A Snyk opinion post (September 10, 2026) laying out where in the agentic development lifecycle each security control should sit. Beyond the thesis, its usable content is a concrete mapping: Laurie Voss's five nested loops and the specific boundary at which automated in-loop fixing stops being reliable.

How it works

The argument rests on a distinction the summary doesn't spell out: an instruction in the context window "shifts the probability of what gets written, but does not decide it." Prompts, skills, and harness config are treated as probabilistic guidance for the predictable risk classes (SQLi, XSS, hardcoded secrets, weak crypto defaults, common IaC misconfigs) — not as constraints. Everything else must be caught by controls placed at a specific loop.

The five loops, inner to outer:

• Execution loop — completes one instruction, exits on environment feedback (test result, API response, file contents).
• Task loop — completes a specification.
• Product loop — ships.
• System loop — improves the whole over days/weeks.
• Oversight loop — a human sets goals, budget, and priorities.

The operative boundary: inside the execution and task loops the work is still open, so a finding can be fixed before the loop closes without human intervention, because the agent still holds the original prompt and spec and can confirm the fix is both functional and secure. From the product loop outward, that context is gone — you need either strong trust in test coverage (unit, smoke, integration tests running before/during CI) or human review.

flowchart LR
  E[Execution loop] --> T[Task loop] --> P[Product loop] --> S[System loop] --> O[Oversight loop]
  subgraph inner[auto-fix possible, agent holds spec]
    E
    T
  end
  subgraph outer[needs test coverage or human review]
    P
    S
    O
  end

What to do

Not a patch — a placement rule for your own pipeline:

• Cover the nameable risk classes with in-context guidance (system prompts, harness config, skills), but treat it as probability-shifting, not a control.
• Put deterministic scans as far inward as possible; the page notes a deterministic scan's cost is "a rounding error next to a model call," and a finding caught in-loop never becomes a ticket.
• Ensure test coverage is strong enough to carry correctness at the product loop and beyond, since agent-held intent is unavailable there.

Caveats

The claim that prevention is "solved" is architectural, not adoption-reality — the post concedes org rollout during an actively shifting SDLC is the hard part, that pressure to remove friction runs the other way, and that agent adoption is uneven across (and within) teams. The fetched text cuts off mid-sentence in "The risks you can name in advance," so any detail past the list of predictable risk classes is not captured here.