Trusted third-party NHI activity can mimic a breach

At a glance

What this is: A third-party NHI used a GitHub App token to clone content from a public repository from an unknown laptop while also behaving normally elsewhere, producing a breach-like identity anomaly.

Why it matters: IAM and security teams need correlation across NHI, SaaS integrations, and identity behaviour because isolated alerts often miss concurrency, context, and whether trusted access has shifted outside its expected boundary.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read Exaforce's analysis of trusted third-party NHI activity that mimicked a breach

Context

Trusted third-party access becomes an identity governance problem when the actor is a non-human identity and the behaviour no longer matches the baseline. In this case, a GitHub App token was used to create a JWT and access a repository from an unexpected device while the same identity was also active in its normal cloud environment, which is exactly the sort of pattern that breaks simple alert-by-alert monitoring for NHI governance.

The key issue is not whether the action was well intentioned. It is that identity context, device context, and timing context all changed at once, which made the activity indistinguishable from compromise until the signals were correlated. That is a typical failure mode in cloud and SaaS environments where third-party integrations carry real access but weak behavioural guardrails.

For practitioners, the lesson is that trusted access must be evaluated as an identity relationship with lifecycle, location, and usage constraints, not just as a token that works.

Key questions

Q: What breaks when a trusted third-party NHI behaves like a threat actor?

A: The main failure is that teams can no longer trust the identity boundary. A valid token may still be used in ways that violate device, network, or concurrency expectations, so alert-by-alert review misses the full risk. Practitioners need correlation and lifecycle ownership, not just authentication logs.

Q: Why do third-party NHI incidents often look legitimate at first?

A: Because the access can be technically valid while the behaviour is operationally wrong. A vendor integration may have permission to act, but if it appears on an unknown laptop, from a residential ISP, or alongside normal cloud activity, the anomaly is in context, not in authentication alone.

Q: How should security teams handle risky behaviour from non-human identities without breaking production?

A: Treat response as a business-impact decision, not just an alert workflow. First determine what the identity supports, who owns it, and whether disabling it would interrupt critical services. Then use scoped containment, credential isolation, or permission narrowing before resorting to full deactivation.

Q: Who is accountable when a third-party integration is abused?

A: Accountability belongs to the business owner, the platform owner, and the identity team together, because connected apps sit across operational boundaries. If no one can state who approved the grant, who renews it, and who revokes it, the organisation has a governance gap. Ownership must be explicit before incidents happen.

Technical breakdown

Why GitHub App tokens and JWTs can obscure identity context

GitHub App tokens are short-lived credentials used by integrations to authenticate as a specific app, often by minting a JWT first and then exchanging it for scoped access. That model is efficient, but it can hide the human or operational context behind the request if telemetry only shows the token and not the device, network, or concurrent session state. In NHI governance, the token may be valid while the behaviour is still unsafe. The control problem is therefore not authentication alone, but identity correlation across the issuer, the session, the device, and the workload environment.

Practical implication: correlate token use with device, network, and concurrency signals before treating access as routine.

Why concurrent activity from one identity is a high-confidence anomaly

The article’s key clue was not a single unusual event, but the same identity appearing to operate in two places at once. That is a strong indicator because non-human identities should normally follow deterministic execution patterns, not simultaneous manual-style and cloud-native behaviour from different environments. When a bot identity shows impossible travel, residential ISP origin, and a workstation client at the same time as normal cloud activity, the question is no longer whether one alert is noisy. The question is whether the identity has been used outside its intended operational boundary.

Practical implication: build detection logic that scores concurrency and behavioural incompatibility, not just individual anomalies.

Why treat-as-breach triage is the right default for trusted third parties

Trusted third-party identities sit in a governance gap between vendor operations and customer expectations. When they behave like threat actors, the evidence can be legitimate access used in an unsafe way, not necessarily compromise by an external attacker. That is why the triage posture should start from containment and evidence preservation rather than intent debate. In practice, identity-centric detection must support fast suspension of third-party integrations, revocation of administrative authentications, and timeline reconstruction so the team can separate acceptable automation from dangerous out-of-band use.

Practical implication: formalise treat-as-breach handling for third-party NHI anomalies before the first ambiguous incident arrives.

Threat narrative

Attacker objective: The objective is to use trusted non-human access in a way that bypasses normal scrutiny and reaches repository content without triggering immediate compromise certainty.

1. Entry occurred through a third-party SaaS integration using a GitHub App token that generated a JWT and authenticated access to clone repository content.
2. Escalation was indicated by concurrent activity from the same identity in a normal cloud environment and from an unknown laptop over a residential ISP, which created an impossible travel pattern.
3. Impact was limited to non-public-facing repository access in this case, but the same pattern could expose internal documentation, runbooks, or sensitive data if the target repository were different.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

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

NHI Mgmt Group analysis

Trusted third-party NHI behaviour is now a breach-class signal, not a support exception. This incident shows that organisations cannot rely on the intent of the actor to determine severity once a non-human identity departs from its baseline. When a third-party integration behaves like a person using a workstation from a residential network while also appearing active in its normal cloud context, the governance question becomes whether the identity relationship itself is still trustworthy. Practitioners should treat that as an identity-control issue, not a helpdesk ambiguity.

