AI security and governance gaps are widening across enterprise AI

At a glance

What this is: This is an analysis of why AI security and governance are failing to operate as a single control plane, and why that separation creates blind spots across enterprise AI.

Why it matters: It matters because IAM, governance, and security teams now have to coordinate identity, access, and compliance controls around AI systems that move faster than traditional review cycles.

By the numbers:

• 73% of organizations experienced at least one AI-related security incident in 2024, with many incidents stemming from governance failures rather than technical vulnerabilities.
• 45% fewer compliance violations were reported by organizations with integrated AI security and governance approaches.
• 60% faster incident resolution times were reported by organizations that integrated AI security and governance.

👉 Read Obsidian Security's analysis of bridging AI security and governance

Context

AI security and governance break down when organisations treat technical protection and policy compliance as separate workstreams. In AI environments, that split leaves gaps in accountability, monitoring, and incident handling, especially where access, data movement, and model use overlap. For IAM and governance teams, the core issue is not only model risk but also who or what is authorised to interact with AI systems, data, and workflows.

The article argues that unified oversight is becoming necessary because AI adoption is accelerating faster than manual governance processes can scale. That intersection is especially relevant to NHI and agentic AI governance, where tokens, service accounts, app-to-app access, and delegated actions can sit outside traditional human identity review. The starting position described here is increasingly typical for enterprises, not an edge case.

Key questions

Q: How should security teams handle delegated access when AI agents act on behalf of customers?

A: Security teams should treat delegated access as a separate governance layer, not as a normal login session. Define what the agent can do, how much value it can move, which approvals are required, and how delegation is revoked. Without those boundaries, the agent inherits more authority than the customer intended and fraud risk expands quickly.

Q: Why do AI infrastructure programmes create new identity governance risk?

A: They create risk because machine-speed workflows can combine APIs, secrets, and delegated authority faster than conventional review cycles can observe. That breaks assumptions built around human-paced approval, auditing, and recertification. The result is not just more access, but less clarity about which component exercised that access and whether it was still appropriate.

Q: What breaks when AI security and compliance are managed separately?

A: Separate management creates inconsistent risk visibility, slower incident handling, and policy drift. Security teams may block threats without proving compliance, while governance teams may document controls without seeing runtime behaviour. In practice, neither side can fully explain who had access, what changed, or whether the control worked.

Q: Who is accountable when an AI agent causes a security incident?

A: Accountability should sit with the business owner, the system owner, and the security function together, because agent behaviour crosses operational boundaries. Organisations need a defined owner for approval, monitoring, and retirement, plus audit evidence that shows what the agent accessed and why.

Technical breakdown

Why AI security and governance diverge in practice

AI security teams usually focus on threat prevention, detection, and incident response, while governance teams focus on policy, compliance, and regulatory alignment. When these functions are disconnected, the organisation gets inconsistent risk visibility across the AI lifecycle. The result is that a system can appear technically protected while still violating policy, or it can satisfy documentation requirements while remaining operationally exposed. In AI environments, identity, access, and data controls are tightly coupled, so a split operating model creates blind spots around who can act, what they can reach, and whether those actions are authorised.

Practical implication: align security and governance ownership around shared AI access, data, and approval controls.

How integrated AI risk frameworks reduce control gaps

The NIST AI RMF and ISO 42001 both push organisations toward lifecycle-based governance rather than isolated point controls. NIST AI RMF frames this through Govern, Map, Measure, and Manage, which helps teams connect policy, risk identification, metrics, and response. ISO 42001 adds management-system discipline, including continuous improvement and documented accountability. For practitioners, the value is not the labels themselves but the ability to enforce consistent controls from model intake through deployment, monitoring, and retirement, while keeping evidence available for audit and incident review.

Practical implication: map AI controls to lifecycle stages and require evidence at each stage.

Where AI identity and access controls become governance controls

AI systems increasingly depend on tokens, OAuth grants, service accounts, app-to-app permissions, and other non-human identities. That means identity governance is no longer just about human users or privilege reviews. It becomes a governance mechanism for AI behaviour, data reach, and delegated action. If a model, assistant, or connected service can access sensitive data without clear lifecycle controls, the organisation loses both security assurance and compliance traceability. This is where NHI governance and AI governance intersect most directly, especially in SaaS and agentic environments.

Practical implication: include non-human identities and delegated AI access in governance, audit, and review workflows.

Threat narrative

Attacker objective: The attacker aims to exploit fragmented AI oversight to reach data, permissions, or actions that neither security nor governance teams can fully see in time.

1. Entry occurs through AI systems, connected SaaS services, or delegated access paths that are governed separately from the rest of the identity estate.
2. Escalation follows when AI access, tokens, or app-to-app permissions are broader than the governance team realises, allowing actions beyond intended scope.
3. Impact appears as data exposure, compliance failure, or incident response delays because security evidence and governance evidence are managed in different systems.

