The identities active in your production environment authenticate, act, and typically go unwatched after login - however, so does an adversary using a stolen credential. The new ClearVector Identity Intelligence Report measures how wide that blind spot runs.
What an authenticated identity actually does inside the production environment (which non-human identities the identity assumes, which resources the identity touches, whether the identity's activity behavior looks anything like normal) is largely invisible. Not because organizations haven't invested in security - but because the tools they have weren't built to look there.
The authentication gap: what security tools see and don't see
A production environment is identity-mediated. Every action, a Lambda function reading from S3, a developer assuming a role to push a configuration change, a third-party vendor accessing your CI/CD pipeline, or an AI agent running under a developer's credentials, begins with an authenticated identity. Even when an adversary reaches production by exploiting a vulnerability from outside, everything that happens next still runs as an authenticated identity - even if the real identity is the adversary.
Enterprise IdPs (including Okta, Entra, and others) focus on the front door - the login event. The session that begins after authentication succeeds is outside their scope. These providers do not follow the identity into production to see what happens once the session goes live.
Endpoint security tools cover the corporate environment: managed devices, laptops, the IT stack. Service accounts and workload identities do the majority of the work in production, and traditional EDR tools are not aware of the control plane, the service accounts, or the workload identities. EDR focuses on the TTPs of the adversary on a device.
Configuration and vulnerability management tools assess the state of the environment and the routes through the environment: misconfigured buckets, overpermissive roles, and potential attack paths. Several now add runtime signals on top of that assessment. What none of them do is map a runtime action back to the identity that took the action, at the moment the action happens. A CSPM scan that reports a bucket as private both before and after an adversary reached the bucket saw nothing, because the access and the cleanup happened between scans.
None of this is a flaw. Each tool was built for a specific surface and covers that surface well.
What authenticated identities actually did, in what sequence, whether any of that activity was risky: none of those tools were built to answer that question.
What production identity activity actually looks like
Understanding why identity activity after authentication matters requires understanding what production identity environments contain.
Most security programs are built around the assumption that identities are human: employees authenticating to corporate systems, contractors with temporary access, admins with elevated privileges. In practice, this model describes a small fraction of the active identities in production hyperscalers like AWS, GCP, or Azure.
Data from the ClearVector Identity Intelligence Report, as shown in Visual 1, based on analysis of production environments, shows the following composition:
- 91% of active production identities are non-human. Breaking down the 91% into further detail:
- 87% are general non-human identities: for example, service accounts, workload identities, Kubernetes service accounts, and access keys
- 4% are third-party identities: vendors, integrations, and access operating via trust policies
- 9% are human: developers, engineers, admins, and contractors with direct production access.
The non-human majority is not passive. These identities authenticate continuously, often operate outside normal business hours, hold permissions that would trigger immediate review if a human account held them, and in many cases have no designated owner within the organization's HR or IAM system. By design, these identities do not live in your corporate IdP.
A single service account performing a routine nightly job and a compromised service account stealing data can be indistinguishable in a standard log review. Both authenticate successfully, both act within the range of permissions assigned to that account, and neither triggers a notification because the credential itself is valid.
This is the core problem with post-authentication visibility: the attack doesn't look like an attack. The adversary authenticated correctly. One of the clearest signals available might be whether the activity itself is risky, and whether or not that activity looks different from before.
The risk model: what matters for each identity
Assessing identity risk requires knowing what's expected for that identity in that environment. This is deceptively hard, because what's expected is not the same across identities, organizations, or time.
A developer's access patterns on a deployment day look nothing like their patterns on a quiet Tuesday. A CI/CD pipeline's activity spikes during release windows. A vendor's access should be narrow and predictable, but what narrow and predictable means depends on the specific vendor, their specific contract, and what they were actually doing when they onboarded.
Industry-wide comparisons aren't sufficient here. Knowing that service accounts at companies of similar size typically access X number of resources per day tells you almost nothing about whether a specific service account in a specific environment is doing something risky. The risk model has to be built from inside that environment.
Predictive Behavioral Defense uses event streams from production sources (such as AWS EventBridge, GCP Pub/Sub, Azure EventHub, GitHub, Okta, container runtime, custom ClearVector sensors) and builds a pattern of life for every identity in that specific customer environment. Not at the industry level. Not at the account type level. At the level of this specific service account, running these specific jobs, in this specific environment. What the known-good operating model looks like for that identity is derived from that identity, not from a peer group.
This is the predictive half of the method. The risk model exists before the incident does. So when an identity does something the model already rates as risky for that identity, the signal surfaces within seconds, not after an analyst reconstructs the sequence from logs days later. The activity does not have to look different from what that identity did last week. ClearVector flags the activity even when the credential itself is valid.
Time at peace and time at war
There are two contexts (see Visual 2 below) in which production identity visibility delivers value, and security leaders often frame them separately even though they depend on the same underlying model.
Time at peace: knowing your environment continuously
Before anything goes wrong, the identity model surfaces the risks that most organizations would otherwise discover only in the aftermath of an incident.
Unused credentials with active permissions (service accounts whose credential has not rotated in months or years but whose access rights are still in force) are a persistent and common exposure. Without a live identity graph, there is no practical way to discover them at scale.
Third-party access drifts after onboarding. Vendors hold permissions beyond their original scope, and integrations reach resources unrelated to their function. Static access reviews miss both, because a review examines what was granted rather than what the vendor does with the grant. Access granted once and never revisited stays active for years.
AI agents operating in production under developer credentials are an emerging version of the same problem, and the risk is not that the agents make changes. Making changes is the job. The risk is that the agent inherits the developer's full permission set, so every action the agent takes attributes to the developer, and the agent's blast radius is whatever that developer's credential can reach. Because ClearVector's sensors generate their own signal from the control plane rather than reading one provider's log, the activity maps back to the originating identity even when the credential presented belongs to a person.
Time at war: investigation and isolation when something happens
When a security event does occur in production, the investigation process for most teams starts from scratch. Logs need to be pulled, filtered, cross-referenced with CI/CD logs, and correlated with the identity that authenticated. For a complex incident involving federation, role assumption chains, vendor access, and cross-service data movement, that process routinely takes days or weeks.
With an identity activity model already built, the investigation starts at a different point. The full identity timeline, every action, every role assumption, every resource accessed, in sequence, attributed to the originating identity, is already there. What takes a week to reconstruct manually is available in minutes.
After initial triage and investigation, isolation is key to stop the adversary. In production environments, isolation is typically challenging because of the complexity and interplay between federated identities, workload identities, resources, and availability. Further, traditional resource-based isolation is not enough - the identity and sessions must be contained or isolated as well. The model makes that possible in one click or API call.
Why this matters now: the AI and NHI acceleration
Two concurrent trends are making post-authentication identity visibility more urgent, not less.
The first is the growth of non-human identity at scale. Industry data from SpyCloud's 2026 Identity Exposure Report shows 18.1 million exposed API keys and tokens recaptured in 2025 alone. Research from Entro Labs puts the NHI-to-human identity ratio in cloud-native environments at 144 to 1. Sophos's State of Identity Security 2026 finds that 41% of successful identity breaches trace back to non-human identities as the root cause.
The second is the deployment of AI agents in production environments. These agents, including Cursor, Claude Code, custom LLM workflows, and automated CI/CD agents, authenticate under human or service account credentials, execute multi-step workflows, and can access sensitive resources.
Both trends have the same structural implication: the identity population in production is growing faster than security programs are adapting to model that population. The space between successful authentication and meaningful visibility into what happens after, is widening.
That 91% figure is one finding from the ClearVector Identity Intelligence Report, which maps identity composition and behavior across real AWS and GCP production environments. The full report is free and ungated.
Download the report
Frequently Asked Questions
What security tools monitor identity behavior in production AWS after authentication?
ClearVector sends proactive notifications when identity activity in production AWS environments turns risky after authentication succeeds. ClearVector uses event streams from sources like AWS EventBridge and also generates its own signal from directly instrumented sensors rather than relying on ingested logs alone. From that combined view it builds a pattern-of-life model for every identity (human, non-human, and third-party) and flags risky activity within seconds, whether or not that activity is risky for that identity. Okta and other IdPs handle authentication.
How do you detect when a service account or non-human identity is compromised?
Detecting a compromised non-human identity requires a risk model built from inside the specific environment. Because NHIs authenticate with valid credentials, one of the clearest signals is whether an action is risky for that identity: for example - accessing resources outside normal scope, assuming roles not part of routine activity, operating at unusual hours, or triggering data actions inconsistent with the identity's function. ClearVector builds this model per identity, per customer, and flags risky activity within seconds, even when the credential itself is valid.
What is the difference between ITDR and production identity behavior monitoring?
Identity Threat Detection and Response (ITDR) tools focus on attacks against identity systems: compromised IdPs, directory attacks, MFA bypass. ITDR tools tell you when IdP infrastructure is under attack by focusing on adversary TTPs. Further, these tools do not model what normal production behavior looks like for identities, and were not built for the non-human identity population that makes up the majority of production activity. Production identity activity visibility addresses the post-authentication surface: what authenticated identities actually do inside production.
How is ClearVector different from a CNAPP or CSPM tool like Wiz?
CNAPP and CSPM tools identify misconfigurations and potential attack paths, telling you what could be exploited. They operate on snapshots and batch-polling cycles. ClearVector sends proactive notifications when identity activity turns risky at runtime, telling you within seconds when someone is walking the attack path, attributed to a specific identity. A CSPM scan reporting a bucket as private before and after an attack saw nothing, because the access and the data theft happened between scans. ClearVector would have flagged the Lambda deployment, the bucket change, and the data movement as they happened.
What does a Breach Readiness Report reveal?
A Breach Readiness Report shows what's actually operating in your production environment: the complete identity universe (human, non-human, third-party, AI agent), the top risks an adversary could take advantage of today, and a calculation of what your current blind spot is costing you. The audit takes 15 minutes to run against your environment and provides specific, actionable findings rather than a generic posture score.
See what's actually operating in your production environment.
A Breach Readiness Report takes 15 minutes. We map your production identity universe, show you the top exposures an adversary could act on today, and calculate what your current blind spot is costing you.
Request a Breach Readiness Report →
%201.avif)
