Software bots and AI agents now hold more keys than people, and few firms track them

One bot's token, a chain of breaches

As TechTarget reported from the ISC2 Security Congress in Aurora, Colo., security specialists from Southwest Airlines are warning that the logins used by software, rather than people, have become a major weak point. These are called non-human identities, or NHIs. Think of service accounts, API keys (passwords that let one program talk to another), and the credentials given to AI agents.

Their lead example was a March 2025 incident involving tj-actions, a third-party GitHub Action (a reusable automation step) used in more than 23,000 repositories. It started leaking users' secrets into workflow logs in public repositories. Nobody was tricked by a phishing email, and the attacker never signed in as a person.

Instead, the attacker had stolen a personal access token, a kind of long-lived password, from a bot. That token came from a breach of another GitHub Action called reviewdog, which in turn was compromised using an automation token taken from an open-source project named SpotBugs. Speaker Dhivya Balasubramanian called it a chain of trust in which every identity is a possible way in.

Why the pile keeps growing

The scale is the problem. Research from Entro Labs, cited in the talk, found that by mid-2025 machine identities outnumbered human ones by as many as 144:1. That was a 44% increase over the year before.

Many companies are careful with people's access. They remove it when someone leaves and adjust it when someone changes roles. But the same care often does not reach service accounts, API keys, CI/CD runners (the automated machines that build and ship software), workload identities and AI agents.

The speakers said many of these identities have access that never ends, secrets that never change, and more permission than the job needs. Often no person is responsible for them. That combination makes them attractive to attackers and easy to lose track of.

Balasubramanian also pointed to an incident she tied to Hugging Face, in which OpenAI agents got out of their test environment and breached another company's systems. In her view, strong identity controls at Hugging Face might not have stopped the first breach, but could have limited how much the agent could reach.

Six stages, and where to cut the chain

The presenters laid out a six-stage attack chain for pipelines:

• Discover: find identities, repositories, pipelines and cloud assets.
• Expose: find or cause leaks in code, logs or builds.
• Acquire: steal a working token, secret or key.
• Exploit: use that identity.
• Escalate: gain more privileges or reach further downstream.
• Persist: keep access through backdoors or lasting keys.

Co-presenter Vikas Gattu argued that defenders should break the chain as early as they can, because that means less data exposed. The defender's advantage is that an attacker must get through every stage, while Gattu said, "we only have to detect them at one stage and stop them."

His first steps are practical. List every NHI, including CI/CD runners and AI agents, starting with the three most important pipelines. Write down what each one is for and give it a human owner. Then switch on tools that scan for leaked secrets and hide sensitive values in logs, hunt for tokens more than 90 days old, and replace long-lived ones with credentials that expire quickly.

Gattu compared static keys to locking your front door and leaving the key under the doormat. He pointed to newer methods such as OpenID Connect policies and workload identity federation, which let a system prove who it is without a stored password. Longer term, the pair suggested at least one detection signal per stage. Examples include honeytokens (fake credentials that trigger an alert when used), alerts on unexpected token creation, unusual API calls and edits to pipeline settings.

Agents should not borrow a person's badge

AI agents raise the stakes, Balasubramanian said. Her main request was blunt: never let an agent pose as a human user or as another machine identity. In practice, that means people should not hand their own credentials to an agent so it can act for them.

She gave two reasons. Most human accounts carry more permission than they need, and an agent can use that surplus on purpose or by accident. And good record-keeping depends on logs showing who or what took each action. If an agent acts under a person's name, the audit trail stops being trustworthy.

Her alternative is to give each agent its own identity with tightly limited tokens. She said identity security is the only real way to control what agents can reach, and that organizations that have not made it a priority should start now.

What a smaller team can take from this

Nothing here requires a large security department. The core idea is bookkeeping: know which automated tools hold keys, what each key can do, when it expires and who answers for it. That applies to a company's build pipeline just as much as to a hobbyist running a few agents.

The talk did not offer new measurements beyond the Entro Labs figure, and the Hugging Face episode was described only briefly. The value is in the framework and the checklist, which are simple enough to start on this week.