Resources | Blog

April 22, 2026

Unochariot: Governing the Identities Your Security Program Can't Reach

Table of contents

Identity security has come a long way. Most enterprises now have solid visibility of identities across their cloud environments, SaaS applications, and IDPs. But ask those same teams about their on-premise and self-hosted systems, and the conversation gets quieter. That part of the environment has always been a different problem and, for most companies, an unsolved one.

Why the gap has stayed unsolved

Most security teams are well aware that their on-prem systems, self-hosted GitHub, internal Jira, private Okta deployments, and legacy applications that predate the cloud era carry real identity risk. Permissions accumulate, access goes unreviewed, and the governance processes that apply everywhere else simply do not reach there. The reason it stays unsolved is that the obvious fix creates a bigger problem. Connecting a cloud tool to an on-prem system typically requires opening inbound access to the private network, including configuring firewall rules, opening ports, and creating security exceptions. For most enterprise security teams, that is a trade-off most are not willing to make. Opening the network perimeter to gain visibility into it defeats the purpose entirely. The right solution would need to work entirely within the customer's existing security model. No inbound access, no credential sharing, no network restructuring. Something that lives within the environment, collects what is needed, and delivers it to the customer on the customer's terms. That is Unochariot.

Unochariot: Built to work within your security model

Rather than the cloud reaching into the customer's network, Unochariot deploys a lightweight agent as a simple Docker container within the customer's own infrastructure, whether cloud-hosted or on-premises. The onboarding process is simple by design. Unosecur generates a unique set of credentials for each Chariot instance, including a client ID, client secret, and agent identifier. Those are loaded into the container, and from that point the agent manages everything itself. The image below illustrates what happens on a set schedule:

All communications are agent-initiated. Unomaster never calls into the customer's network. There are no inbound connections, no open ports, and no changes to existing firewall rules. Credentials for internal systems never leave the customer's environment either. The agent uses them locally to collect data and only transmits the resulting identity information to the platform, not the keys used to retrieve it. Every connection between the agent and Unosecur's servers run over mutual TLS, where both sides verify each other's identity, and all data in transit is fully encrypted.

For organizations in regulated industries where even encrypted internet traffic is not acceptable, Unochariot supports fully private network paths:

  • AWS customers can route data through AWS PrivateLink, keeping it entirely within Amazon's private network.
  • GCP customers can use Private Service Connect for the same guarantee on Google's infrastructure.

In both cases, data travels from the customer's environment to Unosecur's platform without touching the public internet. On the reliability side, the agent is built to handle the realities of enterprise infrastructure. If a data push fails mid-cycle, it retries with exponential backoff rather than dropping the batch. If the agent restarts or goes offline, it picks up from where it left off on the next run. The job history and state are maintained on Unomaster's side, so nothing is lost if the agent itself is restarted or redeployed.

Closing the visibility gap

Once Unochariot is running, on-prem and self-hosted systems appear inside the same Unosecur dashboard that already covers the rest of the environment. The same identity analysis, the same risk findings, the same activity timeline, extended to the systems that have always sat outside the program. In practice, that means systems like self-hosted GitHub Enterprise, Slack Enterprise Grid, on-premise Jira, and Okta deployments running inside a private network are now fully visible. Permissions that have been accumulating for years without review, access that was granted and never revisited, accounts that outlived the people they belonged to. All of it becomes auditable for the first time. That also includes internal applications with no external API. Systems that were never built with third-party integration in mind can still be connected through custom ingestion modules, bringing them into view for the first time.

Governance without compromise

Compliance requirements are not getting looser. Frameworks such as GDPR, SOC, ISO 27001, HIPAA, DORA, and NIS2 are already in effect across industries, and all share the same expectation: security governance must cover the entire environment. That means complete logs of identity activity, clear mapping of who has access to what, and demonstrable evidence that on-prem systems are being reviewed and governed with the same rigor as everything else. On-prem systems are typically the part of that requirement that existing tooling has never been able to address. Unochariot closes that gap by providing the identity logs, access mapping, and audit trails these frameworks require, extended to every system that has always sat outside the program. The on-prem systems that have sat outside identity programs for years will not be exempt from scrutiny. Unochariot makes sure they don't have to be. If your on-premise systems have been outside your identity program, they do not have to stay that way. Book a demo and see what Unochariot uncovers. If your on-premise systems have been outside your identity program, they do not have to stay that way. Book a demo and see what Unochariot uncovers.

Ready To Secure Your Identities?