TL;DR: 91% of active production identities are non-human and most security tools still stop at authentication, leaving post-login behavior largely invisible, according to ClearVector's Identity Intelligence Report. That gap matters because AI agents, service accounts, and third-party access now drive production activity, and the real risk is what an authenticated identity does next, not just whether it logged in.
At a glance
What this is: This is ClearVector's analysis of post-authentication identity activity in production, and its key finding is that most production identities are non-human while the control gap sits after login.
Why it matters: It matters because IAM, PAM, and NHI programmes that stop at authentication cannot see whether a valid session is behaving normally, overreaching, or being abused in production.
By the numbers:
- 91% of active production identities are non-human.
- 87% are general non-human identities such as service accounts, workload identities, Kubernetes service accounts, and access keys.
- 4% are third-party identities, including vendors, integrations, and access operating via trust policies.
👉 Read ClearVector's Identity Intelligence Report on post-authentication production identity behaviour
Context
Production identity security starts with a simple but often missed point: authentication is not the end of the risk surface. In production environments, an identity can log in correctly and still behave in ways that are unusual, excessive, or clearly harmful once the session is live.
That gap is especially important for NHI governance because service accounts, workload identities, third-party access, and AI agents often do the bulk of the work after login. Traditional IAM and EDR controls were built to see the front door or the endpoint, not to attribute runtime actions back to the identity that performed them.
The article argues that production visibility has to be built from the inside of the environment, because a valid credential can belong to a legitimate service account or an adversary using the same access. For IAM teams, the practical question is no longer only who authenticated, but what that identity did next.
Key questions
Q: How should security teams detect risky behaviour after authentication in production?
A: Security teams should combine authentication logs with runtime identity telemetry so they can see what the session did after login. The key is to attribute each action back to the originating identity and compare it with that identity's normal behaviour in the specific environment. That approach catches misuse even when the credential itself is valid.
Q: Why do service accounts and workload identities create so much least-privilege risk?
A: They usually outnumber human accounts, change more often, and are frequently granted broad access for convenience. Because they are hard to review manually, over-privilege tends to persist, which expands the attack surface for anyone who compromises the workload or its credentials.
Q: What do security teams get wrong about post-authentication monitoring?
A: They often assume authentication, endpoint monitoring, or configuration scanning is enough to capture identity risk. Those controls see pieces of the environment, but they usually miss the moment an identity touches a sensitive resource or assumes a risky role in production. Without runtime attribution, valid abuse can look normal.
A: They should isolate the session and contain the identity path, not just the resource the identity touched. If the activity is attributed to a service account, vendor, or AI agent, the response should include revoking the session, cutting off delegated access, and preserving the full action timeline for investigation.
Technical breakdown
Why post-authentication visibility is missing from identity stacks
Identity providers confirm that a login succeeded, but they usually do not follow the session into production to observe what happens next. EDR focuses on endpoint activity, while CSPM and configuration tools assess environment state at scan time. That leaves a blind spot between authenticated access and runtime action attribution. The core technical issue is not log volume, but where the telemetry stops: valid credentials can be used for benign work or abuse, and the difference is only visible if the action is mapped back to the originating identity in real time.
Practical implication: teams need runtime identity attribution, not just authentication records or periodic posture scans.
How production identity behaviour models work
A production identity behaviour model builds a pattern of life for each identity inside a specific environment. Rather than comparing a service account to industry averages, the model learns that identity's normal resources, timing, role assumptions, and sequence of actions from local event streams. When the identity does something outside its own baseline, the system can flag it as risky even if the credential is valid and the action would not trigger a conventional alert. This makes behaviour, not credential state, the primary signal.
Practical implication: tune baselines per identity and environment, not per broad identity type alone.
Why AI agents and third-party access widen the post-login gap
AI agents running under human or service account credentials inherit the permissions of the identity they use, which means their actions are attributed to the underlying account unless runtime telemetry separates them. Third-party identities create a similar problem because vendors and integrations often drift beyond the original access scope after onboarding. In both cases, the identity itself looks legitimate while the activity can expand beyond intended use. The governance issue is not only access grant, but continuous behavioural validation.
Practical implication: monitor delegated and inherited access as active behaviour, not as static entitlement.
Threat narrative
Attacker objective: The objective is to perform harmful actions inside production while remaining inside the boundary of valid authentication and trusted identity.
- Entry occurs when a valid credential or role assumption succeeds, whether used by a legitimate actor, a compromised service account, or an AI agent running under inherited access.
- Escalation happens after authentication when the session touches resources, roles, or data flows outside the identity's normal pattern of life, but still within the permissions granted.
- Impact follows when risky runtime behaviour is not detected in time, allowing data movement, configuration changes, or lateral access to continue under a trusted identity.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Post-authentication visibility is now an identity governance problem, not a tooling gap. Authentication controls answer who entered, but production governance has to answer what the identity did after entry. Once service accounts, vendors, and AI agents begin operating inside live environments, the real control plane becomes behavioural, not simply declarative. IAM teams should treat runtime identity activity as a first-class governance domain.
Runtime identity attribution is the named concept this market has been missing. The operational failure is not that organisations lack more logs, but that most stacks cannot tie an action back to the identity that performed it at the moment it happens. That gap matters because a valid credential can conceal benign automation or harmful abuse with equal ease. Practitioners should build around attribution at runtime, not retrospective correlation.
Production behaviour baselines should be built per identity, not per class. A developer, a CI/CD pipeline, a third-party vendor, and an AI agent can all authenticate successfully while exhibiting radically different normal patterns. Group-level expectations are too coarse to distinguish legitimate bursts from risky drift. The implication is that governance models need identity-specific operating norms, especially where access is inherited or delegated.
AI agents expose the weakest assumption in current access governance. Least privilege is often designed for human-paced decision cycles and stable role expectations. That assumption fails when an AI agent executes multi-step actions under borrowed credentials, because the actor's runtime behaviour can change faster than review cycles can observe it. The implication is that identity governance has to re-think how privilege is bounded when the executor is not human-paced.
Third-party and non-human access should be treated as continuously evaluated relationships. Onboarding is not the control boundary if vendors, integrations, and workloads continue to act long after the original grant. Access reviews that only restate entitlements miss drift in actual use. Practitioners should manage these identities as living production relationships, not static access records.
From our research:
- 91% of active production identities are non-human, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why runtime attribution matters more than static inventory.
- That visibility gap is explored further in 52 NHI Breaches Analysis, where repeated credential and lifecycle failures show up across incidents.
What this signals
Runtime identity governance is becoming the next control boundary. When 91% of active production identities are non-human, the operational question is no longer whether access was granted, but whether the organisation can see what the identity did after login. That pushes IAM, PAM, and NHI teams toward continuous behavioural validation rather than periodic review. For background on the scale of the problem, see the Ultimate Guide to NHIs.
Post-authentication monitoring will need to be built into incident response, not bolted on after it. The gap ClearVector describes is the same gap many teams discover during forensics: the identity session is already over by the time the analyst starts reconstructing it. That means the programme should prioritise live attribution, session containment, and production identity baselining as core controls rather than specialised extras.
Identity blast radius is the concept practitioners should now use to plan control coverage. It is the difference between what an identity is allowed to do and what it actually does during a live session. As AI agents, third parties, and service accounts inherit broader access, the blast radius becomes a runtime problem and not just an entitlement problem. The governance reference point here is the 52 NHI Breaches Analysis.
For practitioners
- Map runtime identity attribution gaps Inventory which production systems can tie actions back to the originating identity at the moment they occur. Prioritise AWS, GCP, Azure, CI/CD, and third-party access paths where authentication logs exist but behavioural attribution does not.
- Build per-identity behaviour baselines Derive normal activity from each identity's own pattern of life, including time of day, resource scope, role assumptions, and action sequence. Use that baseline to flag out-of-pattern activity even when credentials remain valid.
- Separate inherited access from human intent Identify where AI agents, automation, or vendors operate under borrowed human credentials. Reclassify those sessions for monitoring so the underlying account does not hide the real actor's blast radius.
- Contain the identity, not just the resource Make isolation workflows capable of suspending sessions, revoking role chains, and cutting off identity-mediated access in one response path. Resource-level quarantine alone is too slow when the session is still active.
Key takeaways
- Post-authentication behaviour is the blind spot that matters most in production identity security.
- Most active production identities are non-human, so runtime attribution has to be part of IAM and NHI governance.
- Teams that can isolate the session and attribute the action in real time will contain more identity-driven incidents before they spread.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | The article centres on credential-driven NHI visibility gaps and runtime risk. |
| NIST CSF 2.0 | DE.CM-7 | Continuous monitoring is the core control theme in the report. |
| NIST Zero Trust (SP 800-207) | The article argues for continuous verification after authentication, which aligns with zero trust. | |
| NIST SP 800-53 Rev 5 | AU-6 | Runtime attribution and investigation depend on effective audit review and analysis. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0008 , Lateral Movement | The article discusses valid credential abuse and movement through production identities. |
Use attack-pattern mapping to prioritise production identities that can support credential abuse or lateral movement.
Key terms
- Post-Authentication Visibility: Post-authentication visibility is the ability to observe what an identity does after it has successfully logged in or received a token. It is the difference between knowing access was granted and knowing whether that access is being used safely, unusually, or maliciously.
- Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.
- Pattern of life: A pattern of life is the normal behavioural profile of a specific identity in a specific environment. It includes timing, resources, role usage, and action sequence, and it becomes the baseline for identifying abnormal or risky behaviour during live operations.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
What's in the full article
ClearVector's full report covers the operational detail this post intentionally leaves for the source:
- The production identity composition breakdown across AWS and GCP environments, including the split between non-human, third-party, and human identities.
- The event-stream and sensor model used to build per-identity pattern-of-life baselines from live production activity.
- The runtime detection and isolation workflow for investigation, triage, and identity containment.
- The article's examples of post-authentication blind spots in EDR, IdP, and CSPM tooling.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org