Static GitHub tokens in AI systems expose the NHI governance gap

At a glance

What this is: Aembit’s analysis of CrewAI shows how an exception response during provisioning exposed an internal GitHub token with administrative access to private repositories.

Why it matters: IAM and NHI teams should treat long-lived tokens in AI and automation workflows as high-blast-radius credentials that can surface through ordinary failure paths.

By the numbers:

• 65% had unintentionally leaked secrets in GitHub repositories, including deleted forks that still contained valid credentials.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.

👉 Read Aembit’s analysis of CrewAI token exposure and static credential risk

Context

Static credentials create hidden risk because they outlive the task they were meant to perform and can surface in places that were never designed to hold secrets. In NHI governance terms, the problem is not only leakage, but privilege concentration: when a single token can reach private code, automation, and configuration, a routine error becomes a security event.

The CrewAI case is a useful example of a broader pattern rather than an isolated oddity. AI platforms and adjacent automation stacks accumulate service accounts, tokens, and integration keys faster than teams can review them, which makes exception handling, logs, and debugging paths part of the control surface. For practitioners, that means access design has to assume failure, not just normal operation.

Key questions

Q: How should security teams handle long-lived GitHub tokens in AI workflows?

A: Treat them as temporary exceptions and replace them with runtime-issued, narrowly scoped credentials wherever possible. Long-lived tokens are too easy to overuse, too hard to inventory, and too likely to appear in logs or failure output. If they must exist, bind them to a named workload, reduce permissions, and rotate them aggressively.

Q: Why do AI platforms create more risk around non-human identities?

A: AI platforms increase the number of service accounts, integrations, and automation paths that need credentials, which raises the chance that a secret will be exposed or overprivileged. They also expand the places where secrets can leak, including provisioning flows, debug messages, and orchestration logs. That makes identity design part of core platform security.

Q: What is the difference between static secrets and dynamic workload identity?

A: Static secrets are reusable credentials that stay valid until someone rotates or revokes them. Dynamic workload identity issues access at runtime for a specific task and limits how long that access remains valid. The second model reduces secret persistence, shrinks blast radius, and gives practitioners a better control point for automation and AI systems.

Q: When should organisations prioritize secrets rotation over broader identity redesign?

A: Rotation helps after exposure, but it should not be the end state when the underlying model keeps leaking or overextending access. If tokens are long-lived, broadly scoped, or embedded in workflows, redesign should come first because rotation only resets the same risk. Use rotation as containment, then move to shorter-lived identity models.

Technical breakdown

How exception handling exposes privileged non-human identities

An exception response is the output a service returns when a request fails unexpectedly. If that response includes internal objects, stack traces, file paths, or embedded credentials, the failure path becomes a disclosure path. In this case, the critical issue is not that GitHub tokens exist, but that a provisioning failure allowed a privileged token to leave the trust boundary. This is a classic NHI problem: machine credentials often sit deeper in systems than human-authentication controls do, and developers may not treat them as secrets when they appear in debug or error output.

Practical implication: Remove secret-bearing fields from all error responses and treat failure paths as secret-exposure surfaces.

Why long-lived GitHub tokens create a large identity blast radius

Long-lived tokens are static credentials that remain valid until revoked or rotated. When they carry administrative scope, they behave like privileged non-human identities with broad, durable reach across repositories, workflows, and downstream automation. The problem compounds over time because these credentials accumulate permissions as systems grow, then remain present in logs, config files, histories, and third-party integrations. That makes the blast radius much larger than the original workflow that created the token.

Practical implication: Shrink token scope, shorten lifetime, and map each token to one narrowly defined workload or repository function.

How dynamic workload identity changes the exposure model

Dynamic workload identity ties access to runtime context instead of embedding a reusable secret in the application or pipeline. The credential is issued for a specific purpose, for a limited time, and under explicit policy, which means there is less to leak and less value if leakage occurs. This does not eliminate compromise, but it changes the economics of exposure. For AI systems that depend on provisioning, integration, and agent workflows, ephemeral credentials are a better fit than static tokens because they reduce persistence and narrow reuse.

Practical implication: Adopt runtime-issued credentials for AI and automation workloads wherever the system can support them.

Threat narrative

Attacker objective: Use the exposed administrative token to gain broad control over private source code and related automation assets.

1. Entry occurred through a provisioning failure that triggered an exception response inside the AI platform.
2. The exception response exposed an internal GitHub token with administrative access to private repositories.
3. A compromised token could enable repository review, code modification, workflow interference, and secondary secret harvesting.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.

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

NHI Mgmt Group analysis

Static secrets remain the wrong control primitive for AI systems. The CrewAI exposure shows that long-lived tokens are not just harder to manage, they are more failure-prone because they can appear in logs, errors, and provisioning artifacts. As AI platforms expand their integration surface, static secrets create a governance burden that grows faster than operational oversight. Practitioners should treat static credentials as temporary exceptions, not the default.

