TL;DR: A critical CrewAI flaw exposed a high-privilege GitHub token through error handling, giving access to private repositories and creating supply-chain risk, according to Noma Security. The case shows how AI platforms can turn one leaked secret into broad NHI governance exposure, not just a single credential incident.
At a glance
What this is: Noma Security found that a CrewAI exception-handling flaw exposed a high-privilege GitHub token, turning one credential into access across private repositories.
Why it matters: IAM, PAM, and NHI teams need to treat AI platform tokens as high-impact infrastructure identities because one exposed secret can expand into repository access, code tampering, and downstream supply-chain exposure.
Context
AI platform security failures often start as ordinary credential leaks but end as governance failures. In this case, a single internal GitHub token was exposed through error handling inside CrewAI, which is an NHI problem because the credential belonged to a platform component, not a person.
The practical issue is not just that a token leaked. The issue is that AI platforms increasingly sit inside development and deployment paths where one service identity can touch private code, embedded secrets, and update pipelines, so a single disclosure can widen the attack surface quickly.
For identity teams, this is a reminder that NHI controls must cover AI platform components as first-class identities. If exception handling can surface live credentials, then redaction, privilege scope, and token lifecycle governance are part of the application security baseline, not an afterthought.
Key questions
Q: What breaks when an AI platform exposes a GitHub token in an error response?
A: A single exposed token can turn a routine provisioning failure into repository compromise. If that token has broad privileges, attackers may read or alter private code, harvest embedded secrets, and tamper with the workflows that depend on those repositories.
Q: Why do overprivileged platform tokens create supply-chain risk?
A: Because the same identity that can reach source code can also change what gets built and distributed. Once a token can tamper with repositories or automation, the compromise moves beyond access control and becomes a trust problem for downstream software delivery.
Q: How do security teams tell whether error handling is leaking secrets?
A: Look for tokens, clone URLs, API keys, or other sensitive fields appearing in user-facing errors, stack traces, or debug payloads. Any occurrence means the failure path is part of the secret exposure surface and needs the same review as code and logs.
Q: When should teams treat AI platform credentials as high-impact NHI assets?
A: When the credential can reach repositories, deployment workflows, or embedded secrets, it should be governed like a high-risk non-human identity. At that point, lifecycle, privilege scope, and revocation speed matter as much as initial authentication.
Technical breakdown
How exception handling turned into credential exposure
The flaw described here sits in the failure path, not the normal path. When a provisioning check failed, the backend returned a JSON payload that included a GitHub clone URL with an embedded token. That means error handling was not just leaking metadata; it was surfacing an active authenticator in a response that users could see. In NHI terms, the issue is secret leakage through user-facing exception content, which converts a transient error into a credential disclosure event. Practical implication: redact secrets from every failure response, not only from logs.
Practical implication: treat error paths as secret-exposure paths and remove credentials from all user-visible failure output.
Why one GitHub token created broad platform risk
The exposed token was not limited-scope. According to the article, it carried full administrative privileges across CrewAI’s private GitHub infrastructure, which means the attacker would not need separate escalation to reach code, workflows, or embedded configuration. That is a classic overprivileged NHI pattern: a single credential with access that exceeds the minimum needed for the task. Once a high-privilege token is embedded in platform operations, the blast radius includes source code tampering, secret harvesting, and poisoned updates. Practical implication: privilege scope matters as much as token secrecy.
Practical implication: align each non-human credential to the smallest repository and workflow scope that the task actually requires.
How AI platform identity becomes a supply-chain problem
AI platforms that orchestrate deployments and multi-agent workflows sit close to software delivery, so identity compromise can move from internal access to downstream distribution. If an attacker can use a platform token to alter repositories or automation, the result is not just repository read access. It becomes a software supply chain risk because the compromised identity can influence code that other teams or customers trust. That is why AI platform security and NHI governance now overlap: the identity that exposes code can also distribute risk. Practical implication: treat platform-owned service credentials as supply-chain control points.
Practical implication: include AI platform tokens in supply-chain threat models, not only in repository access reviews.
Threat narrative
Attacker objective: The attacker’s objective is to gain durable control over private code, embedded secrets, and update pathways by abusing one exposed platform credential.
- Entry occurred through improper exception handling during a provisioning failure, which exposed a GitHub access token in a user-visible error response.
- Credential access followed immediately because the token was embedded in the repo clone URL and carried administrative privileges across private repositories.
- Impact would include repository compromise, code tampering, secondary secret harvesting, and supply-chain poisoning through malicious updates.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Single-token exposure becomes identity blast radius when the token governs a platform, not a person. This case is not about one leaked secret in isolation. It shows that AI platforms concentrate identity power, so one compromised NHI can expose source code, automation, and downstream trust relationships at once. The practitioner conclusion is that platform-issued credentials need blast-radius analysis, not just leak detection.
Exception handling is now an NHI control surface. The article shows that a failure response can become a credential delivery mechanism when redaction is incomplete. That is a governance failure, not a coding footnote, because the error path is where secrets escape into the hands of users who should never see them. The practitioner conclusion is to treat error handling as part of the credential governance model.
Overprivileged platform tokens create supply-chain exposure, not merely access risk. Full administrative access to private repositories means a leaked token can alter code, harvest secondary secrets, and poison the software that others depend on. This is where OWASP-NHI and supply-chain security converge: the identity boundary is also a release boundary. The practitioner conclusion is to map repository credentials to distribution risk.
AI platform security and NHI governance are now the same operating problem. Organisations are deploying AI orchestration systems into business workflows before they have mature controls for secret lifecycle, privilege scope, and offboarding. That sequencing mistake means the platform can widen exposure faster than the governance model can respond. The practitioner conclusion is to place AI platforms under the same identity discipline as other high-value service accounts.
Improper offboarding was not the issue here, but the failure mode rhymes with long-lived privilege. The article shows why token lifecycle discipline matters even when the leak comes from an error path rather than stale credentials. Once a token exists with broad rights, every minute it remains valid extends the blast radius. The practitioner conclusion is to govern validity windows as part of identity risk, not as a separate operational detail.
What this signals
Credential leakage in AI platforms is an identity governance issue, not just an application bug. Once a platform token can appear in an exception payload, the governance model has already failed at the boundary where access should have been invisible. Teams should review where their AI orchestration tools generate, store, and disclose non-human credentials before they become the next blast-radius event.
AI platform credentials now sit inside the same risk chain as source control and release integrity. If a leaked token can reach private repositories, the issue is no longer limited to authentication or logging hygiene. Practitioners need to think in terms of code tampering, secondary secret exposure, and downstream trust collapse when they assess platform-owned identities.
For practitioners
- Redact secrets from error responses Review provisioning and deployment failure paths so that clone URLs, tokens, and API keys never appear in JSON responses, stack traces, or user-facing messages.
- Constrain repository-scoped privileges Replace broad administrative tokens with narrowly scoped credentials that can only reach the repositories, branches, and actions the workflow actually needs.
- Rotate and revoke exposed tokens immediately Build a runbook that revokes any token found in an exception payload or log and replaces it with a newly issued credential before reuse can occur.
- Audit AI platform tokens as supply-chain assets Include platform-owned GitHub tokens in source-code and release integrity reviews so repository access is assessed as a software delivery risk.
- Test failure paths for credential leakage Add security tests that simulate provisioning errors and verify that sensitive fields are stripped from every response class the platform returns.
Key takeaways
- A single exposed platform token can create much larger impact than a routine secret leak because it may unlock repositories, embedded secrets, and release paths.
- The article shows how a failure response can become a credential disclosure channel when exception handling does not strip sensitive fields.
- The control that matters most here is not only token rotation, but also removing secrets from every user-visible error path and limiting repository scope.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The token was exposed through an error response, making secret leakage the core failure mode. |
| NHI-05 — Overprivileged NHI | The leaked GitHub token had full administrative privileges across private repositories. | |
| NHI-07 — Long-Lived Secrets | Any exposed token remains exploitable until revoked, extending the blast radius after disclosure. | |
| Recommendation — Scan all user-facing error paths for credential disclosure and remove secrets before responses are returned. Reduce non-human credentials to the smallest repository and workflow scope needed for execution. Shorten token validity and revoke any secret exposed in logs, traces, or exception payloads. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle controls are central when a platform-issued authenticator is exposed. |
| Recommendation — Manage authenticator lifecycle so exposed platform tokens are revoked and replaced immediately. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The incident centers on credential exposure and potential extraction of code and secrets. |
| Recommendation — Map exposed tokens to credential-access and exfiltration activity in your detection and response workflows. | ||
Key terms
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Overprivileged Nhi: An overprivileged NHI is a service account, token, key, or other machine identity that has been granted more access than it needs to do its job. The risk is not theoretical. Excess scope increases blast radius, makes compromise more valuable to attackers, and slows containment when the identity is abused.
- Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
- Supply Chain Risk: Supply chain risk is the chance that a weakness, failure, or compromise in an external supplier, partner, or upstream dependency will affect your organization. It includes software, hardware, cloud, data, and service dependencies, where trust, integrity, availability, or confidentiality can be disrupted through third-party access, updates, or operational failure.
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.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org