AI Agents Now Outnumber Your Employees — and Nobody Owns Them

Count the people who log into your systems each morning. Now count the automated accounts, API keys, service principals and AI agents doing the same thing quietly in the background. In most UK SMEs, the second number is larger — often several times larger — and almost nobody can tell you who is responsible for any of it.

These are non-human identities, or NHIs: the machine accounts, tokens and credentials that let software talk to other software without a person in the loop. They've always existed. What's changed is the pace. Enterprise AI agents grew roughly 460% year-over-year, and every one of them needs credentials to read your files, send your emails, or query your databases. The trouble is that they arrive faster than any governance process can keep up with, and they tend to be created by whoever needed them that afternoon — then forgotten.

Why this is a security problem, not a housekeeping one

When the Accenture breach surfaced, the interesting detail wasn't that attackers got in. It was how they moved once inside: stolen Azure tokens and service-account keys. Those credentials don't trigger the alarms a suspicious human login does. A service account doesn't fail a multi-factor prompt. It doesn't log in from an unusual location and get flagged. It just keeps working, because that's precisely what it was built to do — silently, at all hours, with whatever permissions someone granted it months ago and never revisited.

That's the core risk. A human account has a name, a manager, a leaving date and an HR record. When Sarah in accounts resigns, someone disables her login. But the invoice-processing bot Sarah set up in 2022? It's still running, still holding an API key with write access to your finance system, and nobody remembers it exists. Multiply that by every integration, every automation, every 'quick' AI pilot someone spun up, and you have a sprawling attack surface that no one owns.

The numbers behind this are stark. Industry estimates put the ratio of machine identities to human ones at anywhere from 10:1 to 50:1 in cloud-heavy environments. For an SME with 40 staff, that could mean hundreds of credentials floating around — most created with generous permissions 'to save time', most never rotated, and a worrying share stored in plain text in a script, a config file, or a shared spreadsheet somewhere.

Three habits that make NHIs dangerous

Before the audit itself, it's worth naming the patterns that turn machine identities from useful into hazardous.

Over-provisioning. When someone sets up an integration, granting broad admin rights is faster than working out the minimum needed. So the reporting tool that only needs to read data ends up able to delete it. If that credential leaks, the attacker inherits every one of those permissions.

Never rotating. Human passwords get changed. Service-account keys often live for years. The longer a credential exists, the more places it's been copied to, the more people have seen it, and the more likely it's sitting in an old repository or a departed contractor's laptop.

No owner. This is the one that ties everything together. If no named person is accountable for a credential, no one reviews it, no one notices when it should be retired, and no one can answer the simple question during an incident: what is this account allowed to do, and can we safely kill it?

The audit you can run this quarter

You don't need a new platform to make real progress. You need a disciplined sweep and someone to own the output. Here's a practical sequence.

1. Discover what exists

Start by pulling an inventory from the systems where NHIs actually live. For most SMEs that means:

• Microsoft Entra ID (Azure AD): list all service principals, app registrations, and managed identities. Note the client secrets and certificates attached to each, and when they expire.
• Microsoft 365: enterprise applications with delegated or application permissions — especially anything with Mail.Read, Files.ReadWrite.All, or directory access.
• Cloud platforms: IAM roles and access keys in AWS, service accounts in Google Cloud.
• SaaS tools: API keys and OAuth grants in your CRM, accounting software, and helpdesk.
• On-premises and scripts: scheduled tasks, PowerShell scripts, and anything running under a shared service account.

Don't forget the AI layer. Every Copilot connector, chatbot integration, or agent you've trialled has an identity behind it. If a supplier demo left credentials active, they count.

2. Assign an owner to every single one

This is the step most organisations skip, and it's the most valuable. Take your list and put a human name next to each entry — not a team, a person. If nobody can be identified as the owner, that credential is a candidate for immediate disabling. In practice, this exercise alone surfaces the ghost accounts: the ones tied to a project that ended, a person who left, or a vendor you no longer use.

A simple spreadsheet works: identity name, system, what it does, business owner, permissions held, secret expiry date, last used. The 'last used' column is gold — anything that hasn't authenticated in 90 days deserves scrutiny.

3. Right-size the permissions

For everything with an owner, ask a blunt question: does this account need everything it's got? Read-only where read-only will do. Scoped to specific mailboxes or folders rather than the whole tenant. Remove standing admin rights that were granted 'just in case'. This is tedious, but it directly shrinks what an attacker gains from a single stolen key.

4. Rotate and centralise the secrets

Any credential that's more than a year old should be rotated. Any secret sitting in a script or config file should be moved into a proper secrets store — Azure Key Vault, AWS Secrets Manager, or a dedicated vault — so it's encrypted, access-logged, and rotatable without hunting through code. If you find keys in a shared document or a Teams message, treat them as compromised and replace them.

5. Set a review rhythm

An audit is a snapshot. NHIs keep multiplying, so bake in a quarterly review: new identities get an owner at creation, unused ones get disabled, and secrets rotate on a schedule. Make it someone's named responsibility. A control nobody owns is a control that decays.

Getting ahead of the AI wave

The reason to do this now, rather than next year, is that AI adoption is about to make the problem far worse. Every department wants an agent. Each one needs access. If you establish the discipline — owner, least privilege, rotation, review — before the flood, you turn AI rollout into a managed process rather than a scramble. If you don't, you're adding hundreds more ungoverned credentials on top of the ones you already can't account for.

None of this requires a big budget. It requires a list, a set of names against it, and the will to disable what shouldn't be there. Attackers have already worked out that machine identities are the soft way in. The good news is that finding and owning them is entirely within reach for an SME — and doing it this quarter is a lot cheaper than explaining a breach later.

If you'd like a hand running the discovery across your Microsoft 365 and Azure environment, that's the kind of practical sweep we do with clients regularly. It usually takes less time than people expect, and the ghost accounts it turns up are always eye-opening.