OWASP, NIST, and Human Approval for AI-Generated Code
A practical approach to auditing AI-generated code across security, business logic, and agile delivery using OWASP and NIST frameworks.
Aycan Altınöz · 2026-10-27 · Updated: 2026-10-27
Bringing OWASP and NIST Standards into the Agile Process
Auditing AI-generated code does not require inventing rules from scratch. OWASP provides a strong foundation for security, while NIST frameworks support governance and risk management. Our task is to place these frameworks into the team’s sprint rhythm, Definition of Done, and CI/CD pipeline.
OWASP Top 10 for LLM Applications (2026)
OWASP lists the ten most critical security risks for applications that include large language models. Because coding assistants and coding agents are LLM applications, these risks directly affect software teams. The most common examples in AI-assisted development include:
| OWASP risk | How it appears in a software team | Process control |
|---|---|---|
| LLM10 — Mishandling of outputs | Generated code or commands enter a shell, query, or template without validation | Static analysis and parameterized-query rule in the DoD |
| LLM04 — Supply chain | A package suggested by the assistant does not exist or comes from an untrusted source | SCA and approval step for new dependencies |
| LLM02 — Sensitive information disclosure | An API key or customer data enters a prompt or code | Secret scanning and data-use policy |
| LLM03 — Excessive agency | A coding agent has unnecessary access to the repository, pipeline, or production | Least privilege and human approval for irreversible actions |
| LLM07 — Systemic misinformation | An agent reports a nonexistent defect or produces code that only appears to work | Verification before action and mandatory tests |
If your team uses autonomous coding agents, review OWASP’s separate Top 10 list for agentic applications as well.
NIST AI Risk Management Framework and SSDF
NIST’s AI Risk Management Framework is built around four functions: Govern, Map, Measure, and Manage. NIST has also published the AI 600-1 profile for generative AI risks and prepared SP 800-218A to extend secure software development practices for generative AI.
We make these frameworks concrete in an agile team as follows:
| NIST function | Agile-team equivalent |
|---|---|
| Govern | Written AI-use policy, approved tool list, and clear responsibilities |
| Map | Identify where AI is used in the codebase and classify the risk of those areas |
| Measure | Regularly track change failure rate, security findings, and reverted changes |
| Manage | Review findings in retrospectives and update DoD and pipeline rules |
Security Auditing and Business-Logic Auditing
Two different questions must be asked of AI-generated code: Is the code secure, and does it do the right business job? Tools are highly useful for the first question; human judgment remains decisive for the second.
| Dimension | Security audit | Business-logic audit |
|---|---|---|
| Question | Does the code contain a vulnerability, leak, or risky dependency? | Does the code correctly implement acceptance criteria and business rules? |
| Reference | OWASP, NIST SSDF, and the organization’s security policy | User story, acceptance criteria, and domain knowledge |
| Automation level | High: SAST, SCA, and secret scanning | Low; tests help, but the decision belongs to people |
| Owner | Developer and security team | Developer and product owner |
| If missed | Security incident and compliance risk | Incorrect feature behavior, user loss, and business loss |
Manual Review, AI-Assisted Auditing, and Automated Scanning
| Dimension | Manual review | AI-assisted audit | Automated security scan |
|---|---|---|---|
| Strong at | Business logic, architectural fit, and context | Fast first review, explanation, and improvement suggestions | Known vulnerability patterns, dependencies, and secrets |
| Weak at | Slow and vulnerable to fatigue-related omissions | Can also be wrong and may lack context | Does not see business logic or new types of risk |
| Scales with volume? | No | Yes | Yes |
| Best use | Final decision in high-risk areas | First filter on every PR | Mandatory gate on every commit |
These three are not alternatives; they are layers. Automated scanning is the mandatory gate, AI-assisted auditing is the first filter, and human review is the final decision.
Human-in-the-Loop Audit Protocol
- Mark it: The developer states in the PR description that the code was generated or assisted by AI.
- Pass automated gates: Review starts only after static analysis, dependency scanning, and secret scanning are clean.
- Set the risk level: Changes touching authentication, payments, personal data, or infrastructure privileges are high risk.
- Use AI pre-review: AI review directs the reviewer’s attention as a first filter; it does not replace approval.
- Obtain human approval: Standard review is enough for low risk; senior developer and security approval are mandatory for high risk.
- Approve agent actions in their raw form: If an agent proposes an irreversible action such as delete, merge, or deploy, inspect the action itself rather than relying on the agent’s summary.
- Measure and feed back: Review production defects and security findings in retrospectives, then update the DoD and pipeline rules.
Frequently asked questions
Must every line of AI-generated code be reviewed by a person?
Yes, especially changes involving security, payments, authentication, personal data, or infrastructure privileges. AI review can be a first filter, but it cannot replace final human approval.
How can OWASP and NIST frameworks fit agile teams?
Connect the risks to sprint planning, Definition of Done criteria, and CI/CD quality gates. This puts security and governance inside the development flow rather than leaving them as a final check.
Does AI-assisted code review replace automated scanning?
No. Automated scanning detects known patterns and dependency risks; AI-assisted review explains and prioritizes; human review is needed for business logic and context.
How is a high-risk code change identified?
Changes involving authentication, payments, personal data, encryption, infrastructure privileges, or irreversible agent actions should be treated as high risk. Senior developer and security review should be required.
How should the audit process improve over time?
Measure production defects, security findings, and reverted changes after release. Feed retrospective findings back into the Definition of Done and pipeline rules.