Start with inventory and approval. Security teams need to know which models, copilots, plugins, and AI-enabled dependencies are in use before they can assess exposure. Without that baseline, prompt controls, output checks, and runtime monitoring are applied too late and to the wrong assets.
Why the first move is inventory, not controls
When generative ai enters the SDLC, the first AppSec job is to establish what is actually in use: approved models, shadow copilots, plugins, SDKs, RAG components, and AI-enabled dependencies. That inventory gives security a defensible scope for review, rather than trying to bolt prompt rules and output filters onto assets that have not been identified or approved.
Inventory also clarifies where the AI capability sits in the delivery chain. A model used for code generation, a plugin that can reach internal data, and a build-time dependency that calls an external AI service create different exposure patterns, so they should not be assessed as one generic “AI risk.”
For teams formalising that baseline, the AI Supply Chain Security and AI-BOM Guide is useful because it frames the inventory as a supply-chain record, not just a list of tools. That matters when the real question is provenance, dependency visibility, and what can influence code or data before release.
What approval should cover before AI touches delivery work
Approval should decide whether the AI use case is allowed at all, and under what constraints. The practical questions are who owns it, what data it can see, whether the output is advisory or auto-applied, and whether any external service can retain prompts, code, or secrets.
This is where AppSec teams should distinguish between low-risk experimentation and production-adjacent usage. A sandbox coding assistant, a ticket summariser, and an AI agent with repository access do not deserve the same approval path, because their failure modes and blast radius are materially different.
For governance around autonomous or semi-autonomous tooling, the OWASP Agentic Applications Top 10 and the NIST AI 600-1 GenAI Profile both reinforce the need to define scope, control boundaries, and pre-deployment review before AI is allowed to affect operational assets.
Why late-stage prompt controls are the wrong first control
Prompt controls, output checks, and runtime monitoring still matter, but they are not the first line of defence. If the team has not identified which AI systems are in play, those controls get applied inconsistently, miss shadow usage, and often protect the wrong workflow while leaving the risky one untouched.
That is especially true where AI is embedded in development tooling. A code assistant may leak sensitive snippets into a third-party service, a plugin may fetch untrusted context, or an AI-enabled dependency may change the trust boundary without showing up in the usual AppSec review checklist.
The safer order is to approve the use case, inventory the components, then decide which controls are warranted at build time, runtime, and release time. The OWASP ASVS and the NIST SSDF (SP 800-218) are helpful here because they keep the focus on secure design, verification, and software integrity rather than treating AI as a standalone exception process.
Risk and Threat Considerations
Generative AI adopted before inventory and approval creates hidden exposure, because teams lose sight of which services can see source code, secrets, tickets, or customer data. That blind spot makes it easy for a permissive toolchain to become a data-leak path or an unreviewed code-generation dependency.
Failure mechanism: Shadow AI, unmanaged plugins, and third-party AI dependencies bypass normal SDLC review, so security controls are applied after sensitive material has already been exposed or after AI output has already influenced code or configuration.
Impact: The organisation can end up approving the wrong assets, missing data egress paths, and underestimating supply-chain and integrity risk, which weakens both release confidence and incident response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI 600-1, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI 600-1 | Generative AI Profile | GenAI in the SDLC needs pre-deployment governance and risk controls. |
| Recommendation — Use the GenAI profile to define approved use, testing, and disclosure before release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | AI-enabled SDLC changes architecture and verification needs. |
| V8 — Authorization | Plugins and AI tools can expand access to code, data, and build systems. | |
| Recommendation — Apply V15 to verify AI-assisted code paths and trust boundaries. Apply V8 to constrain AI tool access to only the permissions it needs. | ||
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | AI entering the SDLC requires structured exposure assessment before use. |
| CM-8 — System Component Inventory | The answer centers on inventorying AI models, copilots, plugins, and dependencies first. | |
| Recommendation — Perform RA-3 style assessments before approving AI in delivery workflows. Use CM-8 to maintain an authoritative inventory of AI-enabled SDLC components. | ||
Practitioner Guidance
What to prioritise: Build the AI inventory first, and require a named owner and business purpose for every model, plugin, assistant, or AI-enabled dependency before it is allowed into a delivery pipeline. If a tool cannot be inventoried, it should not be treated as approved.
What to verify: Confirm what data the AI system can access, where prompts and outputs are stored, whether retention is enabled, and whether the service can reach repositories, build systems, or secrets stores. That verification is more valuable than a generic policy statement.
Practitioner takeaway: In AppSec, the first AI control is scope control, if you do not know what has entered the SDLC, every later safeguard is partially blind.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams handle risks from AI browser extensions?
- What should security teams review first when IT starts using AI to drive business outcomes?
- How should security teams adapt AppSec controls when AI starts compressing the development lifecycle?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org