Use a discovery model that links identities, assets and runtime signals across every place AI can appear, including desktops, IDEs, cloud workloads and logs. The goal is not just to list tools, but to determine what is actually active, who can use it and which credentials or data paths it touches. Without that correlation, governance remains partial and reactive.
How do you discover AI across endpoints, cloud and developer tools?
Discovery works best when it is tied to identity, asset and runtime telemetry, not just a software inventory. That means correlating what is installed or reachable with who signed in, which tokens or secrets were used, what network or API activity occurred, and whether the activity is sanctioned, shadow IT, or part of a sanctioned rollout. The outcome should be an evidence-backed view of actual AI usage.
A practical discovery program also has to distinguish between AI as a hosted service, AI embedded in a developer workflow, and AI running inside a cloud workload. Those are different control surfaces, even when they share the same vendor or model family. An endpoint plugin, a cloud API call, and a browser-based copiloting session can each create separate data paths, privilege paths and logging gaps.
Discovery is strongest when security teams treat developer tools as first-class AI surfaces. IDE plugins, code assistants, formatting tools, browser extensions, package hooks and CI/CD integrations can all reveal AI use that never appears in a formal procurement list. Code Formatting Tools Credential Leaks is a useful reminder that developer tooling can expose both secrets and hidden trust paths.
Cloud discovery should look for AI assets, AI-specific configuration, service principals, API keys, model endpoints, notebook workloads and data flows that indicate AI is active even when the platform team has not documented it. AI Security Posture Management (AI-SPM) Guide is relevant because discovery is incomplete unless it captures both the asset and the attack path around it.
Endpoint discovery is equally important because local desktop use often precedes formal adoption. Endpoint Security Guide supports the operational view that telemetry, host tooling and user activity are often where unsanctioned AI use first becomes visible. If security teams only inspect cloud subscriptions, they miss the user-facing layer where most experimentation starts.
What evidence should discovery collect before you can govern AI use?
The minimum useful evidence set is not a vendor list, it is a chain of proof that shows activity, authority and data access. Security teams should look for installed clients, browser extensions, SaaS approvals, API usage, workstation logs, identity events, cloud audit trails and developer workflow telemetry that can be tied together into one record. The objective is to prove whether a tool is actually in use and whether it can touch production data, code or credentials.
That evidence should also identify the control owner. A discovered AI capability is not operationally meaningful until teams know whether it belongs to an individual user, a development team, a cloud platform owner, or a central AI governance function. Without ownership, you can discover the tool but still fail to govern its access, retention and data handling.
Security teams should also pay attention to the boundaries around tokens, secrets and delegated access. Once an AI tool can read repositories, call internal APIs or access shared documents, the discovery problem becomes one of access mapping as much as software identification. JetBrains GitHub plugin token exposure shows why IDE-integrated AI or developer tooling cannot be treated as a simple productivity app.
Where possible, discovery should capture the difference between approved use and actual use. A team may approve one copilot, but users may still connect personal accounts, alternate plugins or unmanaged browser tools. That gap is usually where governance fails first, because the control surface is broader than procurement records suggest.
How do you turn discovery into a repeatable operating model?
A durable model starts with continuous correlation rather than periodic review. Teams should feed endpoint telemetry, SaaS logs, cloud audit events and identity data into a single inventory so that new AI activity is detected as it appears, not after an annual review. This is the point where discovery becomes an operational control instead of a one-time audit exercise.
The inventory should then be grouped by risk-relevant use case: end-user copilots, developer assistants, embedded platform services, automated workflows and cloud-hosted AI workloads. Each group has different exposure patterns, so the same control set will not fit all of them. For example, developer assistants often create secret exposure risk, while cloud workloads more often create misconfiguration and service-account exposure risk.
Teams should also keep the scope broad enough to catch sanctioned and unsanctioned use together. AI Security Maturity Model is helpful here because discovery, inventory and ownership are the prerequisite layers for every later governance decision, from policy to monitoring.
If the organisation is already using policy templates, align discovery outputs to those rules so that exceptions are visible. AI Acceptable Use Policy Template fits this stage because discovery should feed the approved-tools list, the data-handling rules and the exception workflow, not sit beside them.
Risk and Threat Considerations
AI discovery fails when organisations stop at visibility and do not connect usage to credentials, data paths and runtime authority. That creates shadow adoption, hidden data exposure and unmanaged access paths, especially where browser tools, IDE plugins or cloud APIs can operate under legitimate user identity.
Failure mechanism: A tool or workload is known by name, but not linked to its active identities, tokens, permissions or data flows, so security teams miss the real blast radius and cannot tell whether use is approved, exposed or compromised.
Impact: Sensitive data, source code or secrets can be processed through an ungoverned AI path, while defenders continue to believe they are seeing the full estate.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI discovery here depends on finding tokens and secrets exposed through tools and workflows. |
| NHI-07 — Long-Lived Secrets | Discovery must identify AI paths that rely on persistent tokens or keys across tools and workloads. | |
| NHI-05 — Overprivileged NHI | The answer hinges on discovering what AI can actually access, not just what exists. | |
| Recommendation — Scan AI-enabled endpoints and developer tools for leaked secrets and revoke exposed credentials. Inventory long-lived AI credentials and replace them with shorter-lived, tightly scoped access. Map AI-related identities to their effective permissions and remove excess access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Discovery relies on knowing which identities and accounts are using AI tools and services. |
| Recommendation — Maintain an authoritative account inventory for AI-enabled users, services and tools. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | AI discovery requires correlating logs, identity events and runtime signals into a usable view. |
| Recommendation — Analyze audit data to identify active AI use and trace its related access paths. | ||
Practitioner Guidance
What to prioritise: Start with the places where AI most often hides, developer endpoints, browser-based copilots, IDE plugins, SaaS add-ons and cloud workloads with model or embedding access. Those surfaces usually reveal the fastest mismatch between “approved” and “actually used”.
What to verify: For each discovered AI use case, verify the identity that invoked it, the permission set behind it, the data it can reach and the logging that proves it is still active. If any one of those is missing, the inventory is not operationally reliable yet.
Practitioner takeaway: Discovery is not a cataloguing exercise, it is a correlation problem, and the teams that solve it earliest are the ones that can govern AI before it becomes invisible infrastructure.
Related resources from NHI Mgmt Group
- How should security teams implement DLP across cloud apps, endpoints, and AI tools without blocking normal work?
- How should security teams evaluate whether a unified data security platform can actually enforce policy across endpoints, browsers, SaaS, cloud, and AI tools?
- How should security teams use AI-driven detection to reduce human-centric attack risk across email, cloud and collaboration tools?
- How should security teams reduce risk from AI agents and developer tools that use secrets locally?