Because the AI system turns language, files, retrieved context, and tool access into behaviour. AppSec and cloud security still matter, but they do not test prompt injection, unsafe outputs, or whether an agent used authorised access for an unauthorised purpose. AI-specific controls close that gap at the interaction layer.
Why GenAI apps need a wider control plane than classic AppSec
GenAI changes the unit of risk. A normal application mostly consumes structured inputs and returns bounded outputs, but a GenAI app can turn prompts, retrieved documents, and model responses into actions, recommendations, or downstream tool calls. That means the control plane has to address not just code quality and cloud posture, but also prompt handling, output safety, and whether a seemingly valid request is being turned into an unsafe decision.
Classic AppSec is still necessary because the app and its APIs can be abused in familiar ways, but it is not sufficient on its own. A model can behave badly without any conventional vulnerability in the web tier, and a secure cloud deployment can still be used to generate harmful content, leak sensitive context, or follow manipulated instructions. The security question shifts from “is the app reachable?” to “is the system making the right action under the right constraints?”
That is why GenAI controls need to cover the interaction layer. Teams need explicit handling for prompt injection, retrieval poisoning, unsafe completion handling, policy enforcement around what the model may reveal or do, and guardrails on what enters and leaves the model context. The right control set treats model behaviour as a security concern, not just a product-quality issue, and OWASP ASVS remains useful only as one part of that larger picture.
Why agent controls have to govern authority, not just code
Agents add execution authority, which is the point where the problem becomes materially different from ordinary GenAI. Once an agent can browse, call APIs, update records, trigger workflows, or hand off to other systems, the main risk is no longer only unsafe text. It is unsafe use of legitimate access. An agent can act within its permissions and still create an outcome the human owner never intended.
That is why agent security has to bind identity, authorization, and task scope to each action. The key question is not simply whether the agent authenticated, but whether it had the minimum authority needed for that specific step and whether the step was allowed in context. AI Agent Authorisation Guide and Zero Trust for AI Agents both reflect that shift from static permission to per-action control.
In practice, this is where traditional cloud security stops short. Cloud controls can protect the workload boundary, network path, and storage layer, but they do not decide whether an agent should be allowed to read one customer account and then write to another, or whether an approved tool call becomes an unapproved business action. For that reason, agent controls must also address delegated authority, approval gates, least privilege, and traceable action boundaries. AI Agent Observability, Audit and Incident Response Guide is especially relevant when teams need to prove what the agent actually did, not just what it was allowed to access.
What GenAI controls add that AppSec and cloud controls cannot
GenAI-specific controls answer questions that AppSec and cloud security usually do not. They ask whether the model can be tricked by instructions hidden in retrieved content, whether memory or conversation state is leaking across users, whether tool use is isolated and attributable, and whether a policy can block an unsafe action even when the request arrived through a legitimate path. Those are different from buffer overflow, misconfiguration, or exposed bucket questions.
They also bring lifecycle concerns that are easy to miss. If an AI agent is registered, delegated authority, connected to tools, and then left in place after its role changes, the failure looks less like an app bug and more like unmanaged authority. Agentic AI Security Policy Template and Agentic AI Identity Guide are useful because they treat registration, ownership, access, and retirement as part of the security model, not an afterthought.
For teams building real deployments, the practical point is that you need controls across four layers at once: model input, model output, tool access, and operational oversight. Cloud and AppSec controls still protect the platform, but they do not by themselves stop prompt injection, constrain an agent from misusing a valid tool, or show when the system crossed from assistive behaviour into autonomous action. That is the gap GenAI control frameworks are meant to close. OWASP Agentic AI Top 10 and NIST AI 600-1 GenAI Profile both align to that broader control need.
Risk and Threat Considerations
GenAI systems create risk when the organisation assumes that a secure application and a secure cloud account automatically imply safe behaviour. The failure mode is usually a trust-boundary mistake: the system accepts untrusted language as instruction, allows retrieved content to steer behaviour, or lets a validly authenticated agent use its access for an unintended purpose.
Failure mechanism: Prompt injection, retrieval poisoning, unsafe tool invocation, or over-scoped agent authority can convert ordinary inputs into unauthorised actions, data exposure, or harmful outputs without breaking perimeter controls.
Impact: The organisation can lose confidentiality, integrity, auditability, and business control at the point where the model turns text into action. In the worst case, the system appears compliant at the infrastructure layer while still behaving unsafely at runtime.
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 addresses the attack and risk surface, while OWASP ASVS, NIST AI 600-1 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | GenAI apps still expose APIs that need request validation and access control. |
| V8 — Authorization | Agent actions need explicit authorization checks beyond basic app access. | |
| V16 — Security Logging and Error Handling | Agent behaviour must be logged so unsafe actions can be investigated and attributed. | |
| Recommendation — Verify API request handling and authorization for every model-backed endpoint. Enforce authorization at each action boundary, not just at login. Log model and agent actions with enough context to reconstruct decisions. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent misuse often comes from excessive or misapplied authority. |
| ASI02 — Tool Misuse | Agents can abuse legitimate tools even when the app itself is secure. | |
| ASI01 — Agent Goal Hijack | Prompt injection can redirect agent behaviour away from the intended task. | |
| Recommendation — Restrict agent privileges and bind each action to a verified principal. Gate tool calls with per-action policy and scope checks. Harden instructions and isolate untrusted content from agent goals. | ||
| NIST AI 600-1 | Generative AI Profile | The subject is specifically about GenAI controls beyond standard app and cloud security. |
| Recommendation — Use the GenAI profile to add controls for prompts, outputs, provenance, and incident handling. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agent authority must be limited to reduce misuse of valid access. |
| AU-2 — Audit Events | Agent actions need traceability so misuse and unsafe output can be investigated. | |
| IA-5 — Authenticator Management | GenAI systems rely on secrets and tokens that must be managed carefully. | |
| Recommendation — Grant each agent only the access required for the current task. Define audit events for prompts, tool calls, and high-risk agent actions. Rotate and protect credentials that let agents call tools or services. | ||
Practitioner Guidance
What to prioritise: Start by mapping which model outputs are advisory and which can trigger action, then put explicit policy gates on the action-bearing paths first. If the system can write, send, approve, or retrieve sensitive context, treat that path as a control boundary, not just a feature.
What to verify: Verify that every agent action is attributable to a specific principal, a specific task, and a specific permission set. Also verify that prompt and retrieval sources are separated from tool authority, so a poisoned document cannot silently become a command channel.
Common mistake: Teams often harden the app server, secure the cloud account, and then assume the GenAI layer is covered. The better test is whether the system can still be induced to do the wrong thing using valid interfaces and valid permissions.
Practitioner takeaway: For GenAI, the real security question is whether legitimate inputs can be turned into illegitimate behaviour, so the control model must extend from infrastructure protection to runtime authority, context handling, and action-level governance.
Related resources from NHI Mgmt Group
- How should security teams evaluate AI security software for GenAI apps and agents?
- Why do AI agents create gaps in existing cloud security controls?
- How should security teams extend segregation of duties controls across cloud procurement apps and ERP environments?
- How should security teams implement GDPR controls across web apps, APIs, and cloud services?