AI governance spending rises, but the authorization gap remains

At a glance

What this is: This is an analysis of why AI governance spending is rising while runtime authorization for AI agents remains incomplete.

Why it matters: It matters because IAM, IGA, and PAM teams need to separate AI visibility and compliance from the enforcement layer that controls agent actions at runtime.

By the numbers:

• Gartner projects AI governance spending will hit $492 million in 2028 and surpass $1 billion by 2030.
• AI regulation will quadruple, extending to 70% of the world's economies by the end of the decade.

Context

AI governance spending is rising, but most programmes still stop at inventory, risk tracking, and compliance reporting. In practical terms, that leaves a gap between knowing what AI exists and controlling what it is allowed to do at runtime.

For identity teams, the distinction matters because AI agents, models, and workflows behave more like continuously acting non-human identities than static software assets. A governance model built only for audits cannot enforce action-level authorisation.

The article argues that the market is moving toward continuous enforcement, but many organisations are still treating AI safety, visibility, and authorisation as if they were the same control plane.

Key questions

Q: Why do AI governance programmes still leave an authorization gap?

A: Because many programmes stop at visibility, risk scoring, and compliance tracking. Those controls show what AI exists and how it is rated, but they do not decide what an agent may do at runtime. Security closes only when policy is enforced at the moment of action, not after the fact.

Q: When should organisations prioritise runtime authorisation over role-based access control?

A: Prioritise runtime authorisation when the actor can change behaviour mid-session, chain tools, or make repeated service calls without human approval. In those cases, role-based access control is too coarse to express intent or context. The practical trigger is not cloud scale alone, but autonomy and policy variance during execution.

Q: What breaks when AI agent identity is split across multiple tools?

A: Governance breaks first. If ownership lives in one system, credentials in another, and activity data in a third, no reviewer can reliably determine what the agent is authorised to do or whether it should still exist. That fragmentation makes lifecycle, review, and incident response slower and less accurate.

Q: How should teams respond if their AI governance vendor is acquired or changes strategy?

A: They should test whether policy rules are portable, versioned, and separable from the vendor’s configuration layer. If the rules cannot survive a platform change, the security programme is exposed to product decisions rather than governed by its own policy intent.

Technical breakdown

AI governance vs AI authorization

AI governance is the control plane for visibility, inventory, risk classification, and compliance reporting. AI authorization is the runtime enforcement layer that decides whether a model, agent, or workflow may perform a specific action at the moment it is attempted. The article's core point is that the market keeps collapsing these two layers into one. That creates false assurance because a system can be well-governed on paper while still being free to act outside policy at runtime. For IAM teams, the operational distinction is the same one that exists between audit evidence and access control: one tells you what is happening, the other determines what can happen.

Practical implication: separate governance reporting from enforcement policy so runtime decisions are not delegated to audit workflows.

Continuous authorization for AI agents

Continuous authorization means access is re-evaluated as context changes, not assumed valid after initial authentication. That is materially different from point-in-time review models, because AI agents can shift data scope, tool use, and decision context within a single operational session. The article frames this as a requirement for both human and non-human identities, but the AI case is sharper because the agent can keep acting after the original assumption has expired. In other words, the authorisation decision has to track the action, not just the identity label attached to it.

Practical implication: move authorisation decisions closer to execution time so changed context can invalidate stale permissions immediately.

Unified authorization across applications, infrastructure, data, and AI workloads

The article argues that AI workflows cross multiple control domains in a single transaction. An agent may authenticate through an application layer, touch infrastructure resources, query data stores, and trigger downstream agents before the request is complete. Fragmented policy across separate tools creates policy drift because no single control plane can judge the full action path. This is why the author places policy portability and code-based controls at the centre of the problem: the challenge is not simply visibility into each domain, but consistent authorisation across them.

Practical implication: map where AI actions traverse multiple domains and remove policy gaps between application, infrastructure, data, and workload controls.

NHI Mgmt Group analysis

AI governance spending is rising faster than runtime control maturity. The market is clearly investing in inventory, risk, and compliance functions, but those do not prevent an AI system from acting outside policy in the moment of execution. That leaves a structural gap between governance evidence and operational enforcement. Practitioners should treat the growth in AI governance budgets as validation of the problem, not proof that the control gap is closing.

The authorization layer is the real security boundary for AI agents. A system can be visible, documented, and scored for risk while still being able to access data or call tools it was never meant to use. That is why runtime authorisation matters more than point-in-time audits for AI operations. The implication is that identity programmes need to measure what AI can do at action time, not just what it is.

Point-in-time audit logic was designed for stable access, and that assumption fails when AI context changes continuously. The same session can begin under one data classification, one policy state, and one operational purpose, then continue under different conditions. This assumption collapse means compliance-only governance cannot be the operating model for agentic systems. Practitioners must rethink continuous enforcement as the baseline, not the enhancement.

Policy portability is becoming a governance requirement, not a procurement preference. When authorisation rules live as vendor-specific configuration, market consolidation can strand security intent inside a platform boundary. The article's consolidation example shows why policy-as-code matters: controls need to survive product changes, not disappear with them. For identity leaders, portability is part of governance resilience.

Runtime authorization for AI workloads: the category is shifting from visibility into enforceable decisioning. That shift changes how IAM, IGA, and PAM teams draw boundaries between review, policy, and execution. The practitioners who win here will align authorisation controls with the AI workload itself, not with the reporting cadence around it.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime authorization is becoming the differentiator between AI oversight and AI control. Organisations can no longer rely on audit trails and policy dashboards alone, because agent behaviour changes during execution and those changes have to be governed where they happen. The programme implication is straightforward: identity teams need to move decision logic closer to the action path and treat continuous enforcement as part of AI security design, not an optional overlay.

Continuous identity now applies across human and non-human actors. The same governance pattern that protects a person at login does not protect an AI agent that keeps acting under changing context. Practitioners should assume that the authorisation boundary is dynamic and design controls that can re-evaluate access at runtime, especially where agents cross application, data, and infrastructure layers.

For practitioners

• Separate governance from enforcement Treat inventory, risk tracking, and compliance reporting as governance functions, then build a distinct runtime authorisation layer for AI actions.
• Map cross-domain AI transaction paths Document how a single AI workflow moves across applications, infrastructure, data stores, and downstream agents so policy gaps are visible.
• Adopt policy-as-code for AI controls Store authorisation rules in version control so they can be tested, reviewed, and moved if a vendor changes direction.
• Test for continuous decision enforcement Verify that authorisation can change when context shifts during a session, rather than assuming the initial decision remains valid.
• Plan for vendor continuity Assess whether your AI authorisation rules remain usable if a platform is acquired, re-scoped, or deprioritised.

Key takeaways

• AI governance budgets are rising, but the operational control gap remains because visibility is not the same as runtime authorization.
• The article's core warning is that AI agents can be well governed on paper and still be under-controlled in practice.
• Identity teams need to separate reporting, policy, and execution so AI actions are authorised continuously instead of only audited later.

Key terms

• AI authorization: AI authorization is the runtime control that decides what an AI system may access or execute at the moment it acts. It goes beyond inventory and compliance because it enforces policy continuously, including across changing context, downstream tools, and delegated actions.
• Continuous Identity: A governance model that turns identity data into live access decisions. Instead of relying on static approvals and periodic reviews, continuous identity reevaluates whether access should still exist based on current context such as risk, device state, ticket status, or business need.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.