I've been integrating AI coding assistants into our team's workflow for about six months now, and while the velocity gains are undeniable, I've noticed a pattern: security considerations can become an afterthought when we're iterating quickly with generated code. The convenience of accepting a suggested fix or feature can sometimes outpace our usual scrutiny. This led me to develop a more structured review process specifically for these AI-assisted changes.
I wanted a checklist that was pragmatic, integrated into our existing pull request workflow, and focused on the unique risks AI-generated code might introduce. The goal isn't to be paranoid, but to add a consistent, lightweight layer of verification. Here's the step-by-step approach I've been refining, broken down into pre-commit and PR review phases.
**Pre-commit & Prompting Phase (Before Generation)**
This is about setting the stage for safer output. My checklist items here focus on the context we provide to the AI.
* **Explicit Security Constraints in the Prompt:** I now always append specific guardrails to my coding assistant prompts. For example: "Do not suggest any code that performs direct string concatenation for SQL queries," or "Ensure any file path operations are sanitized against directory traversal attacks."
* **Scope and Context Limitation:** I'm careful to only share the minimal necessary code context. If the task involves authentication, I might provide an interface but never the actual implementation secrets or keys. This reduces the risk of the assistant inadvertently suggesting something that leaks or misuses sensitive data from its training.
* **Request Justification and Alternatives:** For complex or security-adjacent changes, I ask the assistant to explain *why* its solution is secure and to list potential alternative approaches. This doesn't replace my judgment, but it surfaces the model's reasoning, helping me spot flawed assumptions.
**Code Review Phase (After Generation)**
This is where the generated code itself gets examined, with a lens tuned to common AI failure modes.
* **Hallucinated or Misapplied Libraries/APIs:** I meticulously verify any suggested library, module, or API call. I've seen assistants recommend deprecated packages, fictional functions, or real functions used with incorrect, insecure default parameters (e.g., a cryptographic function with weak defaults).
* **Data Flow and Input Sanitization Audit:** I trace every piece of user or external input through the suggested code. AI often provides the "happy path" logic but can miss edge cases. I ask: Is input validated at the boundary? Is output encoded? Are there any assumptions about data format or size that could lead to injection or overflow?
* **Hardcoded Values and Secret Management:** I search for any strings, tokens, or URLs that look like they should be configuration or secrets. AI will readily hardcode placeholder values, and it's easy to miss one during a cursory review. This item forces a scan for `password`, `token`, `key`, ` http://localhost`, etc.
* **License and Provenance Check:** For any substantial copied or adapted code blocks, I consider the licensing implications. While the AI is generating it, its training data includes open-source code. For critical path or distributed code, I might run a quick scan or at least document this consideration.
The final step in our process is a simple **"Skepticism Pass."** I ask the reviewer to treat the AI-suggested lines with extra skepticism compared to human-written code, focusing on the "why" behind each logical step. We've found this mindset shift alone catches a significant number of subtle issues.
Implementing this hasn't slowed us down; it's just made our acceptance of AI suggestions more deliberate. I'm curious—has anyone else built similar guardrails? I'm particularly interested in how this might map to infrastructure-as-code generation (Terraform, CloudFormation), where the risks are at a different layer.
~jason
~jason