CrewAI token exposure shows how AI platforms can widen NHI blast radius

At a glance

What this is: A CrewAI vulnerability exposed a high-privilege GitHub token through improper exception handling, turning an error path into full repository access risk.

Why it matters: For IAM and NHI teams, this is a reminder that AI platforms can leak standing credentials through runtime failures, not just through code or vault misconfigurations.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today.

👉 Read Noma Security's analysis of the CrewAI token exposure and Uncrew flaw

Context

AI platforms now sit inside application and infrastructure workflows, which means their failure modes can become identity failures. In this case, a deployment error exposed a GitHub token, so the problem is not simply one leaked secret but the way runtime exceptions can surface NHI credentials into places users can reach.

For IAM and NHI practitioners, the lesson is that secret exposure can emerge from operational paths that security teams do not always classify as credential handling. That makes exception hygiene, token scope, and revocation speed part of the governance model, not just engineering details.

Key questions

Q: How should security teams respond when an AI platform leaks a GitHub token?

A: They should revoke the token immediately, assess its privilege scope, and review repository activity for misuse. Then they should rotate any related credentials, search for secondary secrets in affected repositories, and fix the failure path that exposed the token in the first place. The goal is to shrink blast radius before an attacker can turn one leak into broader compromise.

Q: When does a leaked machine credential become a supply-chain risk?

A: A leaked machine credential becomes a supply-chain risk when it can change code, trigger workflows, or expose additional secrets inside source control. At that point, the issue is no longer limited to one account. It can affect build integrity, downstream releases, and the trust that other systems place in the platform.

Q: What is the difference between secret rotation and least privilege for NHIs?

A: Secret rotation changes credentials over time, while least privilege limits what those credentials can do at any moment. Rotation reduces the window of exposure after disclosure, but least privilege limits the damage if the secret is stolen. Strong NHI governance requires both controls because each addresses a different failure mode.

Q: Why do AI platform errors create identity risk for IAM teams?

A: AI platform errors can expose tokens, internal identifiers, or backend state because many orchestration systems return rich diagnostic payloads. That turns reliability issues into identity issues. IAM teams should treat error handling, logging, and debugging paths as part of the credential lifecycle, not as separate application concerns.

Technical breakdown

How exception handling becomes a secret exposure path

Exception handling is meant to fail safely, but in distributed AI platforms it often becomes a data boundary problem. If a backend returns full JSON payloads or logs raw error objects, fields that should have been redacted can leak tokens, repository URLs, or internal identifiers. In this case, a deployment-status failure exposed a GitHub token through the response path. The underlying issue is not the token itself but the combination of privileged credentials, poor sanitisation, and user-visible error surfaces. Once a secret appears in an error channel, the attack surface expands to anyone who can trigger the failure condition.

Practical implication: Treat error responses, logs, and debug output as credential-bearing surfaces and redact them before release.

Why a single GitHub token can create NHI blast radius

A GitHub access token is a non-human identity because it authenticates software to a platform and can carry standing permissions. When that token has administrative scope, it can do far more than read code. It can clone private repositories, alter workflows, harvest embedded secrets, and seed supply-chain compromise through poisoned commits or automation changes. The blast radius grows when the token is reused across internal systems or paired with other privileged automation. For NHI governance, this means scope minimisation and short-lived credentials matter as much as detection, because one exposed secret can expose an entire software trust chain.

Practical implication: Map every machine credential to its effective blast radius and reduce repository-level privilege wherever possible.

What AI platform provisioning flows change for secret governance

Provisioning workflows often combine orchestration, polling, and external integrations, which makes them dense with identity dependencies. If a failed deployment returns internal state to the requester, the platform has effectively turned a control-plane error into a credential disclosure event. That pattern is especially risky in AI systems because build, deployment, and agent orchestration often touch code repositories, model assets, and service accounts in the same flow. The security boundary is therefore not just the API endpoint but the whole lifecycle of the provisioning transaction. Organisations need to design for failure, not only for successful runs.

Practical implication: Review AI provisioning pipelines as identity-sensitive workflows and test how they behave when deployments fail.

Threat narrative

Attacker objective: The attacker aims to turn one exposed internal token into persistent access to private source code and downstream software trust paths.

1. Entry occurred when an authenticated user or requester triggered a deployment-status failure in the CrewAI provisioning flow.
2. Escalation happened when the backend returned a full JSON payload that included a high-privilege GitHub token in the repo_clone_url field.
3. Impact could include repository cloning, workflow tampering, secondary secret harvesting, and supply-chain compromise across dependent users.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.
• 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

The real issue is not token leakage alone, but identity blast radius. A high-privilege GitHub token can expose code, workflows, and embedded secrets at once, which means one disclosure can become a platform-wide compromise. In NHI governance terms, the control failure is over-scoped standing access paired with weak failure-path hygiene. Practitioners should measure exposed-secret impact by blast radius, not by the number of leaked credentials.

