GenAI creates risk because it combines traditional application weaknesses with AI-specific attack paths and a much larger dependency chain. LLM systems rely on external models, datasets, plugins, and connected business applications, so misconfigurations, poisoned data, insecure access, and supply chain exposure can all become entry points. That makes the threat model broader than standard application security.
Why Familiar Stacks Still Expand the Attack Surface
GenAI does not replace the application, it adds a new trust layer on top of it. The web app, API gateway, IAM, databases, and CI/CD pipeline may all look familiar, but the model introduces prompt handling, retrieval, tool invocation, and model-provider dependencies that behave differently from standard application code.
The practical difference is that normal app controls now protect more than user input and business logic. They also have to protect model context, retrieval results, orchestration logic, and the instructions that decide which downstream systems the application can call. That widens the blast radius of a simple security mistake.
One reason this matters is that the familiar stack is often connected to unfamiliar failure modes, such as prompt injection, tool abuse, context poisoning, and misaligned output handling. Those issues can bypass assumptions that are valid in conventional software, where input validation and authorization logic are usually the main gates.
For a broader map of how these risks change the security model, the NIST AI 600-1 Generative AI Profile frames the governance and testing expectations that sit around GenAI deployments, while the OWASP Top 10 for Agentic Applications 2026 and CSA MAESTRO agentic AI threat modeling framework are useful when the application can act, call tools, or orchestrate other systems.
Where the New Risk Comes From
GenAI risk is not only about the model. It also comes from the dependency chain around the model, including prompts, embeddings, vector stores, external APIs, plugins, retrieval sources, and business systems that receive model output as if it were trustworthy. Each added dependency creates another place where data can be manipulated, credentials can be abused, or unsafe actions can be triggered.
That is why a GenAI application can inherit ordinary software weaknesses and still be materially riskier than its non-AI equivalent. A SQL injection issue, exposed secret, or overly broad access rule is already dangerous on its own. In GenAI systems, the same weakness can be chained with model misuse or tool invocation to create unauthorized actions, data exposure, or integrity loss.
Operationally, the biggest mistake is treating the model as an isolated feature instead of part of a distributed system. If the model can retrieve from internal content, send actions to a ticketing system, query customer records, or execute workflows, then the application is no longer just generating text. It is making decisions that can affect production systems.
The strongest internal references for this broader dependency story are OWASP NHI Top 10, which covers agentic attack surface and privilege abuse, and The agentic AI applications guide, which is useful for understanding agent identity, lifecycle, and orchestration risk. For secret exposure patterns, Docker Hub Auth Secrets in Container Images shows how credentials embedded in normal delivery pipelines become a persistent weakness.
What Practitioners Should Test Before Trusting the System
GenAI should be assessed as a control boundary, not just as an application feature. That means testing whether prompts can be manipulated, whether retrieved content is trusted too easily, whether tool calls are bounded by policy, and whether the system can safely fail closed when model output is ambiguous or adversarial.
- Verify that the model cannot reach systems, scopes, or environments that are not explicitly required.
- Check whether retrieved data and external tool outputs are treated as untrusted inputs.
- Confirm that human approvals exist for actions with material business impact.
- Review whether logging captures the prompt, retrieval source, tool call, and final action for investigation.
Where the application depends on credentials, tokens, or API keys, the risk posture is even more sensitive. The relevant question is not only whether the stack is patched, but whether secret handling, rotation, and authorization are designed for a system that may generate or trigger actions dynamically. For that reason, the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 are useful when GenAI systems inherit service credentials, third-party integrations, and operational dependencies that need governance across the full lifecycle.
Practitioner Guidance: Treat GenAI as a trust-amplifying layer, not a novelty feature. If the system can retrieve, decide, or act, prioritize authorization boundaries, tool restrictions, and secret hygiene before tuning prompts or model quality.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI 600-1, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI 600-1 | GENAI PROFILE — Generative AI Profile | GenAI systems need governance, testing, and risk controls around model use and deployment. |
| Recommendation — Apply the GenAI Profile to govern testing, provenance, and incident handling for model-driven features. | ||
| OWASP Agentic AI Top 10 | A1 — Agent Goal Hijacking | Prompt and instruction manipulation can redirect agent behaviour and unsafe tool use. |
| A2 — Tool Misuse | GenAI apps often invoke tools, so tool abuse is a direct attack path. | |
| Recommendation — Harden prompts, tool policies, and approvals against goal hijacking. Restrict tool scopes and validate every action that the model can trigger. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl | GenAI stacks often expose API keys, tokens, and credentials across many components. |
| NHI-03 — Overprivilege | Model-connected services can inherit excessive access that widens blast radius. | |
| Recommendation — Centralize secrets and remove long-lived credentials from code and pipelines. Reduce service permissions to the minimum required for each model workflow. | ||
| NIST CSF 2.0 | PR.AC — Access Control | GenAI introduces new access boundaries around tools, data, and downstream systems. |
| Recommendation — Enforce access boundaries for model inputs, tools, and connected systems. | ||
| CIS Controls v8 | 6 — Access Control Management | GenAI environments need tight control over who and what can access sensitive resources. |
| Recommendation — Limit and review access for the services and identities used by GenAI applications. | ||
Related resources from NHI Mgmt Group
- Why do agent registration protocols create new IAM risk even when they use OAuth?
- Why do AI coding agents create security risk even when they use the same model?
- Why do software suites create operational risk even when they simplify security operations?
- Why do GenAI applications create new security and legal risk for organisations?
