Why do AI governance programs fail when they rely on approved-tool lists alone?

Why Approved-Tool Governance Falls Short

Approved-tool lists create a false sense of control because they govern procurement, not runtime behaviour. An AI feature can be added to an approved SaaS platform after the review, and a user can grant access through OAuth without any change to the vendor register. That means the real security question is not only “what was approved?” but “what can this identity reach right now?” NHIMG’s Top 10 NHI Issues frames this as an identity and lifecycle problem, not a vendor-management problem.

The gap widens when governance teams rely on annual reviews, because AI-enabled workflows can change daily through integrations, plugins, and delegated tokens. This is why current guidance from NIST AI Risk Management Framework and NIST Cybersecurity Framework 2.0 increasingly emphasises continuous monitoring and risk-based controls rather than one-time approval gates. In practice, many security teams discover the failure only after an agent has already chained tools, expanded scope, or exfiltrated data through a “trusted” application.

How It Works in Practice

Effective ai governance treats each AI system, agent, or integration as an identity with observable permissions, not as a line item on an approved-tools spreadsheet. The operational control is identity context: who or what is acting, what environment it is in, which resource it is requesting, and whether that request matches current policy. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because the permission model has to follow the identity across issuance, use, rotation, and revocation.

In practice, mature programs combine the approved-tool inventory with runtime authorisation and telemetry:

• Use workload identity for AI services and agents so the system proves what it is, not just what software it runs.
• Issue short-lived tokens and secrets per task, then revoke them automatically when the task ends.
• Evaluate access at request time with policy-as-code, so approval depends on context, data sensitivity, and action type.
• Log OAuth grants, connector changes, and tool calls together, because the risk often enters through delegated access rather than direct logins.

This aligns with evolving practice in the NIST AI Risk Management Framework and the emerging implementation patterns discussed in the NIST AI 600-1 Generative AI Profile, where governance depends on ongoing measurement rather than static sign-off. It also reflects lessons from the DeepSeek breach, where access pathways and downstream exposure mattered more than the nominal application boundary. These controls tend to break down when SaaS admins, citizen developers, or AI agents can add integrations faster than the security team can re-classify them.

Common Variations and Edge Cases

Tighter tool governance often increases operational overhead, so organisations have to balance speed against visibility and revocation discipline. Best practice is evolving, but there is no universal standard for whether every AI feature inside an approved platform must be treated as a separate control domain. That judgement usually depends on whether the feature can read data, take actions, or create new delegated permissions.

Edge cases show why approved-tool lists are incomplete:

• Shadow AI inside sanctioned SaaS products, where new AI functions appear after procurement approval.
• OAuth sprawl, where a user or developer grants an integration access beyond the original intent.
• Agentic workflows that can call multiple tools in sequence, making the effective risk much larger than any one approved app.
• Shared service accounts, which hide who initiated the action and make revocation too coarse to be useful.

NHIMG’s Regulatory and Audit Perspectives stresses that auditors will increasingly expect evidence of runtime control, not just vendor approval. That expectation is consistent with the direction of NIST Cybersecurity Framework 2.0 and the ISO/IEC 42001:2023 AI Management System Standard. The practical takeaway is simple: if governance cannot see runtime identity, it cannot prove that an approved tool is still behaving like an approved tool.

Related resources from NHI Mgmt Group

• Why do AI governance programmes fail when they rely on manual evidence collection?
• Why do AI governance programmes fail when they rely only on policy mapping?
• Why do AI agents make non-human identity governance harder?
• What is the difference between human identity governance and AI agent governance?