Identity & Access Visibility for Modern Enterprises
TL;DR
Koshalta is a visibility and governance layer that unifies identity and access data across Azure AD, Google Cloud IAM, SaaS, and internal systems.
It answers in real time: who has access to what, who actually used it, why they have it, and whether that risk is justified. Today it delivers a unified access map, real-time access awareness, explainable entitlements (graph-based), and risk identification (overprivileged and zombie accounts). The roadmap adds enterprise dashboards, controlled enforcement with approval workflows, a unified semantic layer, and an intelligent translation layer for new identity providers.
Identity is now the primary attack surface.
As organizations adopt multi-cloud infrastructure, AI platforms, SaaS tools, and automated provisioning, access sprawl becomes inevitable. What remains rare is clear, unified visibility.
Koshalta provides a single operational and governance layer that answers, in real time:
Who has access to what? Who actually used it? Why do they have it? Is that risk justified?
The Executive Problem
Most enterprises today operate across:
Azure AD / Entra ID
Google Cloud IAM
Multiple SaaS platforms
Internal systems
AI tools with API-level permissions
Each system provides its own dashboard and logs. None provide unified governance.
As a result:
Access is granted through layered inheritance (roles, groups, policies)
Koshalta consolidates identity data and access logs across providers into a single operational view.
Security leadership can instantly assess:
Active access by user or system
Last usage timestamps
Sensitive tool exposure
Department-level access posture
Inactive but authorized accounts
This transforms identity from a fragmented control plane into a measurable governance domain.
Dashboard. Single entry point: Dashboard, Graph, Realtime feed, Risk, and Simulation control. Summary counts for users, tools, and recent activity.
2. Real-Time Access Awareness
Koshalta ingests and normalizes access events across identity providers into a unified event model.
Executives gain:
Live access feed
Last-access lookup by user or resource
Department-filtered activity streams
Sensitivity-aware access monitoring
This enables proactive oversight rather than post-incident reconstruction.
Realtime access feed. Live stream of access events (user, resource, source, decision, timestamp).
Filter by source (e.g. azure_ad, google_iam) and decision (allow/deny) to focus on specific streams.
Realtime feed — filtered to “allow”. Only successful access events; useful for compliance and usage analysis.
3. Explainable Entitlements
Koshalta projects IAM entitlements into a graph model, allowing teams to see:
Why a user has access
Through which role or inheritance chain
Which policy governs that access
This explainability is critical for:
Regulatory defense
Audit preparation
Internal governance committees
Board-level reporting
Graph — by user, Entitlement (IAM). Paths from a user through roles to tools they are entitled to access (User → HAS_ROLE → Role → CAN_ACCESS → Tool).
Search by User ID to see why they have access and which role grants it.
Graph — by user, Actual access (from logs). Same user viewed by actual usage: User → ACCESSED → Tool, with last access time.Graph — by tool. “Who has access to this tool?” Search by Tool ID to list users with entitlement (via role) or who have actually accessed it.
4. Risk Surface Identification
Koshalta highlights structural identity risks:
Overprivileged users
Zombie accounts (no access activity within defined windows)
High-sensitivity resources with broad exposure
Policy inconsistencies across platforms
This shifts identity from static compliance posture to dynamic risk management.
Risk panel. Overprivileged users (entitlements but no access in 90+ days or never) and zombie accounts (entitled but no recorded access). Roles and tool entitlement counts support prioritization.
Candidates for access review and remediation workflows.
5. Simulation control & source-of-truth details
This is where you run the simulation and view the required details about it: simulation status (running/stopped), identity-sim-core health, and the full configuration of the sources of truth — Azure AD (users, roles, policies) and Google IAM (projects, tool IDs, IAM bindings).
Simulation details — status and Azure AD. Simulation status (e.g. Stopped/Running), identity-sim-core health, and Azure AD (simulator) summary: user count, roles, policies, plus per-user detail (id, email, department, role_ids, status).Simulation details — Google IAM. Projects and their configuration: project id, name, and tool_ids (which tools belong to the project). IAM bindings define which users can access those tools — the source of truth for allow/deny in the simulation.