AI platform errors are now credential events. When deployment tooling, orchestration layers, and agent runtimes surface raw exception data, they can leak non-human identities just as easily as application secrets. That collapses the old separation between application reliability and access control. Teams should treat every error surface as part of the NHI control plane and require redaction by default.

Short-lived secrets matter, but only if the surrounding workflow supports revocation. Rotation after disclosure is necessary, yet it does not reduce exposure if tokens remain broad in scope or if detection is slow. The practical standard is to pair minimal privilege with fast invalidation and continuous audit. Practitioners should assume leaked machine credentials will be attempted quickly and govern accordingly.

AI platform governance must include failure testing, not just access reviews. Traditional reviews check who can use a secret, but this case shows that the bigger question is how secrets behave when systems fail. Exception paths, debug outputs, and provisioning errors should be tested with the same rigor as authentication and authorisation flows. Teams that ignore failure testing are leaving the most dangerous credential paths unexamined.

Credential leakage in AI tooling is becoming a supply-chain issue, not a point incident. When a platform repository is exposed, downstream users inherit the risk through code, automation, and update channels. That means NHI governance must extend beyond the perimeter of the application team. Practitioners should align secret controls with software supply-chain assumptions before the next runtime exception becomes a breach.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to the Secret Sprawl Challenge.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For practitioners: Map exposed GitHub tokens back to the 52 NHI breaches analysis and the OWASP Non-Human Identity Top 10 to prioritise revocation, scope reduction, and post-exposure audit.

What this signals

Identity blast radius is now the right lens for AI platform risk. A single exposed GitHub token can compromise source code, workflow integrity, and secondary secrets at the same time, so access reviews need to measure downstream reach, not just credential count. Teams that still separate application defects from identity governance will miss the failure mode that matters most.

The governance implication is straightforward. If an AI platform can leak a secret during ordinary exception handling, then exception testing belongs beside access review, token rotation, and repository audit in the control set. That is where the NHI programme has to mature, because runtime failures are now part of the access surface.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, secret leakage is spreading into new control planes as AI adoption widens. Practitioners should expect the same pattern in agent orchestration and deployment tooling, then harden those paths before they become the next disclosure channel.

For practitioners

• Redact secrets in every failure path Test deployment, orchestration, and agent runtime errors for raw credential exposure. Mask repository URLs, tokens, and internal identifiers before they can reach users, logs, or support channels.
• Reduce GitHub token scope to the minimum viable set Audit repository and automation tokens for admin privileges, long-lived access, and reuse across environments. Reissue credentials with least privilege and separate build access from repository administration.
• Treat revocation as a first-class control Build automated token invalidation and rotation into incident response so that exposed credentials can be disabled quickly. Reversal speed matters when secrets are reachable through public error paths.
• Test provisioning flows for secret leakage Simulate failed deployments and verify that error responses do not include authentication material, internal state, or backend payloads. Include exception handling in security review checklists for AI platform engineering.
• Audit repository access after any credential exposure Review clone, push, and workflow execution logs for unusual activity, especially where a leaked token could reach private repositories. Pair log review with secondary secret discovery across code and config files.

Key takeaways

• A single exposed GitHub token can become a broad NHI incident when it carries administrative scope across private repositories and workflows.
• AI platform failure paths matter because exception handling can leak credentials just as reliably as code repositories or misconfigured vaults.
• Practitioners should pair least privilege with rapid revocation, error redaction, and provisioning-flow testing to reduce identity blast radius.

Key terms

• Non-Human Identity: A non-human identity is a machine account, token, certificate, API key, or agent credential used by software rather than a person. These identities often operate with standing privileges and broad reach, so governance must cover their issuance, use, rotation, and revocation across systems and workflows.
• Identity blast radius: Identity blast radius is the amount of access, data, and operational control that an exposed credential can affect. In NHI programmes, it is a practical way to judge whether a single leaked token is a minor event or a platform-wide compromise opportunity.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across repositories, logs, tickets, configuration files, and AI tooling. It becomes dangerous when organisations rely on detection alone, because exposed secrets can remain valid long after they are discovered and can be reused by attackers.
• Exception handling leakage: Exception handling leakage occurs when error responses reveal sensitive values that should have been redacted. In AI platforms and orchestration layers, this can expose tokens, internal URLs, or state information and turn a routine failure into an identity incident.

Deepen your knowledge

NHI lifecycle governance and secret exposure response are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI platforms that handle privileged tokens, it is worth exploring.

This post draws on content published by Noma Security covering the CrewAI token exposure vulnerability: Uncrew and its NHI governance implications. Read the original.