For decades, hardcoded keys lay dormant in private archives, often unnoticed by anyone outside a tight-knit circle of developers. This dynamic was permanently changed by the expansion of AI agents. In what way?
For quite some time, the topic of artificial intelligence security has remained at the top of business news portals, and high-profile data breach scandals painfully illustrate the true scale of the threat. Coding shortcuts that “went unnoticed” for years in seemingly closed archives are becoming a ticking time bomb today. The moment AI assistants and autonomous agents gain visibility into corporate code, past oversights can instantly paralyze an entire enterprise operationally and generate massive financial losses. What can be done to protect against such severe consequences?
The illusion of security
There is a widespread belief that security incidents only affect organizations that have always cut corners on security, showed no interest in the subject, and disregarded the threat. Market experience shows a completely different picture - vulnerabilities stemming from poorly secured software repositories affect entities with an established market position and large teams.
Not long ago, we heard about incidents involving entities such as MyDoctor (MyDr) and the Fakturownia platform. In both cases, attackers managed to breach the organization’s defense perimeter by accessing repositories on GitHub. The affected parties may only feel the consequences of the data leaks over time, and the losses are difficult to estimate.
However, the consequences can also have an immediate, purely financial dimension. Leaking API keys (for example, to artificial intelligence models such as OpenAI or Gemini) allows unauthorized parties to generate massive infrastructure usage at the victim’s expense. There are documented cases in the market where a hacker, unstopped in time, managed to generate a bill reaching 100,000 dollars in just one to two days using intercepted credentials.
Why has the problem emerged now?
Connecting AI tools (e.g., GitHub Copilot) to corporate repositories de facto means that code ceases to be fully isolated and truly private. If developers use non-corporate accounts or unverified tools, sensitive data can be ingested by machine learning algorithms.
More and more often, teams allow autonomous AI agents operating in so-called YOLO mode (without ongoing human authorization for every step) into their workflows. By giving the model unrestricted access to repositories and databases, the company hands over the steering wheel to a tool that possesses no awareness of legal or business risks.
The number of incidents is also rising where malicious instructions embedded in prompts or external extensions instruct an agent to search the repository accessible to it, extract access keys, and send them to external servers.
What does this look like in practice?
We will describe this using the example of a company from the beverage industry. A platform developed over 15–20 years, whose architecture grew into several dozen (from 30 to 50) independent code repositories in a microservices architecture.
For years, the project lacked unified control procedures. Over more than a decade, dozens of developers created their own Amazon Web Services (AWS) cloud access accounts and hardcoded login credentials into configuration files. More than 30 individual access profiles with administrative privileges were identified within the system.
However, the most serious architectural error turned out to be placing the testing environment (staging) and the production environment within the same cloud account. The leak of any key from the more casually treated testing environment automatically granted access to the customer database and the entire production infrastructure.
When an automated scanning tool uncovered how many keys had actually been left in the code, the reaction was… an immediate decision-making crisis. In this company, a complete freeze on deploying changes was implemented, and the entire development team was delegated to putting out fires.
The specifics of version control tools (Git) proved crucial: removing a key from the current file does not delete it from the project history. Every commit from 5 or 10 years ago still contained confidential passwords. Neutralizing the threat required a deep history purge, rotating dozens of credentials, and redeploying all applications, which paralyzed development work for two full weeks.
The problem does not only concern the IT department
A data breach is a direct hit to a company’s balance sheet, and its most painful cost is rarely just the IT infrastructure expenses. In the digital economy, trust remains the primary currency, and news of compromised systems spreads across the market in an instant. Rebuilding a damaged reputation takes years, while customers (fearing for their own security) unhesitatingly defect to competitors. Worse still, the uncontrolled exposure of authorization keys is not confined within the organization. It often becomes a skeleton key to the sensitive data of business partners and end users.
If criminals use the intercepted credentials to take over accounts, steal identities, or commit financial fraud, the company becomes directly co-responsible for tangible, real-world losses suffered by its customers.
Another important aspect is failure to comply with legal obligations. The implementation of the EU’s new NIS 2 Directive and the rigorous enforcement of GDPR make matters clear: a lack of procedures for managing keys and vulnerabilities is a direct breach of the duty to maintain “due diligence”. Any potential breach means financial penalties running into millions of euros or percentages of global turnover.
It is also worth mentioning the lack of compliance with standards (e.g., ISO 27001). The presence of plaintext credentials in code archives invalidates information security declarations and threatens the loss of certification, which often excludes an organization from corporate tenders.
Intellectual property itself is also at stake. Proprietary source code, system architecture, and unique algorithms represent capital built over years that determines market advantage. Allowing their unauthorized seizure or leakage destroys multimillion-dollar investments in technological development and can strip an enterprise of its fundamental market value overnight.
Better to prevent than to cure
If you have doubts about whether legacy vulnerabilities are lurking in your repositories, or if you need an outside, fresh perspective on your code - an independent security audit is a proven solution.
The alternative is waiting to see how events unfold with the hope that “everything will somehow work out”. In the event of an incident, however, the bill for an investigative team, legal counsel, and reputational damage will be many times higher than the cost of any prior verification. Prevention simply pays off much better than dealing with the aftermath of a crisis.
