Security teams should start with existing controls for access control, data protection, monitoring, and supply chain hygiene, then add AI specific controls where the model introduces new risk. The practical goal is not to replace mature security. It is to extend it for data driven behavior, model adaptation, and interconnected AI components that can change the attack surface after deployment.
How to extend mature controls without starting from zero
AI changes the control problem because the system can shape its own inputs, outputs, and sometimes its next action based on data it has seen or generated. That means the safest adaptation is usually to treat AI as a new trust boundary around existing controls, not as a reason to discard them. Access control still matters, but now it must cover prompts, tools, model endpoints, retrieved context, and downstream actions as a single chain of authority.
Data protection also becomes more dynamic. Traditional controls assume a clearer boundary between source data and application behaviour, but AI systems can expose sensitive data through retrieval, memorisation, logging, or inference. Security teams should map where data is ingested, transformed, retained, and reused, then decide which parts need stricter classification, masking, retention limits, or review.
Monitoring and supply chain hygiene remain foundational, but the things being monitored change. For example, model updates, embeddings, plugins, orchestration code, and external tools can introduce new failure points after deployment. The practical adaptation is to extend existing control families so they observe AI-specific inputs and dependencies, rather than creating a parallel security programme that duplicates governance and leaves gaps between teams.
Where traditional controls need AI-specific extension
AI systems most often force new control work in three places: data flow, autonomy, and composition. Data flow matters because models can ingest content from users, documents, APIs, and retrieved sources, which makes contamination and leakage risks harder to see. Autonomy matters because a model may be allowed to choose a next step, call a tool, or trigger a workflow. Composition matters because the system may depend on multiple models, services, and vendors that each expand the attack surface.
That is why mature controls should be translated into AI terms. Change control should cover model versioning and prompt/template updates. Logging should capture prompt, retrieval, tool-use, and decision context where appropriate. Third-party review should extend to model providers, orchestration layers, and any external component that can influence outputs or actions. The objective is continuity of control intent, not identical implementation.
In practice, security teams get better outcomes when they ask a simple question of every existing control: does AI change what must be approved, what must be observed, or what can fail silently? If yes, the control should be extended at that point. If not, the existing control probably already does the job. That keeps the response proportionate and avoids inventing bespoke controls where a stronger general control already exists. For AI-specific threat modelling context, MITRE ATLAS adversarial AI threat matrix is a useful reference, especially where prompt injection, tool misuse, or agent hijacking become material.
Risk and Threat Considerations
AI introduces risk when a system can be influenced through inputs that look legitimate but change behaviour, decisions, or downstream actions in unintended ways. The main exposure is not just data leakage, but control bypass through model behaviour, retrieval poisoning, prompt injection, tool abuse, or over-trusting generated output.
Failure mechanism: A model or agent accepts untrusted content as instruction, context, or evidence, then uses that influence to retrieve, reveal, or act on information beyond its intended authority. Supply chain dependency risk increases when third-party models, plugins, or orchestration layers can change behaviour after deployment.
Impact: Security teams can lose visibility into why an action happened, data can flow to the wrong place, and the system can create new privilege paths that were never present in traditional software. In the worst case, compromise of the AI layer becomes a shortcut into adjacent systems that were assumed to be protected by conventional application controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Govern | AI control extension needs governance, ownership, and policy decisions across the system lifecycle. |
| PR.AC — Access Control | AI introduces new access paths through prompts, tools, retrieval, and automated actions. | |
| DE.CM — Continuous Monitoring | AI systems need monitoring of prompts, outputs, tool use, and dependency changes to spot misuse. | |
| Recommendation — Assign governance for AI-specific control gaps and enforce review of model, data, and vendor changes. Extend access control to cover model inputs, tool calls, and action approval boundaries. Monitor AI behavior, retrieval activity, and tool execution for anomalous or unsafe changes. | ||
| CIS Controls v8 | 5 — Account Management | AI systems often use service accounts and automation paths that need explicit authorization and review. |
| 3 — Data Protection | AI can expose or transform sensitive data through retrieval, logging, memorization, and output. | |
| 8 — Audit Log Management | AI decisions and tool actions need logs that preserve traceability for investigation and control validation. | |
| Recommendation — Review and restrict accounts, tokens, and service access used by AI workflows. Classify, minimize, and protect data that enters or leaves AI workflows. Log model inputs, retrievals, tool calls, and high-risk outputs for review. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | AI endpoints and orchestration layers can be abused through externally reachable interfaces. |
| T1195 — Supply Chain Compromise | AI systems depend on models, plugins, and code updates that can be compromised upstream. | |
| Recommendation — Harden and monitor exposed AI interfaces that attackers can directly interact with. Vet AI suppliers and update paths for tampering, injection, or malicious dependency changes. | ||
| NIST AI RMF | GOV — Govern | AI risk management requires defined accountability and control objectives for model-driven behavior. |
| Recommendation — Set AI governance responsibilities for acceptable use, oversight, and escalation. | ||
Practitioner Guidance
What to prioritise: Start by inventorying the AI system’s trust boundaries, then classify which existing controls still hold and which must be extended. The highest-value first pass is usually prompt and retrieval governance, tool and action authorization, logging of model-mediated decisions, and vendor dependency review.
What to verify: Validate that security controls cover not only the application front end, but also the model endpoint, retrieval layer, external tools, and any automation that executes model output. If a control cannot show what the model saw, what it used, and what it was allowed to do, it is probably too weak for production AI use.
Practitioner takeaway: Treat AI as a control-extension problem, not a control-replacement problem. Mature security still does most of the work, but it must be widened to cover model influence, mediated actions, and post-deployment dependency change.
Related resources from NHI Mgmt Group
- Why do AI systems need threat modelling and security controls earlier than traditional software projects?
- How should security teams adapt software supply chain controls to meet new federal cybersecurity requirements?
- Why do AI systems complicate traditional data security controls?
- How should security teams expose APIs to AI systems without creating unsafe access paths?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