Identity blast radius is now a first-class metric for NHI governance. A token with administrative repository access is not equivalent to a narrowly scoped workload credential, even if both are machine identities. The difference is how much damage a single exposure can cause across code, CI/CD, and downstream systems. Governance programs should measure scope, lifetime, and reuse together, then reduce all three.

Exception handling must be governed as part of access control. Teams often separate application reliability from identity security, but this case shows that error paths can expose the same secrets that access policies are meant to protect. Secure-by-design review should include what a service returns when it fails, not just how it authenticates when it succeeds. The practical conclusion is to review failure modes as part of NHI control design.

Dynamic access is becoming the baseline expectation for agentic AI environments. AI systems that depend on static credentials will keep inheriting the same exposure pattern, even if surrounding tooling improves. The market signal is clear: practitioners need identity models that issue credentials at runtime, bind them to workload context, and limit their lifetime by policy. That shift is now a governance requirement, not an optimization.

From our research:

• 65% had unintentionally leaked secrets in GitHub repositories, including deleted forks that still contained valid credentials, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities. That pattern shows how often NHI exposure moves from theory to incident response, according to The 2024 ESG Report: Managing Non-Human Identities.
• Use the 52 NHI breaches Report to compare this exposure pattern with real breach paths and remediation lessons across 52 case studies.

What this signals

Ephemeral credential trust debt is the gap between how quickly modern AI systems need access and how slowly many organisations still retire static secrets. As machine identities spread across development and orchestration stacks, the programme risk shifts from isolated leakage to repeatable exposure conditions, which is why NHI controls need to be built into provisioning, review, and revocation workflows. For broader control mapping, align these patterns with the OWASP Non-Human Identity Top 10.

With more than 1 in 5 of their non-human identities already considered insufficiently secured in our referenced research, the operational question is not whether AI systems will accumulate risky credentials, but how fast teams can reduce their lifetime and scope before they are exposed. That makes identity review cadence, exception response hygiene, and workload binding decisions part of the security roadmap.

For teams building zero-trust controls around AI platforms, the practical signal is clear: move access decisions closer to runtime and away from reusable secrets. The governance model should combine least privilege, short-lived access, and continuous review, then measure whether exception handling can ever surface a credential. If it can, the control design is still incomplete.

For practitioners

• Eliminate secret leakage from exception paths Review all error handlers, debug responses, and provisioning workflows for embedded tokens, repository paths, or configuration fragments. If a failure can expose a credential, treat it as a design defect and remove the data before release.
• Replace static repository tokens with runtime-issued credentials Use short-lived, scoped credentials for GitHub and related automation wherever runtime identity is available. Reserve persistent tokens only for documented exceptions, and track every exception as a risk acceptance item.
• Shrink administrative scope on machine identities Audit every token and service account for unnecessary repository-wide or org-wide permissions. Move to least privilege, separate build, deploy, and maintenance functions, and revoke broad access that is not required for current operations.
• Expand scans to hidden credential stores Search deleted forks, historical branches, logs, CI output, and developer-owned repositories for secrets that may have escaped earlier reviews. Hidden copies often survive rotation and can remain valid long after teams think a token is gone.

Key takeaways

• CrewAI’s token exposure shows how a routine failure path can turn a machine credential into a broad repository security issue.
• Static tokens remain a governance problem because they increase blast radius, persist too long, and can surface in logs or exception responses.
• NHI programmes should prioritize runtime-issued credentials, tight scope, and failure-path review to reduce exposure before incidents occur.

Key terms

• Static Secret: A static secret is a reusable credential such as a token, API key, or certificate that stays valid until someone revokes or rotates it. In NHI environments, static secrets are high-risk because they can be copied, logged, or exposed in places that were never meant to store access material.
• Dynamic Workload Identity: Dynamic workload identity is an access model that issues credentials at runtime for a specific workload, task, or session. It reduces secret persistence and limits reuse, which makes it better suited to AI systems, automation pipelines, and other non-human identities that change context quickly.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised credential can cause before it is revoked. For non-human identities, it is shaped by scope, duration, and where the credential can reach across repositories, pipelines, cloud services, and downstream automation.
• Exception Response: An exception response is the message a service returns when it encounters an unhandled error during a request. In security terms, it matters because poor error design can expose internal paths, system state, or embedded secrets that should never leave the trust boundary.

Deepen your knowledge

Static GitHub token exposure and dynamic workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning AI and automation access around short-lived credentials, it is worth exploring.

This post draws on content published by Aembit covering the CrewAI GitHub token exposure: static credential risk in AI systems. Read the original.