Device-based AI and SaaS discovery closes local shadow IT gaps

At a glance

What this is: JumpCloud is extending AI and SaaS discovery to the device layer to surface locally installed apps, shadow IT, and rogue AI tools that browser-centric controls miss.

Why it matters: IAM teams need endpoint-level visibility because local installation and local execution can bypass SSO, web filters, and connector-based discovery across NHI, autonomous, and human identity programmes.

By the numbers:

• 46%, ure AI adoption is currently stalled for many organizations by limited oversight of permissions, 46%, and a fundamental lack of visibility into AI activity, 45%.

👉 Read JumpCloud's analysis of device-based AI and SaaS discovery

Context

Local software creates an identity governance blind spot because the control plane often never sees the install, the login, or the execution. In practice, that means a desktop AI app or agentic browser can operate outside the evidence trails that IAM, SSO, and web security teams normally rely on for oversight of AI and SaaS usage.

For NHI and human identity programmes alike, the gap is not just discovery but attribution. If an application is installed locally and used with personal or work credentials on unmanaged hardware, existing browser-first and connector-first models can miss both the subject and the access path, which leaves policy enforcement incomplete.

Key questions

Q: How should security teams govern local AI apps that bypass browser-based controls?

A: Security teams should treat local AI apps as endpoint-governed software, not as browser extensions of SaaS. That means requiring installation review, user attribution, allowed-use policy, and inventory coverage that includes the device itself. If the tool executes locally, browser logs alone are insufficient for audit, compliance, or incident response.

Q: Why do standalone desktop apps create visibility gaps for IAM teams?

A: Standalone desktop apps create visibility gaps because they can be installed and authenticated outside the normal SSO, IdP, and web gateway paths. IAM teams lose the login evidence they usually depend on, which makes shadow IT harder to detect and makes recertification and compliance reporting less reliable.

Q: What breaks when software discovery stops at the browser?

A: What breaks is the assumption that every meaningful application session will produce a central identity or network signal. Local apps, offline tools, and agentic browsers can run without those signals, so software inventory becomes incomplete and security teams may approve or ignore tools they cannot actually see.

Q: How can organisations measure whether local AI is under control?

A: Organisations should measure whether they can link installed local tools to named users, approved device groups, and documented policy decisions. If a local AI app appears in the estate without an owner, a review status, or a recorded business purpose, the programme still has an unmanaged exposure.

Technical breakdown

Device-based discovery on the endpoint

Device-based discovery shifts software inventory from network observation to endpoint inspection. Instead of waiting for browser traffic, SSO events, or SaaS connectors, the device agent reads what is physically installed on the machine and correlates that with user context. This matters because local AI tools, offline apps, and agentic browsers can execute without standard web telemetry, so conventional discovery sees only a partial picture. A unified inventory is created when device findings are merged with browser and connector data, which reduces the chance that shadow IT is treated as a web-only problem.

Practical implication: treat endpoint inventory as a first-class control source, not a secondary audit feed.

Why browser-only SaaS controls miss local AI

Browser-only governance assumes application use produces cloud-visible signals. That assumption fails when software runs locally, whether it is an LLM runner, a downloaded desktop client, or an agentic browser that drives tasks on the host itself. In those cases, no corporate SSO event may exist, no web gateway traffic may be generated, and no connector will necessarily capture the session. The control gap is structural, because visibility is attached to transport and identity events rather than the actual runtime location of the application.

Practical implication: extend discovery and policy coverage to local execution paths, not just web sessions.

Agentic browsers and local AI as discovery and governance problems

Agentic browsers and local AI tools are not just new application categories. They change where identity evidence lives and how much of the access path remains observable. If a user can install an autonomous desktop tool, sign in locally, and let it act on data or websites without a normal SaaS login flow, then IAM teams may lose both provenance and accountability. The governance issue is therefore not only software sprawl but also evidence loss, because the organisation cannot certify what it cannot reliably see.

Practical implication: define review and approval workflows for locally installed AI tools before they become operationally normal.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device discovery is becoming the missing identity control plane for local software. Browser-centric SaaS management was built for a world where most work happened through the web and every meaningful action left an identity trail. That model breaks when applications move onto the endpoint and can be launched with no browser session, no connector event, and no centralised audit signal. The implication is that software inventory, access governance, and user attribution now need to converge at the device layer.

