AI security is becoming an identity governance problem

At a glance

What this is: This is Orca Security’s summary of the TAG Enterprise AI Security Handbook 2026, highlighting that AI security is shifting into an operational identity and governance problem.

Why it matters: It matters because IAM, NHI, and AI governance teams now have to extend existing controls to AI systems that act, access, and change context in ways traditional programmes were not built to track.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.

👉 Read Orca Security's overview of the TAG Enterprise AI Security Handbook 2026

Context

AI security is no longer a lab exercise. Once AI systems enter production, the problem shifts from experimenting with models to governing access, data exposure, and accountability across systems that may behave like non-human identities or autonomous actors.

The guidance gap is now operational: teams are expected to classify risk, extend existing IAM and security policy, and prove control effectiveness without a stable benchmark for what "good" looks like. That is why AI security is converging with identity governance, not sitting beside it.

For practitioners already building NHI programmes, the overlap is familiar. Identity becomes the control plane for access, delegation, and traceability, while AI risk management must be translated into the same lifecycle language used for service accounts, tokens, and AI agents.

Key questions

Q: How should security teams govern AI systems that use enterprise identities?

A: Treat the AI system as a governed identity path, not just an application. Inventory the credentials, delegated permissions, data sources, and tool connections it uses, then assign ownership and review scope as part of normal IAM and security operations. If the AI can act in production, its access must be visible, bounded, and explainable.

Q: Why do AI systems complicate existing IAM and security controls?

A: They complicate governance because access is no longer tied only to a person or fixed workload. AI systems can combine tools, reach data, and change behaviour as context changes, so static permissions and one-time approvals can fail to reflect runtime risk. The control model has to track action, not just authentication.

Q: What breaks when AI risk is not tiered by business impact and exposure?

A: Teams either over-control low-risk internal assistants or under-control externally exposed systems that handle sensitive data. Without tiering, monitoring, testing, and access restrictions become inconsistent, which makes it harder to focus effort where the blast radius is largest. Tiering turns AI governance into a repeatable decision process.

Q: What does the shift to operational AI security mean for existing governance programmes?

A: It means AI security has to run continuously inside existing governance, not as a one-time project. Discovery, access validation, logging, and policy enforcement need to keep pace with changing workflows, because AI systems evolve after deployment. The programme needs operating cadence, ownership, and measurement, not just policy language.

Technical breakdown

Operational AI security needs continuous discovery and control enforcement

The report’s core shift is from one-time AI pilots to an operating model. Continuous discovery means identifying where AI is used across cloud, application, and business workflows, while control enforcement means validating access, data flow, and behaviour as those systems change. This matters because AI deployments do not stay static. New prompts, integrations, tools, and permissions alter the attack surface after go-live. Security teams therefore need a repeatable control loop, not a point-in-time review. The real technical problem is that AI risk emerges from runtime context, so visibility and governance must follow the workload rather than the project.

Practical implication: build AI discovery and validation into standard security operations rather than treating it as a separate review cycle.

Identity controls now govern AI access pathways and accountability

AI systems interact with users, services, and downstream tools through identities, secrets, and permissions. That makes identity the point where access is authorised, scoped, and later explained. The report’s framing aligns with NHI reality: when AI systems use credentials or delegated access, the security question is not just who logged in, but what the system can do, which data it can reach, and who is accountable for its actions. This is where authentication and authorisation become inseparable from governance, because access pathways multiply quickly once AI is wired into production workflows.

Practical implication: map AI systems to the identities and permissions they use, then review access as part of broader governance and accountability.

Risk tiering is a control strategy, not a reporting exercise

The handbook stresses that not all AI risk is equal. A structured risk tiering model separates low-impact internal use cases from customer-facing or data-sensitive systems, so security effort matches exposure and business impact. Technically, this is a policy-routing problem: the same control set should not be applied uniformly when data sensitivity, external exposure, and blast radius differ. Without tiering, teams either over-control low-risk systems or miss high-risk ones. Risk tiering works best when it drives access policy, testing depth, and monitoring expectations rather than living only in a spreadsheet or board update.

Practical implication: tie AI risk tiers to access policy, testing cadence, and monitoring thresholds so controls scale with exposure.

Threat narrative

Attacker objective: The objective is to abuse AI-enabled access pathways to reach sensitive data, systems, or business processes with less scrutiny than traditional controls would allow.

1. Entry via legitimate enterprise adoption, where AI is introduced into existing workflows and connected to cloud, application, and identity systems.
2. Escalation occurs when the AI layer inherits broad permissions, data access, or delegated tool use without equivalent governance depth.
3. Impact follows when those access paths expose sensitive data, create unaccountable actions, or widen business risk across production systems.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security has crossed into identity governance, not because the technology is new, but because the access model is now identity-shaped. Once AI systems call tools, reach data, and act inside enterprise workflows, their security posture depends on the same governance primitives used for NHIs and privileged workloads. That means the real issue is not "AI security" as a separate discipline, but whether IAM, PAM, and lifecycle controls can describe and constrain machine action with enough precision. Practitioners should treat AI systems as governed identities, not just software features.

