Put those areas in the highest review tier and assume tests are not enough. These classes often depend on security knowledge that is not obvious from the local code, such as constant-time behavior, proper locking, authentication checks, and authorization boundaries. Human review should validate the security property itself, not only whether the patch compiles or passes unit tests.
Why code in these areas needs a higher review tier
Cryptography, concurrency, and access control are the kinds of changes where a patch can look correct yet still break the security property. Code generation is especially risky when the important detail lives outside the local diff, such as key handling, timing behavior, lock ordering, privilege boundaries, or request authorization. Treat these changes as design-sensitive, not just implementation-sensitive.
For cryptography, the real question is whether the code preserves confidentiality, integrity, and misuse resistance under the full operating context. A function can compile and pass tests while still leaking information through timing, using the wrong primitive, or handling keys and secrets unsafely. For concurrency, the concern is not only correctness but also whether the locking and memory model still prevent races, deadlocks, or inconsistent state under load.
For access control, the local code often hides the actual security decision. A generated patch may enforce a check in one path while missing a second entry point, a side effect, or a downstream function that still needs the same boundary. That is why the review has to validate the intended authorization rule, not just the syntax of the patch.
What a human reviewer should validate
Reviewers need to check the security property itself, not only whether the code is idiomatic or testable. In cryptography, that means confirming the algorithm choice, mode, IV or nonce handling, key lifecycle assumptions, and whether the code creates any observable difference that an attacker could exploit. In concurrency, it means checking the critical section boundaries, shared-state assumptions, and whether error handling or retries reintroduce races.
For access control, the review should ask whether the code enforces the right subject, action, and resource combination at every path. A secure-looking wrapper is not enough if a caller can bypass it, cache the result incorrectly, or reuse a token or session beyond its intended scope. The review should follow the request flow end to end, especially where code splits across services, helpers, or generated scaffolding.
The safest review posture is to treat these changes as architecture changes in miniature. Even small edits can alter trust boundaries, ordering guarantees, or the point at which authorization is decided. When the reviewer cannot explain why the code is secure in the absence of exhaustive tests, the patch is not ready.
How teams should operationalize this review model
Teams get better results when they predefine which classes of AI-written code automatically escalate to senior review. Cryptography, concurrency, and access control should sit near the top of that list because they are easy to get subtly wrong and hard to prove correct after the fact. The review template should force the reviewer to name the security property being protected before accepting the change.
That review step should be paired with targeted verification. For cryptography, ask for explicit rationale on primitive selection and key handling. For concurrency, ask how the code behaves under parallel execution, retries, and partial failure. For access control, ask which principal is authorized, which resource is protected, and which alternate path could still bypass the check. A passing test suite is useful, but it is only evidence that the code ran, not that the security boundary held.
Practitioner takeaway: When AI writes code in these areas, require a reviewer who can reason about the security property itself, because correctness signals from tests or compilation are not strong enough to prove safety.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V11 — Cryptography | AI-written cryptography code needs review of secure primitive and key handling choices. |
| V8 — Authorization | Access-control code must enforce the correct subject, action, and resource checks. | |
| V15 — Secure Coding and Architecture | Concurrency and boundary-sensitive code require architecture-aware review beyond unit tests. | |
| Recommendation — Verify the cryptographic design and primitive selection before accepting generated code. Review every authorization path for bypasses, missing checks, and scope leakage. Validate the design assumptions, trust boundaries, and failure modes behind the patch. | ||
| NIST SP 800-53 Rev 5 | SI-16 — Memory Protection | Concurrency and crypto bugs often emerge from unsafe shared-state and memory handling. |
| AC-6 — Least Privilege | Access-control changes should preserve least privilege and avoid overbroad authority. | |
| Recommendation — Check shared-state handling for race conditions and unsafe memory access patterns. Limit the code path to the minimum privileges needed for the operation. | ||
Related resources from NHI Mgmt Group
- What do teams get wrong about AI coding agents generating access-related code?
- How should security teams control AI agents that can read secrets and modify code?
- How should security teams implement access control for AI agents when decisions depend on tenant membership, ownership, and runtime conditions?
- How should security teams implement an on-prem LLM gateway to control access across internal tools and AI agents?
