Securing AI requires separate controls for threats, models and operations

At a glance

What this is: This is an independent framework for separating AI security into three control domains: threats from AI, security of AI systems, and security operations with AI.

Why it matters: It matters because IAM, PAM, and governance teams must treat AI agents, model integrations, and decision workflows as governed access surfaces, not just automation features.

👉 Read Anomali's framework for securing AI from, in and with AI

Context

AI security fails when teams treat it as a single control problem. In practice, the risks split into three distinct domains: threats powered by AI, the security of AI systems themselves, and the use of AI inside defensive operations. That distinction is especially important where AI agents, model pipelines, and integrations create new identity, access, and audit requirements.

For identity and governance teams, the key issue is not whether AI is present but where privilege, decisioning, and accountability now sit. When agents can access tools, data sources, and workflows, their permissions become part of the security model, and the same applies to human review, logging, and third-party oversight.

Key questions

Q: How should security teams govern AI systems that can act without human approval?

A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review. That means tightly scoping tools, data, and actions; logging every material step; and making revocation and containment available while the session is still active. Static policy alone does not control machine-paced execution.

Q: Why do AI agents increase IAM and PAM risk?

A: AI agents increase IAM and PAM risk because they can execute actions quickly once privilege is available, which shortens the time available to detect misuse. If access is always on, the attack surface is always on too. That is why task-scoped privilege and ownership controls matter.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: What is the difference between securing AI and using AI for security?

A: Securing AI protects models, data, and pipelines from attack. Using AI for security applies machine learning to improve detection, prioritisation, and response. Both matter, but they solve different problems. A mature programme needs controls for the AI system itself, not only AI-assisted security operations.

Technical breakdown

Securing from AI: how AI compresses attack time

AI-assisted threat activity changes the tempo of attack. It improves social engineering quality, scales reconnaissance, and speeds variant generation, which means defenders have less time to validate intent, correlate alerts, and respond manually. The control problem is not that AI creates a new class of attack in every case, but that it makes familiar attack patterns faster and more adaptive. Security programmes that still depend on human bottlenecks will struggle to keep pace, especially when triage and containment require multiple handoffs. The operational question is therefore not whether to automate, but where automation can reduce delay without creating blind trust.

Practical implication: map high-volume threat paths to automated detection and response steps before human review becomes the limiting factor.

Securing the AI: model inventories, agent permissions and auditability

Securing the AI means treating models, agents, integrations, and third-party dependencies as assets with explicit governance. That includes knowing what is deployed, what data it touches, what tools it can invoke, and which decisions it can influence. In agentic environments, permissions are the core control surface because the agent is not just generating output, it is executing actions through connected systems. Auditability matters because security teams need traceability for model behaviour, tool calls, and delegated actions. Without those records, incident response, compliance review, and root-cause analysis all become partial exercises.

Practical implication: maintain an inventory of AI systems, their delegated access, and their logging coverage before expanding use cases.

Securing with AI: using AI to improve security operations

Using AI with security operations only helps if it improves outcomes rather than simply increasing alert volume. The relevant measures are faster triage, better correlation, lower mean time to detect, and more consistent workflows across large data sets. This is an operational pattern, not a model risk issue, but it still depends on governance because the output of AI-assisted workflows can influence containment decisions. Teams should separate assistance from authority. AI can enrich context and prioritise work, but it should not become an unchecked decision layer in the response chain.

Practical implication: define where AI can assist analysts and where human approval remains mandatory in SOC workflows.

Threat narrative

Attacker objective: The attacker aims to overwhelm manual response processes and improve the odds of successful compromise before defenders can contain the event.

1. Entry begins with AI-assisted reconnaissance, social engineering, or automated targeting that increases the speed and precision of initial compromise attempts.
2. Escalation occurs when defenders rely on human-only triage and cannot respond as quickly as AI-enhanced attack cycles evolve.
3. Impact is the compression of detection and containment windows, which increases the likelihood of successful compromise, spread, or data loss.

NHI Mgmt Group analysis

