Insider risk and cloud runtime correlation for identity investigations

At a glance

What this is: This is a partnership analysis showing how insider-risk and cloud runtime telemetry are linked to turn ambiguous identity signals into a single investigation narrative.

Why it matters: It matters because IAM, PAM, and cloud security teams need identity context and runtime evidence together to judge whether an identity acted maliciously, negligently, or within normal scope.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Above's blog post on insider risk and cloud runtime correlation

Context

Insider risk programmes fail when they stop at intent and never verify impact, or when cloud monitoring shows activity without explaining who initiated it. In identity terms, that leaves investigators with incomplete evidence for the same event. The article is about correlating human behaviour with cloud runtime activity so security teams can connect the identity, the action, and the workload in one decision path.

That gap matters for IAM, PAM, and cloud security because the same identity can look suspicious in one layer and legitimate in another. A departing employee, a compromised account, or an over-permissioned engineer may create very different signals depending on whether the team can see browser, SaaS, API, and AI-service activity together. The typical enterprise already has the telemetry, but not always the joined-up governance model to interpret it.

Key questions

Q: How should teams investigate insider-risk alerts across identity and cloud telemetry?

A: Start by correlating the identity signal to the workload or data event that it touched. If the behaviour cannot be tied to runtime evidence, keep it as a behavioural concern rather than a confirmed incident. The strongest investigations link browser, SaaS, cloud, API, and AI-service activity into one sequence so teams can decide on intent and impact together.

Q: Why do cloud runtime tools miss part of the insider-risk picture?

A: Because cloud tools can show what happened in production but not why the identity did it. Without intent context, the same event may look like normal engineering, negligence, or theft. Teams need identity behaviour attached to the event to prioritise correctly and avoid treating every anomaly as equally risky.

Q: How do security teams know if insider risk detection is actually reducing false positives and investigation time?

A: They should look for clearer reasoning in alerts, fewer ambiguous findings, and faster triage cycles for analysts. Useful signals include whether detections explain why a file or action was flagged, whether reviewers can quickly confirm context, and whether remediation steps are captured with enough detail to support repeatable investigations and policy tuning.

Q: Should AI-service activity be part of insider-risk investigations?

A: Yes. AI-service calls can create the same security consequences as access to databases or object stores, so they belong in the investigation chain. If an identity prompted a model, retrieved data, or triggered a downstream workflow, the runtime impact should be reviewed alongside the identity behaviour.

Technical breakdown

How identity context changes cloud runtime investigations

Identity context tells an investigator whether a cloud action was likely curiosity, negligence, or malicious intent. Runtime telemetry tells the investigator what resource was touched, what data moved, and whether the workload deviated from its baseline. When those two views are separated, teams often overreact to benign anomalies or miss hostile activity hidden inside ordinary-looking cloud operations. The key technical point is correlation across identity, browser, SaaS, workload, API, and AI-service layers, not isolated alerting.

Practical implication: correlate identity signals with runtime evidence before escalating or closing an investigation.

Why cloud telemetry alone does not explain insider behaviour

Cloud runtime tools are strong on what happened in production, but weak on why the identity did it. That matters because the same API call can be part of normal engineering work, an accidental misstep, or an active data theft event. In practice, context needs to travel with the event timeline. Without that, security teams get a stream of technically accurate findings that are still hard to prioritise or prove as risk.

Practical implication: treat runtime findings as incomplete until identity behaviour is attached to the case.

How AI services expand the investigation surface

The article extends the same correlation model to AI services, not just databases and object stores. That is important because AI usage can create a new kind of material action surface where identities prompt models, retrieve data, or trigger downstream workflows. For investigators, the technical question becomes whether the identity only viewed an AI service or actually caused a cloud-side consequence. That distinction changes both containment and evidence collection.

Practical implication: include AI-service calls in insider-risk correlation workflows and case timelines.

Threat narrative

Attacker objective: The objective is to translate suspicious identity behaviour into real cloud-side access, data movement, or service manipulation that creates impact.

1. Entry occurs when a departing employee, compromised account, or over-permissioned engineer begins acting outside the normal identity baseline.
2. Escalation appears when that identity reaches sensitive cloud workloads, object stores, APIs, or AI services that should not be part of routine activity.
3. Impact follows when the runtime activity moves data, touches production resources, or triggers behaviour that changes the security or data posture of the environment.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity investigations are now a correlation problem, not a single-tool problem. Above and Upwind are addressing a common failure in security operations: teams either see the person or see the workload, but not both in a decisionable timeline. That matters because insider risk is judged by intent while cloud runtime is judged by impact. Practitioners should treat this as a governance design issue, not just a telemetry integration.

