AI governance should define where AI may generate code, what actions agents may take, and which approvals are required for high-risk behaviour. Application security should enforce those rules through scanning, policy controls, and runtime restrictions so the two programmes meet at execution time.
How to split the policy layer from the control layer
Teams get better results when AI governance owns the rules of use and application security owns the enforcement plane. Governance should decide which AI use cases are permitted, what kinds of code generation or agent actions are allowed, and what approvals are needed before high-impact behaviour goes live. Application security then turns those decisions into guardrails that are testable in pipelines and runtime.
The practical boundary is not “AI versus appsec”, it is policy definition versus technical control execution. If a rule cannot be scanned, blocked, logged, or restricted by the delivery and runtime stack, it is still a governance rule, but it is not yet an enforceable security control. That separation matters because teams often confuse acceptable-use language with a control that can actually stop unsafe code or agent behaviour.
For teams building agents or code assistants, Agentic AI Security Policy Template is a useful reference point for the governance side, because it frames registration, oversight, tools, monitoring and retirement as policy decisions before the control plane is designed. On the enforcement side, OWASP ASVS is the better fit for code and application controls because it anchors authentication, session, authorization and validation checks in build and test workflows.
What AI governance should own
AI governance should set the decision rights for AI use, not the implementation details of every safeguard. That means defining which models or copilots may be used, whether agents can execute tools, whether code can be generated automatically, and which classes of actions require human approval. It also means setting risk thresholds so teams know when a feature moves from low-risk assistance into higher-risk autonomous behaviour.
Good governance also establishes accountability. Someone must own the AI system, approve exceptions, and decide whether a use case can proceed with compensating controls. Without that ownership model, security teams end up policing business ambiguity after the fact, which is too late to prevent unsafe release patterns or uncontrolled agent expansion.
AI governance is strongest when it is expressed as policy that can be operationalised later. Clear rules about permitted data, tool access, escalation thresholds, and review gates give application security something concrete to enforce. Where organisations are formalising that layer, the NIST AI Risk Management Framework and ISO/IEC 42001:2023 AI Management System Standard both support the idea that AI requires organisational controls, accountability and ongoing risk management rather than one-time approval.
What application security should enforce
Application security should translate AI policy into controls that developers and platforms cannot bypass casually. That includes scanning generated code, restricting what the build pipeline can merge, gating dangerous dependencies, controlling outbound tool access, and blocking runtime actions that exceed the approved policy. In other words, appsec should enforce the boundary conditions of the AI system, especially where an agent can trigger code execution, access data, or invoke downstream services.
Appsec also owns the evidence that the policy is working. If governance says an agent cannot access sensitive systems, application security should be able to show the test, policy check, runtime restriction, or log record that proves the control held. That evidence is critical because “approved” is not the same as “safe in production”, especially when code generation and agentic workflows can change quickly.
NIST AI 600-1 GenAI Profile and NIST IR 8596 Cyber AI Profile help here because they connect AI risk to cybersecurity execution, while OWASP ASVS keeps the technical controls grounded in verifiable application-security requirements rather than broad policy language.
Risk and Threat Considerations
The main failure mode is a policy-control gap: governance says one thing, but the application stack does not actually prevent the unsafe behaviour. In that gap, developers may ship code generated under the wrong assumptions, agents may exceed their intended authority, and exceptions can become de facto permanent because nobody enforces them at runtime.
Failure mechanism: High-risk AI behaviour is approved at the policy layer without a corresponding technical control, so the organisation relies on intent instead of enforcement. That creates a path for unsafe code generation, excessive agent actions, and policy drift as the use case scales.
Impact: Teams lose the ability to prove that AI use stays within approved bounds, which increases the likelihood of insecure code, unauthorized actions, and inconsistent review outcomes across products or teams.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | AI actions and generated code must be constrained by enforceable authorization controls. |
| Recommendation — Map AI execution paths to V8 and enforce least-privilege authorization in the application stack. | ||
| NIST AI RMF | GV — Govern | The question is about assigning AI oversight and decision rights across teams. |
| Recommendation — Assign governance ownership for permitted AI use, approvals, and accountability. | ||
| ISO/IEC 42001:2023 | A.5.3 — Roles, responsibilities and authorities | Dividing AI governance from appsec depends on clear accountability and authority. |
| Recommendation — Define AI governance and security responsibilities with explicit role ownership. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Appsec enforcement should restrict agent and code actions to minimum necessary access. |
| AU-2 — Event Logging | Enforcement needs evidence that AI actions and policy decisions are observable. | |
| Recommendation — Apply least-privilege constraints to AI-driven actions and service access. Log AI-triggered actions and policy denials for audit and investigation. | ||
Practitioner Guidance
What to prioritise: Put the approval boundary in governance and the stop condition in application security. If a rule cannot be tested, blocked, or logged, treat it as a policy statement that still needs a control owner.
What to verify: Make sure every high-risk AI action has a concrete enforcement point, such as a pipeline gate, policy engine, or runtime restriction. The key test is whether a developer or agent can bypass the control without triggering an alert or denial.
Common mistake: Teams often let governance become a committee process and appsec become a checklist. The better model is governance defines the decision, appsec proves the decision is technically enforced in the places where code and actions actually happen.
Practitioner takeaway: Use AI governance to decide what is allowed, and use application security to make that decision real at build time and runtime; if either side works alone, the control fails at the seam.
Related resources from NHI Mgmt Group
- How should security teams divide responsibility between cloud providers and application owners in cloud native security?
- How should security and IAM teams divide responsibility for AI inventory governance?
- What is the difference between role-based access and API key governance for NHI security?
- How should security teams use IAST and RASP in NHI governance?