Independent analysis by NHI Mgmt GroupSource article: Wing Security, “The AI Adoption Playbook: 5 Plays Every Security Team Needs to Secure AI” (January 16, 2026)

TL;DR: AI adoption is spreading through shadow tools, embedded integrations and fast-changing permissions, leaving discovery, inventory, risk management and governance gaps that static security frameworks were not built to cover, according to Wing Security. The practical problem is continuous control of AI touchpoints, not a one-time approval model, because AI risk changes as access, data flows and behaviour change.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on Wing Security's blog post: Organisations need continuous discovery, a living registry, risk management, governance and culture to keep pace with AI that appears through both formal and shadow channels.

Why it matters: It matters because IAM, security architecture and governance teams now have to control AI as a moving access surface, not a static application category, and that changes how discovery, ownership, policy enforcement and review processes are designed.


Context

AI adoption is no longer a single procurement event or a single application category. It now arrives through employee experimentation, embedded features, third-party integrations and emerging agentic behaviour, which means security teams cannot govern it with static inventories or periodic review cycles.

The governance gap is not just visibility. Once AI systems touch data, permissions and external services, the control problem becomes lifecycle management: who owns the integration, what it can reach, how it changes over time, and how policy is enforced continuously.

For IAM and security teams, that places AI squarely inside identity governance, access management and risk management rather than treating it as a separate innovation initiative.


Key questions

Q: How should security teams govern shadow AI in SaaS environments?

A: Security teams should inventory AI-enabled features, classify the data those features can touch, and enforce approved-use rules at the application and identity layers. The practical goal is not to block every model interaction. It is to ensure that prompts, file uploads, and connected data sources stay within defined risk boundaries.

Q: Why do static security frameworks fall short for AI adoption?

A: They assume the system stays stable long enough for approval, review and policy enforcement to remain valid. AI systems change model behaviour, permissions and integrations over time, so the control problem is continuous boundary enforcement rather than single-point sign-off. That is why governance has to follow current state, not original deployment intent.

Q: What breaks when organisations do not maintain an AI registry?

A: Ownership, permissions and data access become impossible to trace consistently, which means teams can see that AI exists but cannot explain what it is allowed to do or who is accountable. Without a living registry, review, exception handling and risk prioritisation all lose their operating context.

Q: How do security teams balance enabling AI adoption with maintaining control over agentic systems?

A: Security teams should frame controls as enablers, not blockers, by setting guardrails that define approved data access, identity boundaries, and monitoring expectations. The objective is to let AI capabilities move forward without bypassing existing governance. That means policy makers, security teams, and standards bodies need shared rules for agent behavior, access scope, and escalation handling.


Technical breakdown

Why AI discovery has to be continuous

AI discovery is the process of continuously identifying AI systems, features and integrations across sanctioned tools, embedded capabilities and shadow usage. The core technical issue is that AI can be introduced without a new application purchase or a formal security review, so the attack surface is often invisible to traditional asset management. Discovery therefore has to operate as an ongoing control, not a point-in-time scan. In practice, this means correlating SaaS telemetry, application inventories and integration logs to identify where AI is already active, including indirect use through third-party APIs or embedded model features.

Practical implication: build discovery into your normal control plane so AI usage is found as it appears, not after procurement or incident response.

What an AI registry adds beyond an inventory

A registry is more than a list of tools. It is a living record that ties each AI touchpoint to ownership, vendor, data access, permissions, model type and operational context. That distinction matters because risk changes depending on whether a system uses an LLM, agentic behaviour or a third-party API, and whether it can read, transform or transmit sensitive data. A registry gives security teams a governance substrate for decisions, reviews and exceptions. Without it, teams know something exists but cannot explain what it is allowed to do or who is accountable for it.

Practical implication: define a minimum record set for every AI touchpoint so ownership, access and data handling can be reviewed consistently.

Why governance must follow behaviour, not deployment

AI governance in this context means enforcing policy as behaviour changes, not merely approving a deployment once. Static frameworks fail because models are updated, permissions shift and new features appear without a fresh security project. The article's logic is that policy must be checked continuously against actual behaviour, including over-permissive integrations, unsafe model connections and anomalous data handling. This is where identity and access controls intersect with AI risk management: if the system can change what it touches, policy must be evaluated against current state rather than original approval. Governance becomes an operating process, not a document set.

Practical implication: monitor AI activity for deviation from approved data, permission and integration boundaries, and route exceptions through an ongoing review process.


Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

