Race conditions are the hardest class of security vulnerability for static analysis. They require reasoning about concurrent execution, shared state, and the specific timing windows between operations. Static analysers have historically under-detected this class. AI-for-security tools claim to do better; the claims vary widely. The specific capability needed — concurrency-aware reasoning over the code — separates tools that find real race conditions from tools that flag anything with shared mutable state.
What race condition detection requires
Three capabilities:
- Happens-before reasoning. Identifying which operations execute before which under concurrent execution.
- Shared state tracking. Recognising state accessible from multiple threads, goroutines, tasks, or async contexts.
- Timing window analysis. Specific race patterns: TOCTOU, non-atomic read-modify-write, check-then-act without locking.
Each capability requires specific engineering. The combination is what separates real detection from pattern recognition.
Where pure-LLM analysis struggles
Mythos-class tools can recognise common race patterns from training data — the check_user(uid); delete_user(uid) TOCTOU pattern is in training corpora. Recognition works.
The failure mode is at the shared-state-tracking layer. In real code, shared state reaches dangerous operations through multiple layers of method calls, class fields, and global references. Tracking "does this specific variable receive concurrent writes under the actual call patterns used by callers" is multi-file reasoning that pure-LLM analysis handles inconsistently.
How Griffin AI handles it
Three deterministic steps:
Concurrency model identification. The engine recognises concurrency primitives across major languages: Go goroutines, Java threads, Python asyncio tasks, Node event loops, Rust tokio tasks. Each has different sharing semantics.
Shared state enumeration. For each function, the engine identifies state that is accessible from multiple concurrent contexts. Class fields without synchronisation, global variables, static caches, singleton-pattern state.
Race pattern matching. Shared state accesses are checked against race patterns: non-atomic read-modify-write, check-then-act, double-initialisation, lost update, and TOCTOU.
The engine surfaces specific patterns with locations. Griffin AI's reasoning step adds context about exploitability.
A concrete example
A web service has a function debitUserAccount(userId, amount). It reads the balance, checks that the balance ≥ amount, then subtracts. No locking. No database transaction. The function is called from multiple concurrent HTTP handlers.
Griffin AI surfaces the race: read-modify-write on shared state without atomicity. The exploit: concurrent requests can both pass the balance check before either subtracts, producing a debit that exceeds the balance. The suggested fix: database row-level locking or optimistic concurrency with version check.
A Mythos-class tool recognising the debit pattern might flag the balance check as "check-then-act without locking" but often does not connect the pattern to the concrete concurrent access pattern in the specific codebase.
Coverage across race classes
The engine covers:
- TOCTOU (time-of-check to time-of-use) — file permission, authentication, balance checks followed by operations.
- Non-atomic counter updates —
count++on shared state without synchronisation. - Double-initialisation — singleton patterns without proper guarding.
- Lost update in caches — cache refresh races.
- Signal-unsafe operations in signal handlers (systems programming).
What to evaluate
Three concrete checks:
- Show the platform a TOCTOU authorisation check. Is the race surfaced with the specific concurrent-access pattern?
- Show a non-atomic counter increment on shared state. Is the race identified?
- Show a benign-looking shared-state access that is actually safe because of external locking. Is the finding correctly suppressed?
How Safeguard Helps
Safeguard's engine implements concurrency-aware analysis across major languages and their concurrency primitives. Race condition findings come with the specific pattern, the shared state location, and the concurrent call sites. Griffin AI adds exploitability context. For organisations whose most expensive incidents have been race conditions that reached production, this detection capability is the architectural feature to evaluate first.