Your AI Agents Are Using Employee Credentials — Here's the Identity Gap DigiCert Just Quantified

A marketing manager at a mid-sized firm sets up an AI agent to draft emails, pull sales figures and update the CRM overnight. To make it work, she pastes her own login details into the tool. The agent now has everything she has: her mailbox, her CRM access, her shared drives. It runs while she sleeps. Nobody in IT knows it exists.

That scene is playing out in businesses across the country right now, and it points to the security problem that will define 2026. It is not that the AI model might say something embarrassing. It is that thousands of autonomous agents are being handed the keys to your systems using human credentials that were never designed to be shared with software.

The number that should make you stop

On 7 July, DigiCert published research showing that 75% of organisations have already experienced an AI-related security incident. Three in four. That is not a projection about what might happen if things go wrong. It is a measurement of what has already gone wrong.

What makes the figure so striking is how quietly these incidents accumulate. An AI agent with an employee's access does not trip the usual alarms. From the system's point of view, it is the employee. When it reads a file it should not, forwards data it should not, or connects to a service it should not, the logs show the member of staff doing it. There is no separate identity to flag, question or shut off.

That is the gap DigiCert has put a date and a number against. And it is a gap of governance, not of technology sophistication.

Why agents broke the old model

For twenty years, identity management assumed one simple thing: behind every login is a person. You issue a person a username, you tie it to a job role, you scope what they can touch, and when they leave you switch it off. Multi-factor authentication, single sign-on, joiner-mover-leaver processes — all of it rests on the person-behind-the-login assumption.

AI agents shatter that assumption in three ways.

They authenticate as someone else. Most agents today borrow a human's credentials or an over-broad API key. There is no distinct identity for the agent itself. So the question "who is this?" has no honest answer.

Their access is rarely scoped. A person is trusted to use judgement — you can hand them broad access and rely on common sense. An agent has no judgement. It does exactly what it is told, at machine speed, thousands of times. Giving it a human's full access set is like giving a photocopier the authority to sign cheques.

They are almost impossible to revoke cleanly. When a member of staff misbehaves, you disable their account. When an agent misbehaves — starts leaking data, gets manipulated by a malicious prompt, or simply loops through an expensive mistake — how do you stop it? If it runs on someone's credentials, killing it means locking out that person too. Often IT does not even know which agent belongs to which login.

This is what people in the industry mean when they talk about the control plane. It is the layer that decides who gets to do what. For human users, that layer is mature. For agents, in most SMEs, it does not exist yet.

The real risk in 2026 is not model safety

There has been a lot of noise about whether AI models are safe — whether they hallucinate, whether they are biased, whether they can be jailbroken into saying something offensive. Those are genuine concerns for the companies building the models. For the companies using them, they are mostly a distraction.

Your exposure does not come from what the model says. It comes from what the agent can do. A perfectly well-behaved model, wrapped in an agent that holds a director's credentials and can reach the finance system, is a far bigger risk than a badly-behaved model that can only read a public web page.

Think about the practical scenarios:

• An agent processing supplier invoices is fed a poisoned document that instructs it to change bank details. It has payment access. It obeys.
• An agent summarising customer tickets is connected to your whole helpdesk and quietly forwards records to an external tool because someone configured it carelessly.
• A member of staff leaves. Their account is disabled. But the agent they built runs on a service account nobody remembered to link to them. It keeps running for months.

None of these require the AI to be evil or broken. They only require it to have access it should not have, and no clean way to take that access away.

What good agent identity looks like

The fix is not exotic. It applies the discipline we already use for people to the software now acting on their behalf.

Give every agent its own identity. No shared credentials, no borrowed logins. Each agent gets its own machine identity, so that every action it takes is attributable to it and not to a confused human record. This is where certificate-based and workload identity approaches — the kind of infrastructure DigiCert and others build — come into their own. You cannot govern what you cannot name.

Scope access to the task, not the person. An agent that drafts emails does not need access to payroll. Apply least privilege ruthlessly. Give the agent the narrowest set of permissions that lets it do its job, and nothing more. If it needs more later, that is a decision someone makes on purpose.

Make revocation fast and specific. You should be able to switch off a single agent in seconds, without affecting the person who created it or any other agent. That means short-lived credentials that expire by default, and a register of which agents exist and what they can reach.

Keep an inventory. You cannot protect what you do not know about. The first honest step for most businesses is simply finding out how many agents are already running, who set them up, and what access they hold. In our experience this exercise alone tends to surprise people.

Why waiting is the wrong call

The tempting response is to sit tight and let the big software vendors solve this. They will, eventually. Microsoft, Google and the identity platforms are all building agent-governance features, and over the next couple of years they will mature.

But DigiCert's data is about incidents that have already happened. The 75% is a present-tense figure. Every month you deploy agents without governing their identity, you add to the pile of access that nobody is tracking. When the tooling does arrive, you will still have to go back and untangle the mess you built in the meantime — and untangling is always harder than doing it right the first time.

The good news is that the work is proportionate. For a typical UK SME, getting a grip on agent identity is a matter of weeks, not a transformation programme. It starts with visibility, moves to naming and scoping, and ends with a clear process for retiring agents when they are no longer needed or start behaving badly.

Where to start this month

If you do three things, do these:

1. Find your agents. Ask around every department. Anyone using an AI tool that touches a company system counts. Write them down.
2. Check what credentials they run on. Any agent using a person's login or a broad, long-lived key is a priority to fix.
3. Decide who owns agent identity. Someone needs to be responsible for approving, scoping and revoking agents — the same way someone owns the joiner-mover-leaver process for staff.

AI agents are useful, and the businesses that use them well will pull ahead. But usefulness and governance are not in tension. The firms that get this right will be the ones that treated their agents like the powerful, credential-holding actors they are — before an incident forced the lesson on them.

If you would like help mapping the AI agents already running in your business, and building the identity controls to govern them, that is exactly the kind of work we do at Cloudworks. Better to have the conversation now than after your name shows up in the 75%.