Extend existing IAM, PAM, data protection, and application security controls first. Separate AI-specific controls only make sense where the technology introduces behaviour those controls cannot express, such as continuous discovery or AI-specific testing. The practical goal is governance continuity, not policy duplication, so the programme remains coherent as AI usage expands.
How to decide whether AI needs separate controls or just stronger existing ones
The cleanest answer is to treat AI as a new workload class, not a new governance universe. If your current IAM, PAM, data protection, logging, and application security controls already describe the risk, extend them and tighten enforcement. Only add AI-specific controls where the system introduces runtime behaviour, autonomy, or model-specific failure modes that your existing policy language cannot express.
That usually means keeping policy continuity at the control-object level, while adding AI-specific operating rules at the implementation layer. For example, a model that can call tools or access data still needs standard authentication, authorization, segmentation, and secret handling, but you may also need AI-specific registration, monitoring, testing, or human-approval conditions.
The practical test is whether the control gap is structural or just naming. If the issue is that service access is too broad, the right fix is better privilege design, not a parallel AI policy. If the issue is that model behaviour changes after prompts, tools, or context injection, you need an additional control pattern because the existing policy was never designed to govern that behaviour directly. For control continuity, see Ultimate Guide to NHIs — Standards for the underlying identity and control model, and NIST Cybersecurity Framework 2.0 for a broad control structure teams can extend.
Where existing IAM, PAM, and data policies already do most of the work
Most organisations should start by mapping AI systems onto the controls they already use for users, services, and sensitive data. IAM still governs who can use the system, PAM still governs elevated access and approvals, and data policy still governs what information can be exposed, retained, or exported. That is especially true when the AI system is mostly consuming APIs, documents, or workflow data rather than making autonomous decisions.
This approach reduces duplication and makes ownership clearer. Security teams already know how to review access paths, rotate credentials, enforce least privilege, and classify information, so those mechanisms should be reused wherever the AI stack depends on them. A separate AI policy is only justified when it adds a decision the older controls cannot make, such as whether an agent may self-select tools, persist memory, or act without a human in the loop.
Where the main risk is data leakage or overbroad access, the better move is to apply stronger control hygiene, not create a second policy stack. That includes tighter data minimisation, stricter production access, better secrets handling, and clearer separation between training, testing, and live operational data. NHI Lifecycle Management Guide is useful here because lifecycle discipline, ownership, and offboarding remain the same governance problems even when the workload is AI-driven.
For cloud-hosted and vendor-hosted AI services, the same logic applies to configuration and third-party risk. Existing controls around accounts, tokens, logging, and vendor access should be the first line of defence, with AI-specific requirements layered on only where model behaviour or agent autonomy creates a distinct gap. The operational goal is fewer exceptions, not a second set of controls that say the same thing in different language.
When AI-specific controls are justified, and what they should cover
AI-specific controls become necessary when the system can behave in ways normal IAM or data policy cannot fully describe. Typical examples are continuous discovery of models and agents, prompt or tool abuse, model-context poisoning, autonomous action chains, or specialised testing for harmful outputs and unsafe tool use. In those cases, a separate control exists because the failure mode is different, not because AI deserves special treatment by default.
That does not mean starting from scratch. It means adding only the missing control dimension: registration of AI assets, ownership of agents, approved tool boundaries, model- and prompt-specific testing, runtime monitoring, and retirement or decommissioning rules. These controls should sit beside, not instead of, your existing access and data controls. If an AI system can access production systems, the identity and privilege controls remain foundational; the AI-specific layer only governs the extra behaviour introduced by the agentic workflow.
Security teams often overbuild here by creating a standalone AI policy that duplicates access, data, and acceptable-use rules already covered elsewhere. A more durable pattern is one governing policy with AI-specific standards or procedures underneath it, so the organisation keeps one source of truth. Agentic AI Security Policy Template is a practical example of how registration, identity, oversight, tools, monitoring, and retirement can be formalised without breaking policy coherence.
Risk and Threat Considerations
The main risk in splitting AI controls too early is governance fragmentation. Teams end up with overlapping rules for identity, data, and AI behaviour, which creates gaps, exceptions, and conflicting approvals. The opposite risk is under-controlling autonomous or tool-using systems, where existing policies assume static users and predictable workflows.
Failure mechanism: The control framework fails when the organisation treats AI as either completely ordinary software or as a special category that needs a separate rulebook for everything. In the first case, runtime AI behaviour slips through existing policy language; in the second, ownership and enforcement fragment across duplicated controls.
Impact: The result is inconsistent access decisions, weaker accountability, and a higher chance that AI systems will be overprivileged, misconfigured, or allowed to operate outside approved data and action boundaries. That increases the chance of data exposure, unsafe actions, and harder-to-investigate incidents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01 — Policy | AI control design is fundamentally a policy-architecture decision across existing and AI-specific controls. |
| Recommendation — Use a single policy spine and define AI-specific exceptions only where existing controls cannot express the risk. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | AI services and agents still depend on service-to-service authentication and authorization boundaries. |
| AC-6 — Least Privilege | The main risk is overbroad access, regardless of whether the workload is AI-driven or conventional. | |
| AU-2 — Event Logging | AI systems need auditable actions and traceability when runtime behaviour expands the attack surface. | |
| Recommendation — Apply service authentication controls before adding AI-specific governance layers. Reduce AI workload privileges to the minimum needed for approved actions. Log AI actions, tool calls, and privileged events so investigations can reconstruct behaviour. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Existing access control policy should be extended before creating separate AI-only rules. |
| Recommendation — Extend the access control policy to cover AI-enabled workflows and tool use. | ||
Practitioner Guidance
What to prioritise: Start by mapping AI use cases to the controls you already enforce for identities, privileges, secrets, logging, and sensitive data. If a control already governs the risk, extend it rather than replacing it with an AI-only version.
Decision rule: If the AI system changes who can act, what it can access, or how it behaves at runtime, keep the existing control and add an AI-specific procedure only for the missing behaviour. If the issue is ordinary access or data misuse, fix the base control first.
What to verify: Confirm that every AI system has a named owner, a clear access path, defined tool boundaries, and an auditable offboarding path. If you cannot explain these in the same governance language you use for other systems, the programme is not yet coherent.
Practitioner takeaway: The best operating model is usually one control spine with AI-specific extensions, not parallel governance tracks that force teams to maintain two versions of the same security truth.
Related resources from NHI Mgmt Group
- How should security teams extend data protection to AI interactions without replacing existing controls?
- How should security teams extend existing DLP policies to AI prompts without creating a separate control stack?
- How do security teams align AI governance with existing IAM and data security programmes?
- How should security teams build data controls into AI applications and pipelines from the start?