Risk tiering is the named concept this market needs: a repeatable way to decide which AI systems deserve deeper control. The report correctly points to the difference between low-risk internal assistants and externally exposed AI applications, but the broader lesson is that AI governance fails when every system is treated as equal. Tiering must drive what gets discovered, what gets tested, and what gets monitored. Practitioners should make risk tiering the organising principle for AI security investments.

Existing security policy does not need replacement, but it does need identity-aware translation. Access management, data protection, and application security all still apply, yet AI introduces more dynamic delegation paths and more frequent context shifts. That creates a governance gap between policy intent and runtime behaviour. The implication for practitioners is clear: control frameworks must be adapted so they can express identity, data, and execution context together.

AI security vendor growth is signaling category convergence around cloud, identity, and data context. The market is moving toward platforms that can correlate AI usage with access paths and exposure, rather than single-purpose point tools. That does not eliminate the need for specialist controls, but it does mean practitioners should re-evaluate whether their current stack can connect identity signals to real exploitability. Practitioners should plan for more consolidation around context-rich security platforms.

Operational AI security is becoming a continuous governance function, not a project milestone. Threats, workflows, and dependencies change too quickly for fixed controls to hold their value for long. The organisations that will keep up are the ones that can continuously reassess AI usage, validate permissions, and align governance with business impact. Practitioners should build AI security into the same operating rhythm as identity governance and cloud risk management.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
• This makes Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs the right next reference point for teams aligning access, rotation, and offboarding with AI and machine identity governance.

What this signals

Risk tiering is becoming the organising concept for AI governance programmes. As AI moves into production, teams need a practical way to distinguish low-impact assistants from externally exposed systems that can affect sensitive data and business outcomes. That is where identity, data, and workflow context must be joined into one control decision rather than handled in separate silos.

The next stage is programme design, not tool acquisition. Organisations that already manage service accounts, tokens, and delegated access can extend those operating habits to AI, but only if they keep runtime validation in scope. The control objective is continuous alignment between permissions, actual use, and business exposure.

For teams building that discipline, the overlap with NHI governance is immediate. Once AI uses enterprise identities, the same questions apply: who owns it, what can it reach, and what happens when its scope changes after deployment? That is the governance gap practitioners should plan around.

For practitioners

• Classify AI systems by risk tier before assigning controls Separate internal assistants, decision-support systems, and externally exposed AI applications, then align access review depth, testing, and monitoring to the tier. Use this to prevent low-value AI from consuming high-cost controls while high-risk systems remain under-governed.
• Map every AI workflow to the identities it uses Inventory service accounts, tokens, delegated permissions, and tool connections behind each AI system, then record who owns each identity and which data it can reach. This is the foundation for accountability when AI actions need to be explained.
• Extend existing IAM and data controls into AI operations Apply access management, data classification, logging, and privilege scoping to AI-connected systems rather than building a separate parallel policy set. The goal is to make AI security part of the existing control plane, not a side programme.
• Validate AI behaviour after deployment, not just before release Use continuous testing and monitoring to catch scope drift, new integrations, and unexpected access paths as AI systems evolve in production. A one-time approval is not enough once tools, prompts, and permissions keep changing.

Key takeaways

• AI security becomes a governance problem when AI systems inherit identities, permissions, and data access inside production workflows.
• The meaningful control boundary is no longer deployment alone, because runtime context changes what the system can reach and do.
• Practitioners should tier AI risk, map identities, and extend existing IAM and data controls into continuous operations.

Key terms

• AI Security Operating Model: An AI security operating model is the repeatable way an organisation discovers, classifies, governs, and monitors AI in production. It connects policy, identity, data, and validation so security is managed as an ongoing function rather than a one-time project.
• Risk Tiering: Risk tiering is the practice of grouping AI systems by exposure, data sensitivity, and business impact so controls can be scaled appropriately. It prevents low-risk tools from being over-governed while ensuring high-risk systems receive stricter oversight and testing.
• Identity Blast Radius: Identity blast radius is the amount of damage or reach an AI system can create once it has access to enterprise identities, data, or tools. It is shaped by permission scope, delegation paths, and the number of connected systems the AI can affect.
• Runtime Governance: Runtime governance is the set of controls that evaluate access and behaviour while a system is active in production. For AI, it matters because prompts, tools, and context can change after deployment, so static approvals do not fully describe real risk.

Deepen your knowledge

AI security governance and identity-aware control design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending IAM, PAM, or lifecycle processes to AI systems, it is worth exploring.

This post draws on content published by Orca Security: A New Chapter for Enterprise AI Security. Read the original.