Notifications
Clear all
Topic starter
19/08/2026 3:40 pm
TL;DR: An AI coding agent can produce working Java code quickly, yet still miss a HIGH-severity insecure temporary directory and fall short on test coverage, according to Sonar’s experiment with Claude Fable 5, which means existing quality gates remain essential even when the code looks correct. The findings also show that training-data patterns do not reliably cover OS-level security knowledge or non-deterministic vulnerability emergence.
NHIMG editorial — based on content published by Sonar: the Claude Fable 5 code-generation experiment and SonarQube Cloud findings
By the numbers:
- The model produced 1,222 lines of working code in roughly 13 minutes.
- Coverage on new code landed at 76.7% against an 80% threshold.
Questions worth separating out
Q: What breaks when AI-generated code skips secure temp-directory handling?
A: A file-upload flow can appear to work while still writing sensitive artefacts into a shared or attacker-influenced location.
Q: Why do AI coding agents still need security gates after functional tests pass?
A: Functional tests prove that the code executes the expected path, not that it is safe under adversarial conditions.
Q: How do security teams know whether generated code is actually safe to ship?
A: They should look for policy compliance before commit, not just scan results after commit.
Practitioner guidance
- Enforce secure temp-directory handling Require every file-upload or staging workflow to use an explicitly secured parent directory with restrictive permissions, not the system default temp location.
- Gate AI-generated pull requests with deterministic checks Make quality gates mandatory for all agent-generated code, including coverage thresholds, security rules, and branch protections that block merges when findings exceed policy.
- Review filesystem semantics in code review Add a review step that checks shared-host and container filesystem assumptions, including whether temp volumes are shared across processes and whether symlink or TOCTOU conditions are possible.
What's in the full article
Sonar's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact code path that triggered java:S5443 and how SonarQube Cloud mapped it to insecure temporary-file handling.
- The full list of 10 findings across security, maintainability, and coverage, including the specific rule IDs.
- The comparison between two repeated runs and how the higher-severity defects changed from one execution to the next.
- The concrete compliant fix patterns for secure temp directories and restrictive permissions.
👉 Read Sonar's analysis of Claude Fable 5, insecure temp storage, and quality gates →
AI coding agents and insecure temp directories: what teams need to know?
Explore further
19/08/2026 4:19 pm
AI-generated code creates a verification problem, not just a coding problem. The key risk is not that the model cannot write functional code, but that it can produce code that behaves correctly while still violating runtime security assumptions. That makes deterministic quality gates a governance requirement, not a nice-to-have, because human reviewers cannot reliably spot every OS-level or environment-specific weakness. Practitioners should assume agentic development increases the burden on automated verification.
A question worth separating out:
Q: How should organisations decide when to allow autonomous coding agents?
A: Allow autonomy only when the task is bounded, reproducible, and reversible. If the work can change multiple files, call external tools, or run in cloud environments, it needs stronger scoping, monitoring, and rollback readiness. Higher autonomy should always require higher assurance, not just faster delivery.
👉 Read our full editorial: AI coding agents still miss OS-level security gaps in generated code