Identity correlation is the named concept this case makes unavoidable: isolated alerts are too weak when a single NHI can generate valid activity across multiple environments at once. Geographic anomaly, network change, and repository access are all noisy in isolation, but concurrency turns them into a coherent risk signal. That means NHI governance has to join identity, device, and session context before analysts can distinguish expected automation from unsafe third-party behaviour. The practitioner conclusion is simple: if the platform cannot correlate, it cannot adjudicate.

Third-party access without lifecycle accountability creates hidden exposure windows. The control gap here is not just that a token was valid, but that the operational boundary for that token could be stretched outside its intended use without immediate programmatic rejection. That reveals a governance assumption that trusted vendor activity will stay inside normal infrastructure and expected timing. The implication is that offboarding, revocation, and usage constraints for vendor-held NHIs must be as explicit as they are for internal service accounts.

Bot identities require behavioural baselines that assume they do not travel, browse, or switch execution environments. The article is a reminder that bot classification is only useful if the controls are tuned to the expected physics of the identity. A non-human identity that suddenly looks interactive is not “just unusual”, it is outside modelled behaviour. Practitioners should use that distinction to elevate priority and reduce tolerance for noisy exceptions in third-party integrations.

One impossible travel event is less important than the fact that two realities coexisted. The most valuable lesson is not the alert count, but the fact that normal cloud execution and manual-style repository access happened at the same time under one identity. That is a structural identity governance failure mode, because standing trust was strong enough to permit access but weak enough to permit misuse without immediate containment. Teams should re-evaluate which integrations are allowed to behave as if they are both automated and interactive.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to the same report.
• For a broader breach pattern view, see 52 NHI Breaches Analysis for recurring control failures and root causes.

What this signals

Identity correlation is becoming the deciding control for trusted third-party access. When a bot identity can appear normal in one environment and suspicious in another at the same time, old alert tuning is no longer enough. Practitioners should expect higher pressure on detection engineering to combine token telemetry, device evidence, and session overlap into one incident view, especially for vendor-managed integrations. See also Ultimate Guide to NHIs , Key Challenges and Risks.

With 72% of organisations already reporting or suspecting an NHI breach, per the 2024 ESG Report: Managing Non-Human Identities, the operational question is no longer whether third-party NHI anomalies will happen. It is whether your programme can prove which behaviour is acceptable before a support incident becomes a security incident.

The next maturity step is to treat vendor-held credentials as governed identities with explicit lifecycle ownership, not as background plumbing. That means offboarding, suspension, and exception handling need to be testable in the same way as internal access reviews, and the policy should be clear before the first ambiguous event arrives. See Ultimate Guide to NHIs , Regulatory and Audit Perspectives.

For practitioners

• Correlate identity, device, and network context for every third-party token. Require detection logic to join token use, source network, user agent, geography, and concurrent session state before escalating or suppressing an NHI alert. Use this to distinguish normal automation from unsafe out-of-band use, especially for GitHub App and SaaS integration identities.
• Treat concurrent activity as a high-severity anomaly for bot identities. Define impossible travel and dual-environment execution as breach-class indicators for non-human identities, even when each individual alert looks explainable. This is especially important when the same identity appears in cloud infrastructure and on a residential laptop at the same time.
• Suspend third-party integrations before the intent debate is resolved. Build a playbook that allows rapid suspension of a third-party NHI, revocation of administrative authentications, and preservation of forensic evidence once behaviour crosses the trust boundary. The goal is to contain risk before analysts finish determining whether the activity was malicious or unsafe support work.
• Map vendor-held NHI lifecycle ownership explicitly. Document who can approve, use, rotate, and revoke each external integration credential, then test whether that ownership still holds when support teams act under time pressure. If lifecycle accountability is unclear, the access path is already too permissive.

Key takeaways

• Trusted third-party NHI activity can look like compromise even when the underlying action is a support workaround.
• The strongest evidence in this case was concurrency, not any single noisy alert or isolated anomaly.
• Lifecycle ownership and behavioural correlation are the controls that separate legitimate integration use from unsafe out-of-band access.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Impossible Travel: A detection pattern that flags two sign-ins from locations too far apart to be physically plausible in the time available. In SaaS identity work, it becomes useful only when paired with baseline user behaviour, proxy indicators, and follow-on account actions.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Identity correlation: Identity correlation is the process of linking multiple account records to one governed subject. It lets IAM and IGA teams understand that separate usernames, principals, or emails may belong to the same employee or workload, which is essential for access review, offboarding, and entitlement analysis.

What's in the full article

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

• The specific alert aggregation logic used to collapse multiple noisy signals into one incident.
• The exact sequence of response actions, including suspension of the third-party integration and revocation of administrative authentications.
• The platform telemetry pattern behind the impossible travel assessment for the bot identity.
• How the team distinguished unsafe support activity from an external breach after investigation.

👉 The full Exaforce post covers the incident timeline, identity signals, and response sequence.

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.