AI governance must account for intent, context and outcomes

At a glance

What this is: This is an analysis of why AI governance fails when organisations treat AI like a conventional workload and rely too heavily on retrospective controls.

Why it matters: It matters because IAM, NHI and AI governance teams need to define intent, context and permitted use before enforcement hardens into blocking that does not actually reduce risk.

Context

AI governance is not just a policy problem. It is a sequencing problem, because controls built for predictable systems struggle when the same input can produce different outcomes based on intent and context. Traditional governance assumes stable behaviour, but AI collapses the gap between access and result. This makes early design decisions disproportionately important.

The core gap is that teams often try to extend existing control models before they have defined how AI should be used. That works poorly when governance needs to operate closer to the decision, not just the infrastructure. The article’s argument is especially relevant to AI governance programmes that also need to account for agent identity lifecycle and permissions bound to AI use.

Key questions

Q: What breaks when organisations rely on data security controls that only cover storage systems and not AI workflows?

A: Storage-only controls miss the point where most AI leakage happens. Users paste data into prompts, upload files, or pass context through connectors that never touch the original repository again. Without runtime guardrails, sensitive data can be exposed in prompts, outputs, and logs, while auditors still lack a clear record of what was accessed and changed.

Q: Why do security teams need to define acceptable AI use before enforcement scales?

A: Because once AI is embedded in workflows, later controls tend to become blunt restrictions that users work around or that disrupt operations without addressing the underlying risk. Defining acceptable use first gives the programme a governance boundary, so enforcement supports direction instead of trying to create it after behaviour has already changed.

Q: How do you know if AI governance is too focused on infrastructure instead of intent?

A: A governance model is too infrastructure-led when it can explain where the request came from, but not what the AI was allowed to do or why that use was acceptable. The sign of failure is a programme that can authenticate activity yet cannot evaluate purpose, context or downstream outcome.

Q: Should AI governance be treated as containment or as an operating model?

A: It should be treated as an operating model. Containment alone turns governance into a blocking function that slows adoption and encourages workarounds. An operating model assigns decision rights, review points and exception handling so safe AI use can scale without making every decision a security exception.

Technical breakdown

Why deterministic control models fail for AI

Most security governance assumes that systems are mostly deterministic: the same identity, same permissions and same workflow produce the same effect. AI breaks that assumption because it infers intent, incorporates context and can produce different outputs from identical prompts or inputs. That means access is no longer a reliable proxy for risk. Controls that only track where a request came from or which account used it miss the more important question of what the system was allowed to do with that access. Practical implication: shift governance criteria from location and entitlement alone to permitted use, context and outcome. See the AI Governance Guide.

Practical implication: Treat AI governance as outcome-aware control design, not a simple extension of access management.

Why governance must start before enforcement scales

Traditional security often observes behaviour first and enforces later, but AI adoption changes that sequence. Once AI is embedded in workflows, controls added afterwards tend to become blunt restrictions that users work around. The governance decision has already happened by then, usually through early product and workflow choices that were never formally reviewed. Effective programmes therefore need a front-end governance layer that defines acceptable use, risk boundaries and escalation paths before large-scale enforcement. Practical implication: establish approval and boundary-setting processes before AI usage becomes operational default.

Practical implication: Create governance gates early enough to shape behaviour instead of trying to contain it after adoption.

How context and intent reshape identity risk in AI

AI governance gets harder when the same tool, authenticated the same way, creates different levels of risk depending on who is using it and for what purpose. This is where identity and AI governance intersect: the account is only part of the story, because authorised use can still become unsafe if the intent, data sensitivity or downstream action changes. That is why programmes need a stronger model for usage intent and context, not just identity and access records. Practical implication: add governance checks for use case, context and permitted outcome alongside user authentication. See the Identity Governance for AI Agents Guide.

Practical implication: Evaluate AI access by purpose and result, not only by who logged in.

NHI Mgmt Group analysis

AI governance debt: organisations that delay governance decisions until after adoption create a structural liability that becomes harder to unwind with every workflow that depends on AI. The article shows that the real risk is not simply ungoverned use, but governance decisions made implicitly and then inherited by the programme. That pattern matters because it shifts the control point from enforcement to design. Practitioners should treat early AI choices as durable governance commitments.