Local AI changes the problem from shadow IT to shadow execution. A downloaded AI desktop app or agentic browser can act outside the controls that were designed around cloud login, web filtering, and SSO mediation. That is not just an extra application to catalogue, it is a different operating mode that bypasses the evidence sources many programmes use to prove compliance or investigate misuse. Practitioners need to recognise that the governance failure is invisibility at runtime, not merely undeclared software.

Endpoint visibility exposes a broader identity truth: control must follow the workload, not the assumption. When the workload is local, the security boundary moves with it. That means identity teams can no longer treat browser telemetry as a proxy for software risk, especially when local tools are used with personal credentials or on unmanaged devices. The practitioner conclusion is straightforward: inventory, policy, and recertification all have to account for where execution actually occurs.

Unified discovery creates the conditions for meaningful software accountability. A combined view of browser, connector, and device-based findings gives security teams a practical way to distinguish approved tools from unmanaged ones. That does not eliminate risk by itself, but it does convert an unknown estate into a governed one. In identity terms, visibility is the prerequisite for ownership, and ownership is the prerequisite for enforcement.

From our research:

• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to DeepSeek breach.
• Our research also found that attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
• The same exposure pattern reinforces why local AI discovery must connect to credential hygiene, so review and rotation can follow the asset rather than the browser session.

What this signals

Local software governance is moving from optional inventory to core identity control. As more AI and SaaS tools execute on the endpoint, programmes that rely on browser telemetry alone will keep missing the software that matters most. The next step is not another dashboard, but a policy model that ties device discovery to access ownership, especially for locally installed AI and unmanaged desktop clients.

Shadow execution will become a more useful concept than shadow IT for many teams. A tool can be approved on paper and still create risk if it runs outside the evidence sources that security teams can review. That is why endpoint visibility should be aligned with a broader control set such as the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, which help teams reason about runtime behaviour as well as software presence.

For practitioners

• Add endpoint installation data to SaaS governance: Correlate device-installed applications with browser and connector discovery so local AI tools and desktop SaaS apps do not remain outside the software inventory.
• Review approval paths for local AI tools: Require explicit review for standalone AI desktop apps and agentic browsers before they can be used with corporate or personal credentials on managed devices.
• Treat local execution as a policy boundary: Write controls that apply when software runs outside the browser, including requirements for user attribution, allowed installs, and evidence retention.
• Use unified inventory for compliance evidence: Build a single inventory that can support audit, shadow IT review, and software bill of materials reporting by combining endpoint, browser, and connector sources.

Key takeaways

• Local AI and desktop SaaS tools create an endpoint visibility problem that browser-only governance cannot solve.
• The evidence gap is operational, not theoretical, because local execution can bypass SSO, web filters, and connector-based discovery.
• Security teams need unified inventory and approval workflows that follow where software actually runs, not where they expect it to run.

Key terms

• Device-based discovery: Device-based discovery is the practice of identifying installed applications by inspecting the endpoint itself rather than relying only on browser, network, or SaaS connector data. It matters because local software can run without generating the identity signals many governance programmes expect to see.
• Shadow execution: Shadow execution is software activity that occurs on a device outside the monitoring paths a security team uses to prove ownership, approval, or accountability. The application may be known in name, but the runtime behaviour and identity evidence are not visible enough for dependable governance.
• Agentic browser: An agentic browser is a browser-like tool that can take actions with some degree of autonomy, such as navigating sites or completing tasks locally. In governance terms, the concern is not only what it can do, but that it may do so outside standard SaaS, SSO, or web filtering controls.
• Software bill of materials: A software bill of materials is an inventory of applications and components used in an environment. For identity teams, its value depends on accuracy and scope, because incomplete discovery creates blind spots that weaken compliance evidence, access review quality, and incident investigation.

Deepen your knowledge

Local AI and SaaS discovery are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building endpoint-level governance for shadow IT and rogue AI, it is worth exploring.

This post draws on content published by JumpCloud: device-based AI and SaaS discovery for local shadow IT and AI. Read the original.