Your cloud security posture is dialed in. But what about the Active Directory server in the closet, the legacy database behind the firewall or the air-gapped environment that no SaaS tool can reach?
According to Gartner, 87% of organizations today operate in a hybrid environment — a mix of public cloud, private cloud, and on-premises infrastructure — and that number is trending toward 90% by 2027. Hybrid isn't a temporary state. It's the steady state.
The problem is that more and more security teams are building their visibility stack around cloud-native tooling. That's smart for cloud workloads, but it leaves a gap. On-premises Active Directory, physical network devices, legacy applications, self-hosted databases and air-gapped environments all sit outside the reach of your SaaS-based security platform. You can see your cloud. You can't always see what's behind the firewall.
That gap has a name: the visibility gap. And it's where risk hides.
The Visibility Gap Is a Security Risk
Every infrastructure evolution — from mainframes to physical servers, virtualization to containers, Kubernetes to serverless — has added capability while also adding complexity. Organizations don't upgrade in clean, linear steps. They accumulate layers. The mainframe from the 2000s might still be running alongside the Kubernetes cluster you deployed last quarter.
The result is an environment where no single tool sees everything. Cloud-native platforms can't reach your on-prem resources. On-prem tools were never built to handle cloud workloads or SaaS applications. And when you add multi-cloud into the mix — where the same resource types exist across AWS, Azure and GCP with different APIs — the gap widens further.
For security teams, this isn't an abstract problem. It means compliance controls that can't validate what they can't see. It means identity risks in Active Directory that don't show up in your cloud security posture. It means a source of truth that isn't actually telling the whole truth.
Enter the JupiterOne Collector
The architecture is straightforward. JupiterOne generates a data request. The Collector — running inside your environment — picks up that request, connects to the on-prem source (Active Directory, Device42, a container registry or any other supported integration), pulls the data, normalizes it into JupiterOne's data model and syncs the metadata back to the platform. No sensitive data leaves your network. Only normalized metadata is transmitted.
Setup is simple: create a collector in the JupiterOne UI, copy a single command, run it on your host and the Collector spins up two containers — a daemon and a runner — that handle the rest. Once deployed, the Collector auto-updates by checking for the latest version from the JupiterOne GitHub repository every time it runs. There's nothing to patch or maintain manually.
What This Unlocks for Security Teams
Once on-prem data flows into JupiterOne, it becomes part of the same graph that models your cloud resources, identities and relationships. That's where the value compounds.
Query your entire environment, not just the cloud. With the Collector feeding Active Directory data into JupiterOne, you can run queries like "which users have admin access?" or "which AD users are missing an email address?" alongside your cloud identity queries. The data model is the same. The query language is the same. The blind spot is gone.
Build compliance controls for on-prem assets. JupiterOne's Continuous Controls Monitoring (CCM) extends to Collector-sourced data. You can build custom frameworks — for example, an Active Directory compliance framework — that continuously validate controls against your on-prem infrastructure. One example is a custom AD framework running at 67% compliance, with clear visibility into which controls were failing, which asset types were affected and which risks were of highest priority. That level of visibility simply didn't exist before the data was in the graph.
Map relationships across hybrid boundaries. Because JupiterOne is built on a graph database, Collector-sourced assets don't sit in isolation. An Active Directory user pulled via the Collector can be linked to their cloud IAM roles, their device posture and their application access — all in a single graph traversal. The hybrid boundary that separates your on-prem from your cloud disappears at the data layer.
Scan container registries for vulnerabilities. The Collector also enables SBOM and vulnerability scanning for self-hosted container registries. Deploy the Collector, point it at your registries and use open-source tools like Syft (for SBOM generation) and Grype (for vulnerability detection) to feed software composition data into JupiterOne. The result: full visibility into what's running inside your containers, with relationships mapped to the rest of your infrastructure.
Security Considerations
For security teams evaluating the Collector, a few details matter. The Collector only transmits normalized metadata — no raw sensitive data leaves your environment. Proxy and firewall traversal is supported via standard HTTP/HTTPS proxy environment variables. TLS communication can be enabled by uploading your certificates through the JupiterOne UI, ensuring encrypted traffic between the Collector and the platform. And because the Collector is a container, it carries a minimal footprint and attack surface.
From Partial Truth to Source of Truth
The phrase "source of truth" gets used a lot in security tooling. But a source of truth that only sees half your environment is, at best, a source of partial truth. The JupiterOne Collector is designed to close that gap — not with a heavyweight agent deployment or a complex integration project, but with a single container that bridges on-prem data into the same graph where your cloud security already lives.
For security teams operating in hybrid environments, the Collector expands JupiterOne from a cloud visibility platform into a full-environment visibility platform. Same data model. Same query language. Same compliance controls. No more blind spots behind the firewall.
