Enterprises have started treating tokens the way they treat capital, tracking consumption, routing workloads to the cheapest model that will do the job, and holding teams accountable for what they spend. That discipline solves a cost problem. It does not solve a very different problem hiding underneath it. The same AI systems burning through compute tokens are also authenticated, connected, and orchestrated by an entirely separate category of token: the OAuth credentials, API keys, and machine identities that let models talk to data, tools, and each other. Managing token supply in the cost sense means little if the tokens that hold the whole system together are sitting unmonitored, unrotated, and unaccounted for.
WHEN TRUST BECOMES THE ATTACK SURFACE
Every AI deployment of any complexity is really a web of integrations. A model calls a retrieval system, the retrieval system calls a vector database, an agent calls a CRM, and each of those calls is authorized by a token that proves the request is legitimate. Security researchers at Palo Alto Networks’ Unit 42 describe these credentials as the invisible currency of trust in modern cloud environments, and that description applies just as much to AI pipelines as it does to traditional SaaS integrations.
The 2025 Salesloft Drift incident showed what happens when that trust is exploited. A threat actor identified as UNC6395 stole a single OAuth token from a third-party integration and used it to bypass multi-factor authentication entirely, gaining legitimate, persistent access to hundreds of customer Salesforce instances. The attacker never needed to break in through a front door. The token was the front door, already unlocked, and connected systems had no reason to question a credential that looked completely normal.
THREE WAYS THE TRUST BREAKS DOWN
Unit 42’s research identifies a small number of recurring failure patterns behind nearly every major token-related breach, and each one maps directly onto how AI systems are typically built and connected.
The first is the dormant integration, a connection nobody remembers exists but that remains fully authorized. In 2022, GitHub disclosed that attackers had compromised OAuth tokens issued to Heroku and Travis CI integrations that many organizations were no longer actively using. The authorizations simply lingered, and threat actors exploited that forgotten trust to reach private repositories and harvest secrets. An AI pipeline with dozens of connected tools, plugins, and data sources accumulates exactly this kind of forgotten authorization as projects evolve and integrations get replaced without ever being formally revoked.
The second is insecure storage. CircleCI’s 2023 breach involved customer OAuth tokens, environment variables, and SSH keys stored unencrypted in build environments, and once attackers gained internal access, those credentials were simply there for the taking. CircleCI had to ask every customer to rotate every token and secret it held, a costly and disruptive response to a problem that better storage hygiene would have prevented outright.
The third is the absence of expiration. The 2024 Internet Archive breach involved GitLab tokens that had remained valid for 22 months without rotation, giving attackers nearly two years of undisturbed access before they exfiltrated seven terabytes of data. A token with no lifecycle is a vulnerability with no expiration date either.
THE SUPPLY CHAIN GOES DEEPER THAN CREDENTIALS
Token compromise is only one layer of a much larger problem. The Coalition for Secure AI’s Workstream 1 has published detailed guidance on what makes the AI supply chain fundamentally different from a conventional software supply chain, and the difference comes down to where the intelligence actually lives. In traditional software, sensitive logic sits in identifiable places in the code. In AI systems, that intelligence is distributed across millions of weighted connections learned from training data, which means the attack surface extends all the way back to the data an organization never directly controls.
That distributed structure creates risk at every stage. Training data can be poisoned through direct manipulation or by planting malicious content on public web pages that crawlers will later ingest, and the resulting bias or backdoor can remain dormant until a very specific input triggers it. Pre-trained models transferred between organizations carry the same risk in a different form, since weights can be tampered with in storage or during transfer in ways that evade ordinary testing. Even the authentication systems that govern access to a deployed model are themselves part of the supply chain. CoSAI’s framework specifically calls out API key management, token rotation, and role-based access control as core components of model serving infrastructure, meaning the OAuth and credential risks described above are not a separate concern from AI supply chain security. They are one of its central pillars.
Retrieval-augmented generation systems introduce a further wrinkle. The vector databases, embedding models, and context-assembly systems that feed information to a model each represent a potential injection point, and a compromised vector database in a multi-tenant environment can leak information across customer boundaries in ways that look nothing like a conventional data breach.
WHERE GOVERNMENTS ARE DRAWING THE LINE
National cybersecurity agencies have started treating this as a distinct category of risk rather than an extension of ordinary software security. Australia’s Cyber Security Centre has published guidance specifically on AI and machine learning supply chains, warning that the complex ecosystem of models, data, software libraries, and cloud infrastructure behind modern AI systems can expose organizations to poisoned data, hidden backdoors, and malicious code if left unmanaged. The agency’s guidance applies to any organization deploying or developing AI systems, whether that means building models in-house or simply consuming a vendor’s pre-trained model and third-party datasets, and it points organizations toward AI-specific extensions of the software bill of materials, sometimes called an AI BOM, as a way of making the components of a model interrogable rather than treating it as an opaque black box.
The guidance also extends the supply chain conversation to hardware, recommending that organizations treat the infrastructure underlying AI systems the same way they would treat any other integrated technology: enforcing signed drivers and firmware, enabling verified boot, and keeping management networks properly segmented from production systems. It’s a reminder that AI supply chain security doesn’t stop at the model or the data. It runs all the way down to the silicon.
BUILDING A TOKEN GOVERNANCE PROGRAM
The organizations managing this well tend to converge on a similar set of practices, regardless of whether they arrived there through a security review or a cost audit. The starting point is visibility: a current inventory of every OAuth token, API key, and service credential in circulation, including which integrations they belong to and whether those integrations are still in active use. Dormant connections should be revoked on a regular schedule rather than left to accumulate indefinitely, and token lifespans should be kept short by default, with rotation built into the design of a system rather than treated as an emergency response after a breach.
Storage discipline matters just as much as lifecycle management. Tokens should be encrypted, kept out of source code and logs, and subject to the same secret-management standards an organization would apply to its most sensitive credentials, because a token sitting in plaintext is only as secure as the weakest system that can read it. Runtime monitoring closes the loop, since centralized logging and anomaly detection are what turn a compromised token into a contained incident rather than a months-long undetected breach.
On the model and data side, the same discipline needs to extend upstream. Provenance documentation for training data and pre-trained model checkpoints, cryptographic signing of model artifacts, and vendor assessments that ask hosting providers to demonstrate their own security posture are no longer optional extras for organizations operating at scale. They are the difference between knowing what is actually inside a model and simply trusting that it behaves as advertised.
THE OUTLOOK
Token-based competition, in the cost sense, rewards organizations that treat consumption as a resource to be measured and directed. Token security, in the credential sense, rewards organizations that treat trust the same way: as something with an inventory, a lifecycle, and an owner. The two problems will only keep converging as AI systems connect to more tools, more data sources, and more of each other, and the enterprises that manage both sides of that ledger, the spend and the trust, will be the ones that can scale AI without quietly expanding their attack surface at the same time.
References
Batchelor, B., Rafian, E., and Quist, N. “Trusted Connections, Hidden Risks: Token Management in the Third-Party Supply Chain.” Unit 42, Palo Alto Networks, September 12, 2025. https://unit42.paloaltonetworks.com/third-party-supply-chain-token-management/
“Establish Risks and Controls for the AI Supply Chain, V 1.0.” Coalition for Secure AI (CoSAI), Workstream 1: Software Supply Chain Security for AI Systems, June 12, 2025. https://github.com/cosai-oasis/ws1-supply-chain/blob/main/risks-and-controls-for-the-ai-supply-chain-v1.md
“Artificial Intelligence and Machine Learning: Supply Chain Risks and Mitigations.” Australian Signals Directorate, Cyber.gov.au. https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/artificial-intelligence-and-machine-learning-supply-chain-risks-and-mitigations
