TL;DR: Generative AI behaves probabilistically rather than deterministically, so the same prompt can produce different outputs as context, retrieval, or configuration changes, according to Noma Security. That means traditional software security assumptions do not hold, and AI-aware threat modeling and runtime controls are now a governance requirement.
Editorial analysis by NHI Mgmt Group, based on content published by Noma Security: “That’s a Great Question – AI Behaves Differently, How Should My Security Approach Change?”.
Key questions
Q: What breaks when security teams treat AI like traditional software?
A: The main failure is assuming the system will behave the same way every time.
Q: Why does AI-generated code still require strong security governance?
A: Because lower defect rates do not remove business context, deployment risk, or ownership.
Q: How do security teams know if agentic AI controls are failing?
A: The main signs are session drift, repeated retry loops, unauthorized tool calls, and behaviour that diverges from the documented task sequence.
Practitioner guidance
- Map every AI control that assumes determinism Identify where current testing, monitoring, and approval processes rely on a system producing the same output for the same input.
- Constrain model permissions and tool access Review which internal systems the model can query or act on, then reduce access to the minimum needed for each use case.
- Add runtime monitoring for behavioural drift Monitor for shifts in response quality, policy bypass, hallucination patterns, and unexpected access to sensitive information after deployments or tuning changes.
Bottom line: Generative AI breaks the assumption that the same input will always produce the same output, which makes traditional software control models incomplete.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Determinism is the wrong security assumption for generative AI: this class of system does not respond the same way every time, so the control model must shift from static validation to continuous behavioural governance. Security leaders who still treat AI like conventional code will miss failure states that emerge only under specific prompts, retrievals, or configuration states. The practical conclusion is that AI security has to be managed as an operating condition, not a one-time deployment task.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should boards ask before approving AI systems with tool access?
A: They should ask who can define the model’s permissions, what systems it can reach, how runtime behaviour is monitored, and what happens if the model generates unsafe actions or disclosures. The accountability question is whether the organisation can govern business impact after deployment, not just approve the model in advance.
👉 Read our full editorial: AI systems are not traditional software: why security models break