NHI Mgmt Group analysis

AI governance debt is becoming an operational security problem. When organisations add AI faster than they add unified controls, they create a backlog of unresolved risk decisions, undocumented access paths, and missing accountability. The issue is not simply compliance lag. It is a structural mismatch between AI deployment speed and governance cadence, and that mismatch directly affects identity, access, and auditability. Practitioners should treat unresolved AI governance as live security debt.

Non-human identity governance is now part of AI governance. AI systems often act through service accounts, OAuth tokens, and delegated app permissions, which means governance cannot stop at model approval or policy documents. If those identities are not lifecycle-managed, organisations cannot prove who or what was authorised to access data or execute actions. This makes identity governance a prerequisite for defensible AI governance, not a separate stream. Practitioners should extend review and evidence controls to AI-linked NHI paths.

Unified control planes will outlast fragmented AI tooling. The market is converging on models that combine security posture, compliance evidence, and access governance because isolated tooling cannot keep pace with AI operating patterns. That does not mean one platform solves the problem. It means practitioners will increasingly evaluate whether a control stack can correlate policy, identity, and runtime behaviour across the same AI workflow. Practitioners should re-evaluate whether their current tooling can support that correlation.

Continuous monitoring is the minimum viable control for AI systems with delegated access. Manual review cannot keep up when AI systems can move between data sources, applications, and approval boundaries in seconds. Continuous monitoring is not a nice-to-have add-on. It is the control that preserves visibility when AI action paths outnumber human review paths. Practitioners should design AI governance around continuous evidence, not periodic attestation.

What this signals

AI governance debt will increasingly show up as identity debt, because delegated access paths, service accounts, and tokens are where policy becomes enforceable or invisible. Teams that cannot map AI actions back to a governed identity will struggle to prove control effectiveness during audits or incidents.

The operational test is no longer whether an AI system can be approved, but whether its access can be continuously explained. NIST AI RMF gives practitioners a useful structure here, especially the Govern and Manage functions, but the real signal is whether evidence stays current as integrations and permissions change.

As AI systems spread across SaaS and enterprise workflows, continuous compliance will matter more than periodic review. Practitioners should expect pressure to prove not just that AI is allowed to operate, but that every delegated action remains within a documented trust boundary.

For practitioners

• Unify AI security and governance ownership Create a shared operating model between security, compliance, legal, and AI platform teams for approvals, exceptions, and incident response. Make one group accountable for evidence collection across model lifecycle, delegated access, and runtime monitoring. This is where cross-functional review becomes operational rather than ceremonial.
• Inventory AI-linked non-human identities Catalogue every token, service account, OAuth grant, app integration, and agent that can act on behalf of an AI workflow. Tie each identity to an owner, purpose, expiry, and review date so access can be evaluated as part of governance, not discovered only after an incident.
• Automate policy-to-control mapping Map AI governance requirements to enforceable controls such as access restrictions, logging, approval workflows, and monitoring thresholds. Use continuous compliance checks so policy drift is visible before auditors or attackers find it. Link evidence collection to the same control set used for security operations.
• Treat delegated AI access as privileged access Apply privileged access principles to systems that let AI read, write, or trigger actions in enterprise applications. Limit scope, shorten approval windows, and review high-risk integrations more frequently than standard application access. This is especially important where AI can touch customer data or administrative functions.
• Test incident response across both security and governance failure modes Run scenarios where a control failure creates both a security event and a compliance breach, such as unauthorised data access by an AI workflow or an unapproved integration path. Measure whether teams can identify, contain, and evidence the event in one workflow instead of two separate processes.

Key takeaways

• AI security and governance fail fastest when organisations treat them as separate disciplines rather than a shared control model.
• The risk is visible in the numbers, with most organisations already reporting AI-related incidents and many lacking full visibility into AI data access.
• Identity governance for tokens, service accounts, and delegated access is now a core requirement for defensible AI oversight.

Key terms

• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• 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.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Continuous Compliance: Continuous compliance is the practice of keeping controls and evidence current as the environment changes, rather than proving compliance after a review cycle. For identity and NHI programmes, it means access, logging, and revocation must operate together in real time.

What's in the full article

Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The article's full lifecycle model for aligning AI security controls with governance checkpoints across deployment stages.
• The detailed maturity stages for moving from basic coordination to automated policy enforcement and continuous compliance.
• The vendor's examples of integrated accountability across CISO, compliance, legal, and MLOps functions.
• The specific product framing for AI Security Posture Management and continuous monitoring of AI workloads.

👉 Obsidian Security's full post covers the maturity model, accountability structure, and continuous compliance approach 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 gives security and identity practitioners a practical foundation for governing delegated access across modern enterprise systems.