Because user language and retrieved context become part of the operating state. A GenAI system can behave differently on each interaction, so malicious prompts, sensitive documents or changing tool results can alter the outcome after approval. That makes continuous control more important than a one-time model review.
Why GenAI Has a Wider Attack Surface Than Static Logic
Static application logic usually follows a fixed decision path: same input, same code path, same expected class of outcome. GenAI systems are different because the prompt, retrieved context, conversation history and tool outputs all influence the next action. That means the system is partly defined at runtime, which expands the set of things that can change behaviour after deployment.
In practice, that makes the security boundary less about a single approved model and more about the whole operating context around it. A malicious prompt, an untrusted document, or a poisoned retrieval result can shift what the system says or does without any code change. The risk is not only incorrect output, but also incorrect action when the model is allowed to call tools or trigger workflows.
That is why GenAI should be treated as a dynamic control surface, not just an application feature. The model may be stable, but the surrounding context is not, and the security posture must account for that moving state.
Why Approval Is Not Enough for GenAI Behaviour
With static logic, a one-time review of code and rules often captures most of the material risk, provided inputs are well constrained. GenAI does not give that same assurance because the same approved system can produce different outcomes as context changes. If retrieval sources, prompts, or downstream tools are allowed to vary, the effective behaviour changes even when the deployed model version does not.
That is why review must extend beyond the model itself to the whole interaction path. Prompt handling, context filtering, retrieval quality, tool permissions and output handling all influence whether the system stays within acceptable bounds. Current guidance from NIST AI 600-1 GenAI Profile reflects that reality by treating governance, provenance, testing and incident handling as part of the control model, not as afterthoughts.
Because the state can change every turn, a GenAI system needs continuous validation of the inputs it consumes and the actions it is allowed to take. Static logic can often be certified by design alone; GenAI usually cannot.
What Changes When GenAI Can Read, Retrieve and Act
The main risk multiplier is not generation by itself, but generation plus access. Once a GenAI system can read internal content, retrieve external material, or call tools, it can inherit the trust issues of each connected system. Sensitive documents can leak into context, retrieved material can steer the answer, and tool results can become the basis for the next step in a workflow.
That is why GenAI security often overlaps with application control, access control and data handling. If the system can surface confidential material, execute a function, or relay a command to another service, you have to evaluate what an attacker can influence and what the model is trusted to do with it. A useful internal reference on this pattern is OmniGPT breach claim 2025, which illustrates how prompts, chat content and exposed secrets can converge into a larger data-risk problem.
This is also why GenAI risk scales with privilege. The more context, tool access and downstream authority the system has, the more a bad prompt or bad document can matter. In other words, the model does not need to be “hacked” in the classic sense for the business outcome to be compromised.
Risk and Threat Considerations
GenAI systems increase exposure because they accept untrusted natural language and dynamic context as part of the operating state. That creates a persistent opportunity for prompt injection, data leakage, retrieval poisoning and unsafe tool use, especially when the system can act on behalf of a user or process.
Failure mechanism: An attacker, untrusted document, or poisoned retrieval source influences the context that the model uses to choose content or trigger actions, bypassing the assumption that the system is behaving on a fixed rule set.
Impact: The result can be disclosure of sensitive information, incorrect decisions, unauthorized actions, or chained failures in downstream systems that trusted the model output.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | GenAI systems must constrain untrusted prompts and retrieved context. |
| AC-6 — Least Privilege | GenAI tool access and downstream authority determine blast radius. | |
| Recommendation — Validate prompts, retrieved content, and tool inputs before they influence model actions. Limit tool and data access to the minimum authority needed for each workflow. | ||
| NIST AI RMF | Govern | GenAI risk depends on governance, provenance, and ongoing control of changing context. |
| Recommendation — Establish AI governance for context sources, approvals, monitoring, and incident response. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | GenAI systems that can call tools face misuse when prompts or context steer actions. |
| Recommendation — Restrict and monitor tool invocation so model output cannot trigger unsafe actions. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | GenAI integrations often fail through overly broad access and unsafe configuration. |
| Recommendation — Harden GenAI integrations with explicit authorization, scoped access, and safe defaults. | ||
Practitioner Guidance
What to prioritise: Treat context sources and tool permissions as first-class security controls. If the system can read it, retrieve it, or call it, assume it can influence behaviour and must be governed accordingly.
What to verify: Verify which inputs are allowed into the prompt, which retrieval sources are trusted, and which tools can be invoked without human review. The key question is not whether the model is approved, but whether the surrounding state can be manipulated.
What good looks like: The system can explain why a given context item was used, which tool result it consumed, and what guardrails constrained the action. If you cannot observe that path, you do not really control it.
Practitioner takeaway: GenAI risk is higher than static logic because behaviour is co-authored at runtime by users, data and tools, so security must be continuous, contextual and observable rather than a one-time release decision.
Related resources from NHI Mgmt Group
- Why do retrieval augmented generation systems create more security risk than static application workflows?
- Why do unauthenticated application exploits create so much more risk in ERP systems?
- Why do static secrets create more risk in distributed systems?
- Why do AI workloads create more runtime risk than static application scans capture?