How do security teams govern sanctioned and unsanctioned AI tools without losing visibility into risk?

Why This Matters for Security Teams

Sanctioned and unsanctioned AI tools create the same core problem: they expand access faster than traditional inventory, review, and approval processes can track. Once employees connect a browser plugin, chatbot, or autonomous agent to corporate data, the risk is no longer only whether the tool is approved, but what identities it can impersonate, what secrets it can reach, and what data it can export. That is why governance has to combine discovery, entitlement review, and behaviour monitoring instead of relying on a simple approved or blocked list. Guidance from NIST Cybersecurity Framework 2.0 and NHIMG research such as Top 10 NHI Issues both point to the same operational reality: visibility is the control plane for risk. NHIMG’s analysis in The 2024 ESG Report: Managing Non-Human Identities, published with Oasis Security & ESG, found that 72% of organisations have experienced or suspect a breach of non-human identities. In practice, many security teams encounter shadow AI only after an OAuth grant, exposed token, or over-permissioned agent has already touched sensitive systems.

How It Works in Practice

Governance starts with discovery, but not just SaaS discovery. Security teams need to correlate sign-up emails, SSO events, OAuth consents, browser telemetry, endpoint logs, and API activity to build a complete picture of sanctioned and unsanctioned AI use. That means identifying both the tool and the identity behind it: the human account that approved access, the service account or NHI behind the integration, and any downstream agent that can act independently. The NIST Cybersecurity Framework 2.0 supports this kind of continuous visibility, while NIST SP 800-53 Rev. 5 Security and Privacy Controls gives teams a control vocabulary for access enforcement, logging, and monitoring.

For AI-specific governance, the practical model is to separate policy for approved tools from policy for shadow AI. Approved tools should be onboarded through procurement, security review, and identity binding so their OAuth scopes, API keys, and service credentials are visible and revocable. Unsanctioned tools should not be treated as a pure blocking problem; they should be categorized by exposure path, data sensitivity, and whether they can chain actions across systems. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because AI tools behave like living integrations, not static applications.

• Inventory tools, agents, and plugins through identity, network, and SaaS telemetry.
• Map each tool to the data stores, SaaS tenants, and internal APIs it can reach.
• Review OAuth scopes and token lifetimes before approving any integration.
• Alert on new sign-ups, unusual consent grants, or access from unfamiliar tenants.
• Revoke or quarantine tools that begin exporting data, escalating privileges, or chaining requests unexpectedly.

These controls tend to break down in decentralised environments where teams can self-authorise new tools through personal email, unmanaged devices, or consumer AI accounts because the security team never sees the consent event in time.

Common Variations and Edge Cases

Tighter AI governance often increases friction for developers and business teams, so organisations have to balance speed against the need for durable visibility. The hardest cases are not the obvious unsanctioned chatbot use cases, but sanctioned tools that quietly expand scope through plugin installs, delegated mailbox access, or service-to-service authentication. In those cases, a tool may remain “approved” while its effective risk profile changes every time a user adds a connector or an agent inherits a new permission set. Current guidance suggests this should be handled with policy-based review of each new trust relationship, not with a one-time approval. There is no universal standard for this yet, but best practice is evolving toward runtime checks, short-lived credentials, and explicit scope limits for every connection.

Another edge case is shadow AI used through personal accounts on corporate devices. Endpoint controls may see the browser, but not the tenant, consent chain, or data flow. That is where correlation matters most, and where Regulatory and Audit Perspectives can help teams justify evidence collection and retention decisions. The same principle applies to autonomous agents: if an agent can decide when to call tools, pass data between systems, or retry failed actions, its risk cannot be understood from a static allowlist alone. Teams should align governance to behaviour, not just procurement status, and treat every new connector as a new attack path.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern encrypted DNS without losing visibility?
• How should security teams govern AI agent token spend without losing accountability?
• How should security teams govern AI-driven customisation without losing control?