Why does AI create risk that traditional DevSecOps controls do not fully cover?

Why AI Changes the Security Boundary DevSecOps Was Built Around

Traditional DevSecOps assumes software behaviour is mostly deterministic: the same code path, configuration, and dependency state should produce the same outcome. AI breaks that assumption because training data, prompts, retrieval sources, model updates, and inference-time context can all change results without a code change. The security concern is not just whether a pipeline is hardened, but whether the system can be trusted when its outputs are probabilistic and its inputs are more fluid than a standard build artifact. That distinction matters for governance, validation, and incident response. In practice, many teams discover the gap only after a model is already embedded in a workflow that was never designed to challenge its inputs or explain its decisions.

For a broader control lens, the NIST Cybersecurity Framework 2.0 remains useful for organising governance, protection, detection, and recovery, but it does not by itself describe the AI-specific failure modes that sit inside those functions.

Where DevSecOps Still Helps, and Where AI Needs Extra Controls

DevSecOps still matters for the infrastructure around AI systems. Secure build pipelines, dependency checking, access control, logging, segregation of duties, and deployment approval all reduce ordinary software risk. The problem is that AI introduces additional control points that are not fully covered by those practices alone. A clean container image does not guarantee a trustworthy model. A signed release does not ensure the retrieval corpus is safe. A passing security scan does not prove the model will resist prompt manipulation or produce reliable outputs under adversarial context.

• Code and infrastructure controls mainly protect the application wrapper, not the model’s learned behaviour.
• Data controls must extend beyond source code into training sets, fine-tuning content, retrieval content, and feedback loops.
• Testing must include model misuse, prompt injection, unsafe output handling, and harmful reasoning paths.
• Monitoring must look for abnormal prompt patterns, unsafe responses, retrieval poisoning, and model drift.

That is why AI security needs an added layer of governance around model lifecycle, data provenance, and human review of high-impact outputs. Traditional CI/CD controls remain necessary, but they are no longer sufficient when the system’s behaviour is shaped by inputs and context that live outside the code repository. Where teams rely only on standard pipeline gates, the guidance breaks down once model behaviour changes faster than release management can track.

When the Usual Controls Stop Being Enough

Tighter AI governance often increases operational overhead, requiring organisations to balance faster experimentation against stronger validation and oversight. The hardest edge case is not a fully broken control set, but a control set that appears complete while missing the real failure path. A deployment can satisfy application security requirements and still inherit risk from poisoned training data, a compromised model dependency, or an unsafe prompt-handling pattern. Industry consensus is still forming on exactly how much assurance is enough for each AI use case, so teams should treat assurance depth as a function of impact, not as a one-size-fits-all checklist.

Another common edge case is indirect trust. A model may not directly expose credentials or infrastructure, yet it can still influence decisions, generate code, recommend actions, or retrieve content that creates security consequences elsewhere. That means the primary risk is often governance failure rather than simple technical compromise. Traditional DevSecOps is strongest when the question is, “Is the software shipped safely?” AI also asks, “Can we trust what the system learned, what it will produce next, and who is accountable when it is wrong?”

Risk and Threat Considerations

AI expands exposure in ways that conventional DevSecOps controls do not fully model. The main risk is not only software compromise, but manipulation of the training, prompting, retrieval, or output layers that shape system behaviour after deployment. That creates attack paths that can bypass code-centric assurance and move the problem into data integrity, trust abuse, and model misuse.

Failure mechanism: Attackers or insiders can poison training or retrieval data, manipulate prompts, exploit weak output filtering, or abuse third-party model dependencies so the system behaves unsafely without any obvious application-layer defect. Because the model can change its responses based on context, ordinary release gates may never see the harmful behaviour until it is exercised in production.

Impact: The result can be unsafe decisions, data leakage, supply-chain exposure, loss of decision confidence, or downstream compromise through generated code or instructions. In higher-stakes environments, the failure is often governance loss first and technical incident second.

Practitioner Guidance

What to prioritise: Treat AI security as an extension of software security, not a replacement for it. Start by identifying where the model can be influenced: training data, fine-tuning sources, retrieval content, prompts, tool access, and output consumption.

What to verify: Confirm that the control owner can show provenance for critical data, define acceptable model behaviour, and explain how unsafe outputs are detected, blocked, or escalated. If a team cannot describe those three things clearly, the AI control environment is not mature enough for high-impact use.

What practitioners underestimate: The most common blind spot is assuming that secure deployment equals secure behaviour. For AI systems, the release pipeline is only one checkpoint; assurance has to continue across data, model updates, and runtime use.

Practitioner takeaway: The practical test is whether your controls still work when the system changes its behaviour without changing its code.

Related resources from NHI Mgmt Group

• Why do agentic AI endpoints create new risk compared with traditional application controls?
• Why do AI deployments create new data security risk even when traditional cloud controls are in place?
• Why do code agents create more security risk than traditional AppSec controls can cover?
• Why do AI agents create a different access-risk profile than traditional applications?