Controls built for deterministic systems do not map cleanly to AI behaviour. AI changes the relationship between permission and outcome, which means legacy access controls can no longer be the primary governance answer. This is not a call to discard existing controls, but it is a warning that they only cover part of the risk surface. Security leaders need an explicit model for variability, context and permitted outcomes. Practitioners should redesign control expectations around AI behaviour, not infrastructure assumptions.

The strongest AI governance programmes will look more like operating models than policy documents. The article correctly frames governance as a way to enable safe use at scale rather than as a containment exercise. That is the right direction for identity teams too, because it forces ownership, decision rights and lifecycle boundaries into the programme before exceptions multiply. Where a governance model exists, it should define who can approve use, what context matters and when the control boundary shifts. Practitioners should build governance as an operating discipline, not a one-time policy artefact.

Governance needs to move closer to intent, not just identity. That is the most important identity-security lesson in the piece. In AI programmes, authentication proves who accessed the system, but not why the system was used, what it was allowed to decide, or how far its output can propagate. That creates a genuine gap for IAM and NHI teams, especially where AI agents or workflow automations begin acting on behalf of users. Practitioners should align AI governance with AI governance and lifecycle controls that can track purpose, not only access.

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 Governance Guide

What this signals

AI governance debt: the longer organisations let early AI decisions harden into informal practice, the harder it becomes to introduce meaningful boundaries later. That means practitioners should treat early review gates, use-case registers and ownership assignments as programme infrastructure rather than administrative overhead.

The practical signal for identity teams is that AI governance will increasingly intersect with agent identity, lifecycle control and delegated permissions. Once AI systems begin acting inside business workflows, the question shifts from who can access the tool to what the tool is authorised to decide, consume and produce.

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. That kind of decentralisation raises the risk of inconsistent governance unless ownership and policy are made explicit early.

For practitioners

• Define acceptable AI use before broad enforcement Document permitted use cases, disallowed use cases and escalation paths before AI is embedded in production workflows. This gives governance a boundary to operate against instead of leaving security teams to react after adoption patterns are already entrenched.
• Separate governance decisions from blunt containment Avoid using one-size-fits-all restriction as the first response to AI risk. Build review points for intent, context and downstream effect so governance shapes behaviour rather than simply blocking usage when risk appears.
• Add context checks to identity-based controls Require the business purpose, data sensitivity and expected outcome to be visible when AI usage is approved or reviewed. Identity alone does not explain whether the same access is safe in a different workflow.
• Create an AI governance operating model Assign decision rights for approval, review and exception handling so AI governance is not spread across ad hoc teams. The article’s core warning is that implicit choices become hard constraints later, so ownership must be explicit early.

Key takeaways

• AI governance fails when organisations rely on controls built for predictable systems and then expect them to manage variable, intent-driven behaviour.
• The article’s central warning is about sequencing: once AI is embedded in workflows, governance choices become harder to reverse and easier to normalise.
• Identity teams should focus on permitted use, context and decision rights, because authentication alone does not explain whether AI use is safe.

Related NHI Mgmt Group resources: AI Governance Guide · AI Security Maturity Model · Identity Governance for AI Agents Guide · AI Governance Platform Buyer's Guide

Key terms

• AI Governance Debt: The operational and organisational burden created when AI decisions are made informally and then hardened into practice before governance is defined. It accumulates when ownership, boundaries and review points are added after adoption, making later control changes harder, slower and more disruptive.
• Intent-aware Governance: Intent-aware governance is the practice of controlling actions based on the purpose behind an identity’s request, not only on who or what is making it. In identity security, it aligns AI agents, NHIs, and human users with approved business intent, then constrains access, approvals, and execution to reduce misuse and unintended automation.
• Outcome-Based Control: A control model that measures the result an AI system is allowed to produce rather than only the identity, location or application used to trigger it. This is important because AI can generate different outcomes from the same input, making access-based control alone incomplete.
• 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.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and related lifecycle controls. It helps practitioners connect identity decisions to the wider security programme that depends on them.