Cloud runtime evidence without identity context produces false certainty. A file read, API call, or object-store access can look equally suspicious whether it is part of normal work or malicious behaviour. The article shows why investigators need behavioural context attached to runtime evidence before they can make a reliable call. The practitioner conclusion is that alert quality depends on joining human identity signals to cloud activity.

Runtime-context gap: security teams have often built investigations around either user behaviour or cloud events, but not the bridge between them. That gap becomes more visible as sensitive data and AI workloads move deeper into cloud platforms. Once an identity can affect production systems, the question is no longer whether a control fired, but whether the team can prove what the identity actually did. The implication is a more evidence-driven insider-risk operating model.

AI services widen the insider-risk boundary. The article correctly includes AI services alongside workloads and APIs because AI actions can now be part of the same investigative chain as conventional cloud operations. That means identity governance can no longer stop at login, browser, or SaaS activity. Security teams need a shared case model that covers human behaviour, cloud execution, and AI-side consequence together.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% confirmed and 26% suspected.
• For a broader breach lens, The 52 NHI breaches Report shows how identity failures compound across lifecycle, access, and runtime control gaps.

What this signals

Runtime correlation will become a baseline requirement for insider-risk programmes. As cloud workloads and AI services absorb more business-critical action, teams will need evidence that links the identity layer to the runtime layer before they can defend a case. The control gap is not lack of telemetry, but lack of joined interpretation across layers.

AI-service activity should be treated as part of the identity attack surface. If an identity can prompt models, move data, or trigger downstream workflows, then insider-risk review has to extend beyond browser and SaaS behaviour. Teams that ignore AI-side consequence will understate both exposure and blast radius.

With 72% of organisations already reporting or suspecting an NHI breach in our research, the wider lesson is that identity governance must connect behaviour, privilege, and runtime consequence rather than treating them as separate workstreams.

For practitioners

• Correlate identity and runtime timelines Build investigations so browser, SaaS, workload, API, and AI-service events can be reviewed on one case timeline. The goal is to avoid deciding based on either human context or cloud telemetry alone.
• Separate benign anomaly from hostile intent Create triage rules that require an identity explanation before a cloud finding is treated as malicious. That reduces wasted escalations and helps teams distinguish policy drift from real insider risk.
• Include AI-service activity in case design Treat AI-service calls as part of the same evidence chain as database access and object-store movement. If AI endpoints are not in scope, investigations will miss part of the actor's actual impact surface.
• Align insider-risk and cloud teams on a shared threshold Define when an identity-layer signal should trigger runtime review and when runtime anomalies should trigger identity review. That shared threshold prevents gaps between SOC workflows and insider-risk workflows.

Key takeaways

• The article's core point is that insider-risk and cloud security only become actionable when identity intent and runtime impact are analysed together.
• The governance gap is correlation, not visibility alone, because investigators need a single timeline that spans user behaviour, cloud activity, and AI-service consequence.
• Practitioners should redesign case handling so identity signals, runtime evidence, and AI-service activity are reviewed as one investigative chain.

Key terms

• Identity-context correlation: Identity-context correlation is the practice of joining behavioural signals from a person or account with technical evidence from cloud, API, or application activity. It helps investigators decide whether an event reflects normal work, negligence, or malicious intent, rather than treating each layer as a separate story.
• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.
• Insider-risk case timeline: An insider-risk case timeline is the ordered sequence of identity behaviour, access activity, and downstream effects that supports an investigation. It is more useful than isolated alerts because it shows how a suspicious action moved from user context into business impact.
• AI-service activity: AI-service activity is the set of calls, prompts, data retrievals, and downstream actions involving AI services in production. In identity investigations, it belongs in the same evidence chain as databases and APIs because it can create operational impact and data exposure.

What's in the full article

Above's full blog post covers the operational detail this post intentionally leaves for the source:

• The specific integration workflow for pairing Above identity signals with Upwind runtime findings.
• The investigation examples that show how analysts move from suspicion to runtime confirmation.
• The customer-facing use cases for cloud-heavy organisations that need identity plus runtime evidence.
• The referenced Above integrations and related agentic AI risk material.

👉 Above's full post covers the investigation workflow, use cases, and related integration context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.