Non-Human Identity Overtakes Phishing as the Way In

Ask a security team how an attacker gets in and the answer arrives quickly: somebody clicks something. That answer has been correct for so long that most identity programmes are built around it, from the awareness training to the phishing simulations to the conditional access rules. New research across 750 security leaders puts compromised non-human identity ahead of phishing and social engineering as the primary entry point into the enterprise, at 31% against 17%. The credential that let the attacker in increasingly belongs to something that cannot be trained, cannot be phished, and has never once been asked to prove it is not a robot.

31% Of intrusions where a compromised non-human identity was the primary entry point

17% Of intrusions where phishing or social engineering was the primary entry point

36% Of organisations actually monitoring machine and AI identity exposure

95% Of organisations that believe they already have that visibility

Why Non-Human Identity Overtook the Inbox

Service accounts, API keys, authentication tokens, CI runners, integration users and now AI agents all carry credentials. They have always carried credentials. What changed is the ratio and the rate.

Every new SaaS integration mints a token. Every pipeline needs a runner identity. Every AI agent that reads a ticket queue or writes to a database needs its own way in, and it needs standing access rather than the seven hour working day a human uses. The population of credentials in a mid-sized enterprise has been growing for years in a direction nobody staffed for, and attackers follow population growth the way water follows a slope.

The research also found non-human identity misuse to be the most commonly reported identity event type overall, at 42%, in a year where 68% of organisations reported an identity-based event at all. That is the shape of a category that has stopped being an edge case.

Security alert from Brandefense about suspicious email activity. — Brandefense warns users about service accounts not reporting suspicious emails for enhanced security.

Every Control in Your Identity Programme Has a Human Shaped Hook

The reason this category is under-defended is not neglect. It is that the controls a mature identity programme relies on were each designed around something only a person does.

• Joiner, mover and leaver processes depend on an employment lifecycle, and a service account created for a migration in 2023 has no leaving date and no manager to sign it off.

• Multifactor authentication depends on a second channel belonging to a person, and an API key cannot be challenged for a code without breaking the automation it exists to run.

• Behavioural baselines depend on habits, and a machine identity that queries at three in the morning from a data centre address is not anomalous, it is working.

• Credential rotation depends on someone being inconvenienced and complying anyway, and rotating a key that six undocumented systems depend on is a change request nobody wants to own.

• Access reviews depend on an owner who can be asked whether access is still needed, and the most dangerous non-human identity is precisely the one whose owner left the company.

Remove the human from the identity and each of those controls does not fail loudly. It simply has nothing to attach to, and the account drops quietly out of the programme while remaining fully valid.

A stolen key does not look stolen

When an employee’s credentials are used by somebody else, there is usually friction somewhere: an unfamiliar device, an impossible travel alert, a second factor prompt arriving on a phone in another timezone. The system has an expectation, and the attacker deviates from it.

A machine identity carries no such expectation. It authenticates from infrastructure, at machine speed, at all hours, performing exactly the kind of bulk access that would be flagged instantly on a human account. An attacker holding that key produces telemetry indistinguishable from the automation it was issued for. There is no anomaly to detect, because the identity had no normal pattern that excluded the attacker.

The Belief Gap Is the Actual Finding

The single most uncomfortable pair of numbers in the research is not about attackers at all. 95% of organisations believe they have visibility into their AI and machine identity exposure. 36% are actually monitoring it.

That gap does not describe a control failure. It describes a reporting failure, which is worse, because a known gap gets budget and an unknown gap gets a green square on a board slide. Sixty points of difference between perceived and actual coverage means most of the organisations in that sample are making decisions about where to invest using a picture of themselves that is not true.

It is worth asking your own team the two questions separately and comparing the answers. Where is the inventory of non-human identity in this organisation, and what monitors those credentials for exposure outside our perimeter? In most places the first question has an answer and the second does not.

AI Agents Are Not a New Category, They Are a Multiplier

91% of the organisations surveyed use AI tools or agents with access to internal systems, applications or data. Only 56% have formal governance and ownership for the privileges those tools receive, and 41% rely on informal processes or partial ownership.

An agent is a non-human identity with two properties that make it worse than a service account. It is granted broad access on purpose, because narrow access makes it useless. And its permissions are usually chosen during an experiment by the team that wanted the capability, not during a review by the team that owns risk.

The failure mode here is not the model doing something unexpected. It is the ordinary one: a credential provisioned quickly, scoped generously, documented nowhere, and still valid eighteen months after the pilot it was created for was abandoned.

Where the Keys Actually Leak

Non-human identity exposure rarely begins with an attack on the identity system. It begins in the ordinary places credentials end up when the thing holding them is not a person who knows to be careful.

• Source repositories and their history, where a key removed in a later commit remains readable in an earlier one.

• Build and deployment logs, where a variable printed for debugging becomes a permanent record in a system with broader read access than the secret store it came from.

• Environment variables on developer and build machines, which is exactly what information stealing malware is written to collect.

• Vendor and partner systems, with exposed API keys or application access involving third parties reported in 22% of cases, because your key is only as private as the least careful organisation holding it.

• Paste sites, forums and marketplaces, where a working key is worth more than a password because it arrives pre-authorised and nobody is going to reset it on a schedule.

What to Do About It

The work splits into two halves that are usually owned by different teams, which is part of why neither half gets finished.

Inside the perimeter

• Build the inventory by issuer rather than by team, enumerating from the identity provider, the cloud platforms, the CI system and the SaaS admin consoles, because asking teams what they created returns the credentials people remember.

• Give every non-human identity a named human owner and an expiry date at creation, and make the absence of both a blocking condition rather than a finding.

• Scope agent credentials to the specific task rather than the role, and re-scope at the end of any pilot instead of at the start of the next incident.

• Treat egress controls as a compensating control for the identities you cannot rotate, since limiting where a credential can reach is often faster than establishing what would break if you changed it.

Outside the perimeter

• Monitor for your own keys and tokens appearing in public repositories, paste sites, stealer logs and criminal marketplaces, because that is where the exposure becomes visible first and where 36% monitoring means most organisations are not looking.

• Extend the same watch to the vendors and partners holding your credentials, since a key exposed through their estate authenticates against yours exactly as well.

How Brandefense Addresses Non-Human Identity Exposure

An internal inventory tells you what exists. It cannot tell you what has already escaped. That second question is answered outside your perimeter.

Capability	How It Addresses Non-Human Identity Exposure
Token and API key exposure monitoring	Watches public repositories, paste sites and forums for the keys and tokens issued in your name, including ones committed and later removed.
Infostealer log monitoring	Surfaces environment variables and stored secrets harvested from developer and build machines, which is how a working key reaches a marketplace without any system being breached.
AI and machine infrastructure discovery	Finds the orchestration servers, agent endpoints and integration hosts that were stood up outside the asset inventory and are issuing credentials nobody is tracking.
Vendor and partner credential exposure	Follows exposure of your credentials through third-party estates, where an exposed integration key is indistinguishable from one leaked by your own team.
Dark web marketplace surveillance	Tracks the sale of access and credentials that arrive pre-authorised, which is the form a compromised machine identity takes once it reaches the market.