AI governance is becoming a core security discipline for CISOs

At a glance

What this is: This is a governance-first analysis of why CISOs need to treat AI as an enterprise security domain, with inventory, intake, monitoring, and runtime control as the central operating model.

Why it matters: It matters because the same governance gaps that create exposure in NHI and IAM programmes now appear in AI deployments, especially where access, data handling, and autonomy are expanding faster than oversight.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.

👉 Read OneTrust's blog on how CISOs can secure and govern AI across the enterprise

Context

AI governance is the discipline of defining who can introduce AI, what data it can touch, what decisions it can influence, and how its behaviour is monitored after deployment. The primary gap is visibility, because AI is now embedded in SaaS tools, development environments, analytics platforms, and third-party services faster than security programmes can catalogue it.

For CISOs and IAM teams, the important shift is that AI governance is no longer just a policy problem. Once AI systems can initiate actions, consume sensitive data, or influence business decisions, the control model has to extend across inventory, intake, review, lifecycle oversight, and runtime enforcement.

Key questions

Q: How should security teams govern AI systems that are embedded inside existing business tools?

A: Security teams should govern embedded AI the same way they govern other shared enterprise controls: discover it, classify it, assign an owner, and define the data and action boundaries before broad use. If the AI feature is inside a SaaS product or developer tool, procurement and onboarding must include explicit review of data handling, decision impact, and monitoring needs.

Q: Why do AI governance programmes need more than policy documents?

A: Policies describe intent, but they do not enforce behaviour. AI governance fails when organisations rely on static rules without intake, approval evidence, monitoring, and lifecycle oversight. Once AI systems are embedded in workflows, the control must be operational, repeatable, and visible to the teams responsible for risk.

Q: What breaks when organisations cannot inventory all of their AI systems?

A: Without inventory, organisations cannot assign ownership, assess data exposure, determine which controls apply, or prove governance to auditors and regulators. The result is reactive review, duplicated approvals, and unmanaged shadow AI. In practice, lack of inventory turns governance into guesswork rather than a control process.

Q: Who should be accountable when an AI system takes an unauthorised action?

A: Accountability should sit with the business owner of the use case, the control owner for the workflow, and the team that approved the AI’s access and autonomy. If the system can initiate actions, accountability must include the people who defined its scope, not just the people who built the model.

Technical breakdown

AI inventory and system-of-record governance

An AI inventory is the minimum control plane for governing enterprise AI. It should record models, embedded AI features, use cases, vendors, business owners, data sources, and risk classifications. Without that record, teams cannot assign accountability or determine which controls apply. The governance failure is often not lack of policy, but lack of discoverability across shadow AI and embedded AI features. That makes later review reactive and incomplete, especially when third-party applications introduce AI functionality outside normal procurement paths.

Practical implication: treat AI discovery as a standing governance process, not a one-time assessment.

Structured AI intake, risk review, and approval flow

AI intake is the point where governance becomes operational. A structured review should test intended use, data sensitivity, decision impact, third-party dependencies, and the degree of autonomy the system will have. The key issue is that AI risk is multidisciplinary. Security, privacy, legal, compliance, and business stakeholders all have different failure modes to catch, and no single team can validate the whole picture. Ad hoc approval chains break down because they do not produce consistent evidence or repeatable risk decisions.

Practical implication: require a single intake path that classifies risk before any AI use case reaches production.

Runtime governance for agentic AI and continuous monitoring

Agentic AI changes governance because the system does not just generate outputs, it can take actions. That means oversight must cover action scope, tool access, decision boundaries, and event-level observability. Manual reviews are too slow once a system can chain actions in real time. Governance by design therefore means policy enforcement inside the workflow, not just after the fact. In practice, the control problem shifts from reviewing what an AI said to monitoring what it did and what it could do next.

Practical implication: extend monitoring and guardrails to runtime actions, not only model outputs.

Threat narrative

Attacker objective: The practical objective is to exploit weak AI governance boundaries so the system can access sensitive data or take business-impacting actions without sufficient oversight.

1. Entry occurs when AI capabilities are introduced through approved SaaS, developer tools, or third-party applications without complete enterprise visibility into the embedded system or its data reach.
2. Escalation occurs when the AI system is given broader data access or action scope than the job requires, allowing it to influence decisions or trigger workflows beyond intended boundaries.
3. Impact occurs when unmanaged AI behaviour produces data exposure, compliance failure, incorrect business decisions, or uncontrolled autonomous actions at scale.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 governance is becoming a control-plane problem, not a policy problem. The article correctly shifts attention from written rules to operational oversight, because policy alone does not constrain what AI is embedded inside SaaS, development, or third-party services. Governance fails when teams cannot see the full AI estate, cannot classify risk consistently, and cannot attach ownership to each use case. Practitioners should treat AI governance as a continuous system of record and control, not as a document set.

