Who should be accountable for approving GenAI use in development workflows?

Why This Matters for Security Teams

Approval for GenAI in development workflows is not a paperwork exercise. It determines who can introduce model output into code, who can expose source material to external services, and who accepts the risk when a prompt, plugin, or generated dependency creates a security issue. The wrong owner leaves teams with informal use, inconsistent review, and no clear stop point when sensitive data is involved.

Current guidance from the NIST AI 600-1 GenAI Profile and NIST AI 600-1 GenAI Profile points toward governance that is explicit, documented, and tied to risk decisions rather than individual experimentation. That matters because GenAI usage in development often leaks into code review, issue triage, test generation, and secrets handling before leaders notice. NHIMG research on the State of Secrets in AppSec shows 43% of security professionals are already concerned that AI systems can learn and reproduce sensitive information patterns from codebases.

In practice, many security teams encounter GenAI risk only after a model has already seen sensitive code, rather than through intentional approval and control design.

How It Works in Practice

Accountability should usually sit with the application owner and the security leader who can approve the workflow, define acceptable data use, and enforce review gates. Developer teams can propose use cases and operate within policy, but they should not be the final risk acceptor when GenAI touches production code, proprietary logic, secrets, or regulated data. That separation matters because development workflows are not static. A developer may use a chatbot for documentation one day, then ask it to refactor authentication code the next.

A workable approval model typically includes:

• defined allowed and prohibited use cases for GenAI in coding, testing, and review;
• data-classification rules that block source, secrets, or customer data from being sent to external models;
• explicit approval for tools, extensions, and model endpoints before use in CI/CD;
• logging and periodic review of prompts, outputs, and exceptions;
• escalation paths when the model touches credentials, security controls, or regulated material.

That approach aligns with the control emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects accountable governance around access, configuration, and monitoring. It also fits the risk posture discussed in DeepSeek breach, where exposed information and model-related data handling showed how quickly AI misuse can become a security incident. The practical test is simple: if a GenAI tool can influence code or see sensitive context, there must be a named approver who can say yes, no, or stop. These controls tend to break down in fast-moving CI/CD environments because teams treat model access as a productivity choice instead of a governed production dependency.

Common Variations and Edge Cases

Tighter approval usually increases workflow friction, so organisations have to balance developer speed against control assurance. That tradeoff is real, especially where teams use multiple models, third-party extensions, or locally hosted assistants.

Best practice is evolving for lower-risk uses such as non-sensitive documentation drafting or generic code explanation. In those cases, some organisations permit broad use with policy reminders and lightweight review. Higher-risk cases need stronger sign-off, especially when GenAI can touch secrets, infrastructure code, customer data, or regulated records. This is where approval should shift from a team norm to a named governance decision.

Edge cases also appear when a model is embedded into a developer platform rather than used as a standalone chat tool. The approval question then includes the platform owner, the security reviewer, and sometimes the data protection function if training or retention terms are unclear. NHIMG’s coverage of the GitHub Action tj-actions Supply Chain Attack is a useful reminder that development tooling can become an attack path quickly when trust is assumed instead of approved. There is no universal standard for this yet, but current guidance suggests treating GenAI like any other high-impact development capability: approved by accountable leaders, bounded by policy, and reviewed when the use case changes.

Related resources from NHI Mgmt Group

• Who is accountable when fraud shifts into fulfilment, returns, or dispute workflows?
• Who is accountable when inactive approvers stall access request workflows?
• Who is accountable for secure workload credential handling when federated access and automatic refresh are in use?
• Who should be accountable for access governance when enterprise API tools use SCIM, domain capture, and domain lock together?