AI security is now a governance segmentation problem, not a single control domain. Treating threats from AI, security of AI, and security with AI as one programme obscures ownership, metrics, and control design. Each domain needs different success criteria, different control owners, and different audit evidence. Security leaders who fail to separate them will overinvest in one area while leaving another structurally under-controlled. The practical conclusion is to govern AI by risk domain, not by label.

Agent permissions are becoming the new control plane for enterprise AI. Once an AI system can invoke tools, query data, or trigger workflows, its access scope matters as much as its output quality. That creates a direct intersection with IAM and PAM because delegated access, service credentials, and approval boundaries now govern machine action. Programmes that do not inventory and constrain those permissions are effectively allowing runtime privilege expansion. The practical conclusion is to apply identity controls to AI systems the same way you would to any high-risk workload.

AI governance debt: rapid experimentation without inventories, audit trails, and ownership creates a compounding control deficit that becomes expensive to unwind. The article reflects a market shift from ad hoc AI adoption to documented governance, which is where many programmes discover they are behind. That debt shows up in missing lineage, unclear delegation, and weak incident evidence. Governance teams should treat this as an accumulated exposure, not a future concern. The practical conclusion is to measure governance completeness before scale increases further.

Auditability is the dividing line between usable automation and ungoverned autonomy. In regulated and high-impact environments, teams need evidence of what the system accessed, what it decided, and what it changed. That is not a compliance afterthought, because it is also the basis for containment, investigation, and assurance. AI systems without traceability are not fully operationally safe, even if they appear performant. The practical conclusion is to make audit evidence a deployment requirement, not a retrospective control.

What this signals

Agentic growth is outpacing governance maturity. The practical signal for security leaders is that AI adoption will keep widening before control coverage catches up, so inventories, delegation boundaries, and auditability need to become deployment prerequisites. That gap is where identity governance becomes operational, because an agent with tool access is a governed identity whether teams label it that way or not.

The market is moving toward documented accountability for AI behaviour, which means teams should expect stronger pressure to evidence who approved access, what the system touched, and how misuse would be contained. In that environment, AI security programmes that cannot produce traceability will struggle to satisfy both incident response and compliance requirements. Aligning with NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 is becoming a practical governance baseline, not just a reference point.

For practitioners

• Define separate control owners for the three AI security domains Assign ownership for threats from AI, security of AI systems, and security with AI to different teams or clearly separated programme lanes. Each lane should have its own control objectives, metrics, and escalation path so that operational effort does not blur into governance confusion.
• Inventory AI models, agents and integrations Create a living register of deployed models, connected tools, data sources, and third-party dependencies. Include who approved each integration, what data it can reach, and whether logging exists for tool use and delegated actions.
• Constrain agent permissions to the minimum delegated scope Treat agent access like any other privileged workload. Use least privilege, time-bound access where possible, and approval controls for higher-risk actions such as data export, credential use, or workflow execution.
• Make auditability a release gate for AI deployments Require evidence that model decisions, tool calls, and data access can be traced before systems go live. If the system cannot explain what it accessed or changed, it is not ready for regulated or high-impact use cases.
• Separate assistive AI from decision authority in SOC workflows Use AI to enrich context, reduce noise, and prioritise work, but keep containment and high-impact response decisions under explicit human control until the workflow has proven reliable and observable.

Key takeaways

• AI security breaks into three distinct problems: threats from AI, securing the AI itself, and using AI inside operations.
• Agent permissions and auditability are now core governance controls because AI systems can act, not just respond.
• Security teams should separate ownership, inventories, and approval paths before AI usage scales further.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.

What's in the full article

Anomali's full article covers the operational detail this post intentionally leaves for the source:

• How the webinar mapped practical controls to each of the three AI security domains for security operations teams
• The leadership discussion on governance, auditability, and deployment qualification for agentic AI
• Operational examples of where AI can improve triage, correlation, and response workflows
• The on-demand session context behind the framework and the speakers' original wording

👉 The full Anomali article covers the webinar framing, leadership commentary, and operational examples in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the access and lifecycle controls that underpin safer AI and identity programmes.