AI adoption now behaves like an identity governance problem, not a software feature problem. The article is strongest when it frames discovery, registry and governance as the control stack needed to manage AI touchpoints across the enterprise. That matters because the risk is not just model use, but the identity and access relationships created around it. Practitioners should treat AI as part of the governed access estate, not as a separate innovation track.

Discovery is the foundation control because unseen AI cannot be governed. Embedded features, shadow experimentation and third-party integrations create an inventory problem before they create a policy problem. If security teams do not know where AI is active, they cannot assign ownership, assess data exposure or enforce review. The practitioner conclusion is straightforward: visibility is the prerequisite for every other control.

Living registry is the named concept that best captures the article's operational model. A registry only works if it stays current with ownership, permissions, vendor posture and data access as the environment changes. That turns AI governance into a lifecycle discipline rather than a one-time approval exercise. The implication is that static inventories fail the moment AI behaviour, integration scope or delegated access changes.

AI risk management must move from feature approval to continuous boundary enforcement. Misconfigured agents, unsafe model connections and over-permissive integrations are not just technical bugs, they are governance failures at the point where AI crosses into data and action. The control question is whether the organisation can detect drift early enough to stop unauthorised exposure or business disruption. Practitioners should anchor AI risk to current-state behaviour, not original deployment intent.

Culture is necessary, but culture without control architecture will not hold. Awareness training helps users understand safe AI use and data sensitivity, but the article shows that governance must still be embedded in policy, monitoring and remediation. That balance matters because AI adoption is distributed across the organisation, not centralised in one team. The practitioner conclusion is to pair education with enforceable governance, or the organisation will normalise unmanaged AI use.

From our research library:

What this signals

Living AI registry: security teams will need a record that moves with ownership, permissions, vendor posture and data access, otherwise AI governance becomes a snapshot exercise that fails as soon as integrations change.

The immediate programme impact is that discovery, inventory and policy enforcement can no longer sit in separate workstreams. They need to operate as a single control loop so embedded AI, shadow use and agentic behaviour are governed before data flows widen.

AI adoption is forcing IAM and security leaders to treat dynamic integrations like governed identities. That means the operational question shifts from whether AI is approved to whether its current access, behaviour and data reach still match the approved boundary.


For practitioners

  • Establish continuous AI discovery Correlate SaaS telemetry, application inventories and integration logs so AI features, embedded services and shadow tools are identified as they appear.
  • Create a living AI registry Record ownership, vendor, data access, permissions, model type and external integrations for every AI touchpoint, then update it when scope changes.
  • Review AI data paths and permissions Validate which sensitive datasets an AI system can read, transform or transmit, and remove over-permissive integrations that exceed the approved boundary.
  • Enforce continuous AI governance Monitor for changes in model behaviour, integration scope and policy deviation, then route exceptions through an ongoing review and remediation process.
  • Extend user awareness to AI usage Train employees on safe AI use, data sensitivity and reporting expectations so informal experimentation does not become unmanaged production use.

Key takeaways

  • AI adoption creates a governance problem because discovery, ownership and policy enforcement all have to keep up with systems that appear through formal and shadow channels.
  • A living registry is the operational anchor for tracking AI touchpoints, permissions and data access as they change.
  • Security teams need continuous boundary enforcement, not one-time approval, if they want AI use to stay inside approved limits.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01 — Improper OffboardingDiscovery and registry depend on knowing when AI touchpoints should be removed from governance scope.
NHI-05 — Overprivileged NHIThe article highlights over-permissive AI integrations and unsafe access boundaries.
NHI-08 — Environment IsolationAI tools and integrations need isolation boundaries when they touch different data sets and contexts.
Recommendation — Track AI touchpoints through offboarding so dormant integrations do not remain in your inventory. Review AI integrations for excess data reach and remove permissions that exceed approved use. Separate AI environments and data paths so one integration cannot traverse unrelated trust zones.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsAI governance in the article depends on controlling permissions and entitlements as AI behavior changes.
GV.OV-01 — Oversight of Risk Management StrategyThe article is fundamentally about continuous oversight of AI risk and policy enforcement.
Recommendation — Apply entitlement reviews to AI touchpoints and keep access aligned to current business need. Set oversight routines that review AI risk, policy drift and remediation outcomes on an ongoing basis.

Key terms

  • AI registry: A living inventory of AI systems that records ownership, purpose, data access, dependencies, and privilege. Unlike a static asset list, a registry supports governance by linking each AI touchpoint to review, enforcement, and lifecycle decisions.
  • AI Discovery: AI discovery is the process of automatically finding AI tools, embedded features, agents, and integrations operating in an environment. It provides the first visibility layer for governance, but it does not by itself explain ownership, permissions, or risk.
  • 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.
  • Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org