As AI platforms grow more complex and interdependent, small failures can cast long shadows.
That’s what happened inside the open-source CrewAI platform, where a vulnerability in its error-handling logic surfaced during a provisioning failure. The resulting “exception response” – the message a service returns when it encounters an unhandled error during a request – contained an internal GitHub token with administrative access to all private repositories inside the organization, creating an exposure that extended far beyond the original malfunction.
The circumstances around the CrewAI flaw, which Noma Security identified and disclosed, show how easily a token can be exposed through standard software development.
It exemplifies a pattern that now touches nearly every software company that relies on long-lived machine credentials to support development, automation, and integration workflows. When a routine failure can return a credential with broad reach, it places customer data and internal systems at risk. The industry will need to move toward short-lived, identity-based access if it wants to reduce the impact of these exposures.
As these systems grow, they accumulate large numbers of service accounts and the various credentials those accounts require, including long-lived tokens. These credentials are often created to sustain continuous deployment, internal automation, and agent provisioning, and they frequently remain present in areas that were never designed to hold sensitive information. A misplaced log, a debugging message, or – as in this case – an exception handler can surface a token that was intended to remain entirely inside the platform.
The token in the CrewAI case held administrative rights, which meant that anyone who obtained it could review source code, modify repositories, interfere with automation workflows, or extract additional secrets stored in configuration files or historical directories.
A token with that scope operates as a privileged non-human identity, and the reach of such identities often grows wider than teams intend. Some remain in place for long periods because pipelines need constant access. Others gather additional permissions over time as development expands and new components are added.
Safeguards That Help Contain Incidents Like the CrewAI Exposure
Well-timed research from Wiz illustrates how widespread this pattern has become. Its analysis of leading AI companies showed that 65% had unintentionally leaked secrets in GitHub repositories, including deleted forks that still contained valid credentials. These exposures included model-access tokens, workflow keys, and API tokens for specialized AI services. Many were introduced through ordinary development activity rather than malicious action.
Tokens with this level of influence create fragility in the software supply chain. They connect to multiple systems, outlast their intended lifetimes, and open direct pathways into core areas of the development environment. Once exposed, they become immediately useful to anyone who encounters them.
A more disciplined identity model would alter the conditions entirely. Short-lived workload identities tied to runtime context would not appear in exception responses, and they would not carry sweeping authority across an organization’s development environment. Their narrow scope and limited lifespan would contain the impact of any exposure.
Organizations working with AI platforms can reduce the likelihood of similar incidents through several practical measures:
1) Limit the information returned in exception responses so that internal details, including repository paths or embedded tokens, are not exposed through routine failures.
2) Replace long-lived static repository tokens with short-lived credentials that obtain permission at runtime and follow a clear policy controlling their scope and duration.
3) Require your vendors use short-lived tokens. Add this to your security reviews and demand an understanding of how your third-parties reduce token risk.
4) Rotate remaining credentials on a reliable schedule and restrict each one to a limited set of tasks.
5) Review and monitor service accounts with the same rigor applied to human users.
6) Expand repository scans to include historical branches, deleted forks, and developer-owned repositories where older secrets may remain.
The New Stakes of Identity in Agentic AI Systems
The CrewAI disclosure shows how a single oversight in an ordinary code path can shape the security of an entire development environment. It arrives at a moment when agentic AI systems are beginning to act across broader portions of the software stack, and their activity depends on non-human identities that move through code, data, and deployment pipelines.
When those identities remain tied to long-lived static tokens, they create quiet points of failure that become more consequential as these systems take on greater autonomy.
A more reliable framework and strategy begins with identities that are issued dynamically, limited to precise functions, and enforced by explicit policy. As AI platforms become even more interconnected, this approach becomes an essential part of operating securely at scale.
