Identity used to be treated as a directory problem: find the user, inspect the groups, review the assigned roles, and decide whether the account has too much access.
That model no longer matches the cloud.
A single person may authenticate through Okta, inherit permissions from multiple groups, receive role assignments in more than one cloud, and reach resources through policies defined in separate control planes. Non-human identities are even harder to reason about. The same IAM roles, service accounts, service principals, Kubernetes service accounts, and cloud applications can be used by workloads, automation systems, and AI agents.
The security object is no longer the account. It is the path from a principal to a permission to a resource.
Effective access cannot be reconstructed from an inventory
An inventory-first CIEM workflow can tell you that a user, group, role, or policy exists. It cannot, by itself, explain how access was assembled.
Consider an AWS IAM user that belongs to an administrative group while also carrying an inline policy and a custom policy. The important question is not whether any one of those objects looks risky. It is which relationships contribute to the user’s effective access and where each permission came from.
The same problem appears in Azure. A user may connect to cloud access through group membership, subscription-scoped RBAC assignments, and multiple role definitions. Looking at the user record alone hides the access chain. Looking only at the role definition hides who inherited it and through which assignment.
This is why identity security needs a relationship model. Permissions are inherited, delegated, scoped, and sometimes transitive. The context that matters lives between objects.
The graph becomes the identity security system of record
Upwind’s new Identity Graph correlates identities across AWS, Azure, Google Cloud, Okta, and AI service providers. It creates an end-to-end inventory while preserving the connections between identity providers, cloud IAM objects, policies, role assignments, and the resources that use them.
That changes the questions a security team can ask.
Instead of stopping at “Which roles does this identity have?”, teams can follow the path that granted the role, identify the assignment scope, inspect the policy behind it, and see which resources depend on the identity. The graph preserves provenance: direct access versus inherited access, identity-provider membership versus cloud-native assignment, and a human identity versus the non-human principal ultimately used by a service.
This also makes reverse investigation possible. Teams can begin with a high-privilege resource or policy and work backward to the users, groups, service accounts, and applications that can reach it.
The chained search available in the product goes further: find identity-provider users with impersonation permission, follow that relationship to a service account, and determine whether the service account is connected to a high-privilege access policy. That is not a filter over three separate inventories. It is a query over an access path.
Agentic identities make the graph mandatory
AI systems do not replace cloud identity primitives. They consume them.
An AWS Bedrock agent may use an AWS IAM role. A Vertex AI workflow may use a Google Cloud service account. An Azure OpenAI integration may use a service principal. LangGraph may operate through a Kubernetes service account, while Copilot Studio or Gemini-backed workflows may use cloud applications and service accounts.
From an IAM perspective, these can look like familiar non-human identities. Operationally, they represent a new class of software actor that can call services, access data, and take actions without a person initiating every request.
Upwind’s identity experience treats agentic identities as a first-class category. The agentic inventory shows the account, identity type, the platform or service using it, the number of resources using the role, a risk overview, and recent activity.
That context matters because “service account” is no longer a sufficient description. Security teams need to understand what is using the identity, how broadly it is connected, whether it is active, and which risks are attached to it.
The new identity focus views apply the same principle across human, non-human, agentic, and stale identities. Rather than forcing teams to navigate provider-specific inventories, they organize day-to-day work around the identity class and security condition that requires attention.
From permission data to operational decisions
A graph is useful only if it improves decisions.
The surrounding identity experience places relationship context alongside recent activity, resource usage, risk findings, cloud sessions, and related detections. This helps distinguish identities that merely exist from identities that are actively used, broadly connected, or positioned on a high-privilege path.
It also gives security teams a more precise unit of investigation. A finding is no longer just “this role is privileged.” It can be understood as a chain: an identity-provider user belongs to a group, the group receives a cloud role assignment, the role definition grants access, and a workload or agent uses the resulting identity against specific resources.
That context improves prioritization without reducing identity risk to a single severity score. It shows why the risk exists and which relationship must change.
Identity posture includes credentials and configuration
Permissions are only one part of identity state. Non-human identities also depend on certificates, secrets, and the policies governing their lifecycle.
Upwind extends the identity model into new CSPM frameworks and certificate and secret-rotation management. The architectural value is not another isolated control. It is the ability to connect configuration state and credential hygiene to the identity and access paths they affect.
A stale secret, an unrotated certificate, an impersonation permission, and a high-privilege policy may each appear in a different security workflow. In a connected identity model, they can be evaluated as parts of the same access system.
That is the difference between reporting identity findings and understanding identity risk.
The access path is the new security boundary
Cloud identity security cannot be solved one provider, one directory, or one account type at a time. Human users, service accounts, workload roles, and AI agents now cross the boundaries between identity providers, cloud IAM systems, applications, and resources.
The Identity Graph completes Upwind’s CIEM model inside the broader CNAPP by making those relationships the primary object of analysis. It is not a more detailed account inventory. It is a model of how access is created, inherited, used, and connected.
Once identity is represented as a graph, teams can investigate and prioritize based on the path privilege actually takes through the cloud.