Visibility debt is the new enterprise AI risk baseline. The article’s inventory argument reflects a broader governance truth: you cannot secure what you have not discovered. AI embedded in existing products is especially difficult because it often arrives through procurement, not standalone projects, which makes traditional review points easy to miss. For identity teams, that means AI exposure can accumulate in the same way NHI sprawl does, with ownership ambiguity and unclear control scope.

Runtime guardrails are the dividing line between AI assistance and AI behaviour. Once AI systems can initiate actions, the governance question changes from output quality to authority boundaries. That is why runtime monitoring, observability, and policy enforcement matter more as autonomy increases. The article is right to place agentic AI in the foreground, because static approvals do not scale to systems that can act faster than human review cycles.

Governance by design is the only credible model for AI at enterprise scale. The article makes the correct strategic point that mature governance can enable adoption rather than slow it down, but only if controls are embedded into workflows and lifecycle processes. This is the same operating logic that has long applied to IAM and NHI programmes: security works best when it is part of the system, not a separate checkpoint. Practitioners should design AI governance as an operational control layer, not an exception process.

AI governance and NHI governance are converging around the same lifecycle failure modes. The article’s emphasis on inventory, third-party review, monitoring, and lifecycle oversight mirrors the control problems already visible in NHI security. The difference is that AI systems can also make decisions and trigger actions, which raises the stakes for identity governance. Practitioners should align AI oversight with NHI and IAM operating models before the tool sprawl becomes unmanageable.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• Only 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• That same survey found 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, which is why Top 10 NHI Issues remains a useful reference point for control design.

What this signals

AI governance will increasingly be measured by operational evidence, not policy count. Security teams should expect scrutiny to shift toward inventory completeness, approval traceability, and runtime monitoring coverage. With 70% of organisations granting AI systems more access than a human employee doing the same job in the 2026 Infrastructure Identity Survey, governance debt is already visible in access design.

Named concept: governance by design. In practice, this means AI controls must live inside procurement, onboarding, and workflow execution rather than in a separate checklist. That direction aligns with the control logic in the NHI Lifecycle Management Guide, where visibility and lifecycle ownership are treated as operating requirements rather than afterthoughts.

As autonomous features spread through enterprise platforms, identity teams will need to coordinate more closely with application owners and third-party risk functions. The control question will not be whether AI exists, but whether the organisation can prove what it can access, what it can decide, and who is accountable when it acts.

For practitioners

• Build a single AI inventory as a control record Capture models, embedded AI features, business owners, vendors, data sources, and risk classifications in one place so governance decisions have a consistent reference point.
• Route all AI use cases through a structured intake review Require security, privacy, legal, compliance, and business review before deployment, with explicit assessment of data sensitivity, autonomy, and decision impact.
• Extend monitoring into runtime AI behaviour Track what the system can access, what actions it can take, and what it actually does after deployment so reviews are not limited to pre-production approval.
• Apply third-party governance to embedded AI capabilities Test vendor AI features during procurement and onboarding for transparency, data handling, access scope, and accountability so unmanaged features do not enter production unnoticed.

Key takeaways

• AI governance has become a core security control problem because embedded systems now outpace manual review.
• Inventory, intake, monitoring, and lifecycle oversight are the operating controls that turn policy into enforceable governance.
• Agentic AI raises the bar further because governance must cover actions, not just outputs.

Key terms

• AI Inventory: A centralized record of AI systems, embedded features, models, vendors, owners, and data sources. It gives security and governance teams the visibility needed to assign accountability, classify risk, and decide which controls apply before and after deployment.
• Governance by Design: An operating approach that builds governance into workflows, systems, and approvals instead of treating it as a separate review step. In AI programmes, this means policy, access boundaries, monitoring, and evidence are embedded where the system actually runs.
• Agentic AI: AI systems that can initiate actions, interact with tools or services, and make multi-step decisions with increasing autonomy. The governance challenge is not only what they generate, but what they can do, when they can do it, and under whose authority.
• Runtime Controls: Controls that enforce policy while a system is operating, rather than only before release. For AI, runtime controls include observability, action limits, policy enforcement, and alerts that detect behaviour outside approved scope.

What's in the full article

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

• The article’s step-by-step AI inventory approach, including the fields teams should capture for ownership and risk tracking.
• The intake and review questions OneTrust recommends before an AI use case moves into production.
• The specific ways OneTrust frames continuous monitoring, lifecycle oversight, and governance by design for agentic AI.
• The named frameworks and implementation references used to align AI governance with broader security and compliance programmes.

👉 The full OneTrust post covers AI inventory, review processes, lifecycle governance, and preparation for agentic AI.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.