Scope
This guide focuses on transitioning from traditional line-by-line code reviews to intent verification systems for teams facing AI-generated code bottlenecks. You'll find specific steps for implementing deterministic checks, intent documentation frameworks, and integration patterns that meet security requirements in PCI DSS v4.0.1, SOC 2 Type II, and ISO/IEC 27001:2022.
This guide does NOT cover eliminating manual code reviews, AI code generation tools, or general PR workflow optimization unrelated to security verification.
Key Concepts and Definitions
Intent verification: Validating that code implements documented security requirements and constraints before reviewing implementation details. Your security gate occurs at the specification phase, not the PR phase.
Deterministic checks: Automated, binary pass/fail tests that verify specific security properties. Examples include authentication middleware presence, input validation patterns, and cryptographic algorithm compliance. These checks block code that fails to meet security standards.
Pre-implementation security contracts: Written agreements between developers and security teams specifying required controls, acceptable libraries, data handling rules, and threat model assumptions before code generation begins.
Review debt: The gap between code production velocity and review capacity. Research shows that as change size grows, the share of useful comments shrinks. Teams with high AI adoption are merging more PRs, while review times have increased significantly.
Requirements Breakdown
Security Control Requirements
PCI DSS v4.0.1 Requirement 6.3.2: Ensure security vulnerabilities are identified and addressed. Your deterministic checks must detect OWASP Top 10 2021 patterns like injection and broken authentication before code reaches production.
PCI DSS v4.0.1 Requirements 6.5.3 and 6.5.4: Address injection flaws and implement proper authentication. Intent documentation must specify the input validation framework and authentication boundaries.
SOC 2 Type II CC6.1: Implement logical and physical access controls. Pre-implementation contracts should define data access and how code enforces boundaries.
ISO/IEC 27001:2022 Annex A.8.3: Document media handling controls, including retention policies and deletion mechanisms, in the intent phase.
Process Requirements
- Intent documentation before code generation: Specify data flows, security boundaries, cryptographic requirements, and error handling patterns.
- Deterministic checks pre-merge: Block PRs that violate codified security rules.
- Human review focuses on intent-implementation alignment: Ensure code implements the documented security contract.
Implementation Guidance
Phase 1: Codify Your Non-Negotiables
Start with security rules that have zero acceptable variance:
- Cryptographic standards: TLS 1.3 for transport, AES-256-GCM for data at rest, bcrypt (cost factor ≥12) for passwords.
- Authentication patterns: JWT validation must check signature, expiration, issuer, and audience claims.
- Input validation: All external input must pass through allowlist validation before database queries.
- Secrets management: No hardcoded credentials, API keys, or certificates in source code.
Automate these tests to run in your CI/CD pipeline using tools like Semgrep or CodeQL. If code violates these rules, the build fails immediately.
Phase 2: Build Intent Templates
Create pre-implementation templates for common security-sensitive features:
API endpoint template:
- Authentication method (OAuth 2.0, API key, mTLS)
- Authorization model (RBAC roles required)
- Input validation rules (expected data types, size limits, format requirements)
- Rate limiting parameters
- Logging requirements (what gets logged, what gets redacted)
- Error handling (what information can leak in error messages)
Data processing template:
- Data classification level (public, internal, confidential, restricted)
- Encryption requirements (at rest, in transit, in memory)
- Retention period
- Deletion mechanism
- Access logging requirements
Developers fill out these templates before writing code. Your security review happens here — on the intent document, not the implementation.
Phase 3: Train Your Team on Intent Documentation
Ensure your developers understand what security reviewers care about. Conduct workshops on:
- Threat modeling basics (STRIDE is sufficient for most teams)
- Common vulnerability patterns from OWASP ASVS v4.0.3
- Your organization's specific compliance requirements
- How to read and write security contracts
The person generating code should be able to answer: "What attack vectors does this code defend against?" If they can't, the intent documentation is incomplete.
Phase 4: Implement Graduated Review Paths
Not all code needs the same scrutiny:
Deterministic checks only:
- Dependency updates with no API changes
- UI copy changes
- Configuration updates that don't affect security boundaries
- Refactoring with identical test coverage
Intent verification:
- New API endpoints with standard authentication
- Database schema changes
- Third-party integrations using approved libraries
Full security review:
- Custom cryptographic implementations
- Authentication/authorization logic changes
- Payment processing code
- Access control modifications
Common Pitfalls
Pitfall 1: Treating intent documentation as bureaucracy
If your team sees this as "more paperwork," you've failed. Intent docs should take 10-15 minutes and prevent hours of back-and-forth during PR review. Frame it as front-loading the conversation.
Pitfall 2: Weak deterministic checks that produce false confidence
A check that verifies "authentication exists somewhere in the file" is useless. Your checks must verify specific security properties: "This endpoint calls authenticateRequest() before accessing user data AND that function validates JWT signatures."
Pitfall 3: Skipping intent review for "small changes"
The smallest changes cause the biggest incidents. A one-line configuration change can disable authentication. Every security-relevant change needs intent verification, regardless of size.
Pitfall 4: No feedback loop from incidents to intent templates
When you find a vulnerability in production, update your intent templates and deterministic checks to prevent that class of bug. Your templates should evolve based on real findings.
Pitfall 5: Assuming AI-generated code is inherently less secure
The code quality isn't the issue — it's the volume and velocity. AI can generate perfectly secure code if the intent specification is correct. Focus your energy on getting the intent right.
Quick Reference Table
| Review Stage | What You Verify | Tools/Artifacts | Blocking Criteria |
|---|---|---|---|
| Pre-implementation | Security requirements documented, threat model complete, compliance controls specified | Intent template, threat model doc | Missing data classification, undefined authentication, no input validation rules |
| Pre-merge (automated) | Code matches security patterns, no prohibited libraries, secrets not hardcoded | Semgrep, CodeQL, custom static analysis | OWASP Top 10 patterns, non-compliant crypto, hardcoded credentials |
| Pre-merge (human) | Implementation matches intent, security boundaries correct, error handling appropriate | Intent doc + PR diff | Intent-implementation mismatch, security boundary violations |
| Post-merge | Runtime behavior matches specification, logging captures security events | APM tools, SIEM integration | Unexpected data flows, authentication bypasses, missing audit logs |
Compliance mapping:
- PCI DSS v4.0.1 Requirements 6.3.2, 6.5.3, 6.5.4 → Deterministic checks + intent verification
- SOC 2 Type II CC6.1 → Intent templates must specify access controls
- ISO/IEC 27001:2022 Annex A.8.3 → Data handling documented in intent phase
Review frequency by risk level:
- Critical (auth, payments, PII): Intent review + full security review
- High (API endpoints, data processing): Intent review + spot checks
- Medium (business logic, UI): Intent review only
- Low (documentation, tests): Deterministic checks only
Bookmark this table. When someone asks "Do we need to review this PR?", check the risk level and follow the corresponding path.
