Machine Identities Are Growing Faster Than Annual Security Assessments Can Count Them

Most security assessments count people and skip machine identities: the service accounts, API keys, tokens and AI agents that log in to your systems without a person at the keyboard. An annual review asks who has access. It should also ask what has access, what each credential can do, and who owns it. Until it does, the assessment covers only part of your identity surface.

A human account changes a few times a year. Machine identities appear and disappear every time someone ships a pipeline, connects a tool or tries out an AI agent. That speed is the whole problem, and it is why the yearly checklist misses it.

What machine identities are and why they pile up

The OWASP Non-Human Identities Top 10, published in 2025, describes them as credentials software uses to act on its own, "such as service accounts and access keys." In a typical small business that list includes:

• Service accounts that run backups, sync files or send reports.
• API keys pasted into a website, a payment tool or a marketing platform.
• OAuth grants that let one app read another app's data.
• Deploy keys and runner tokens in a build pipeline.
• AI agents given a login so they can read email, files or tickets.

Each one was created for a good reason by someone who needed a job done. Few of them have a named owner after that person moves on. They do not quit, change roles or get flagged by HR, so the controls built around people never touch them. Machine identities simply accumulate.

The risks OWASP ranks for machine identities

OWASP's list puts improper offboarding first: "the inadequate deactivation or removal of non-human identities (NHIs) such as service accounts and access keys when they are no longer needed." The rest of the list reads like a description of what an annual audit misses:

• Overprivileged credentials. Developers or administrators "may assign NHIs with significantly more privileges than required for their function."
• Long-lived secrets. Keys and tokens "with expiration dates that are too far in the future or that don't expire at all."
• Secret leakage. Keys copied "to unsanctioned data stores throughout the software development lifecycle," such as a config file or a chat thread.

None of these needs a clever attacker. A forgotten key with broad rights is enough.

Why annual assessments miss machine identities

The yearly assessment was designed for a world where the set of things that could log in changed slowly. It inventories staff accounts, checks password rules, confirms multi-factor sign-in and moves on. That made sense when nearly every login was a person.

Today a build pipeline can create and retire credentials daily. An AI agent can be connected on Tuesday and making authenticated calls to production on Wednesday. A developer can generate a test key, drop it in a file and forget it. By the time the next assessment runs, those machine identities have either vanished or become part of the furniture, and neither state shows up on a checklist built around people.

AI agents add machine identities faster than anything before

Federal standards work is catching up to this. On February 5, 2026, the National Institute of Standards and Technology published a concept paper, "Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization," through its National Cybersecurity Center of Excellence. NIST framed the issue as "understanding the potential risks from giving AI agents access to diverse data sets, tools, and applications" and called for "applying appropriate identification and authorization controls to mitigate these risks." Public comments closed April 2, 2026.

The takeaway for a business owner is simple. If the people who write identity standards are treating AI agents as a new kind of identity, your assessment should too. Every agent you connect is another entry on the list of machine identities, and it often holds broader access than any single employee.

What one stolen key can do

The clearest public example is a 2023 intrusion into a major cloud email service used by US government agencies. The Cyber Safety Review Board, the Department of Homeland Security panel that reviews major incidents, found in its March 2024 report that the attackers held an old signing key that "enabled the threat actor to forge authentication tokens that allowed it to access email systems." The board concluded "this intrusion was preventable and should never have occurred." DHS announced the findings on April 2, 2024, including a recommendation that providers "implement emerging digital identity standards."

That key was a machine credential. It was old, it should have been retired, and nothing alerted anyone that it was still trusted. Your business is far smaller, but the pattern scales down: one long-lived key with wide rights, no owner and no expiry.

How to assess machine identities in practice

A real assessment starts with a full count of human and machine identities, then works through ownership and rights. You can begin this week:

1. Inventory. List every service account, API key, OAuth grant, pipeline token and AI agent login across email, cloud storage, finance, your website and code hosting.
2. Assign an owner. Every credential gets a named person who can say why it exists. No owner means it goes on the removal list.
3. Trim rights. Cut each one to the least access it needs for its job.
4. Set expiry. Rotate keys on a schedule and prefer short-lived tokens over permanent ones.
5. Watch continuously. Log what each identity does, and review new grants as they appear instead of once a year.

LTFI runs this kind of check as part of its assessment layer, on infrastructure isolated for each client, and its AI staff work behind approvals so an agent never holds standing access it does not need. Our security layer explains how credentials are stored and scoped. For a related look at automated revocation, see our note on agents that revoke risky OAuth grants.

The difference between a checkbox audit and a useful one is the question it asks. "Who has access?" covers your staff. "What has access, what can it do, and when did anyone last check?" covers the machine identities that now do much of the work.

Frequently asked questions