Signals · AI security

One user, many instances

Security used to mean worrying about the user. With agentic AI, one person can now run several copies of themselves, in parallel and around the clock. The first job is to see them.

A cloaked traveller with a staff stands on a stone bridge while many glowing golden copies of a figure, each carrying a key-like staff, spread out across mountain paths towards a vast citadel in the mist

“I used to have to just worry about the user. Now I have to worry about multiple instances of a user.”

— Gouresh Kamble, Amon Dîn

For years, identity security had a simple shape. One person, one account, one laptop, one working day. If something looked odd at three in the morning, it probably wasn't them.

That shape is changing quickly. A single member of staff can now have an AI assistant reading their inbox, a coding agent working in their repositories, a browser agent filling in forms, and a few automations connected to the CRM and the shared drive. Each of these acts with that person's identity, their tokens and their permissions. They don't sleep, they work in parallel, and they don't always tell anyone what they did.

Earlier this month we wrote about why AI agents should not be given global admin rights. This post is about the step before that: finding out how many of these “instances” of your people already exist.

Most of them are already there

The surveys this year point the same way. In April the Cloud Security Alliance reported that 82% of the organisations it surveyed had discovered previously unknown AI agents in the past year, and 65% had at least one agent-related incident. Shadow agents most often appeared in internal scripts and automation, AI assistants and plugins, SaaS tools with built-in automation, and workflows built by developers.

Okta's AI Agents at Work 2026 survey found that 90% of executives were confident in their visibility of AI tools, while 52% of employees admitted using AI tools without approval, often through personal accounts. Both surveys are of larger organisations, but the pattern is familiar in SMEs too: people adopt what makes them faster, and they rarely ask first.

That is why the OWASP Top 10 for Agentic Applications lists “identity and privilege abuse” among the main risks. An agent running on a borrowed human identity inherits everything that person can reach, and its mistakes look exactly like theirs in your logs.

Why banning it rarely works

The instinctive response is to block it all. In practice, that usually pushes the activity onto personal accounts and devices, where you have no visibility at all. The people using these tools are often your most productive staff, and they are trying to get work done.

The UK NCSC takes a more practical line. Its interim guidance on agentic AI, published on 20 August, sets out seven safeguards. Among them: give each agent its own identity distinct from human users, limit the credentials it can use, decide where a human must approve, treat agent activity as user activity in your monitoring, and keep the ability to “pull the plug”. None of that requires saying no. It requires knowing what is there.

How we approach it

First, map what is actually happening. Before any policy, we look at what exists: which agents, assistants and automations are running, whose identity and tokens they use, what they can reach in email, files, finance and code, and what, if anything, they log. In most organisations this is the first time anyone has seen the full picture.

Then, nudge rather than ban. With the map in hand, we help people move their agents onto safer footing, one step at a time:

  • Separate identities for agents, so an agent's actions are not indistinguishable from the person who set it up.
  • Scoped, least-privilege access: an agent that drafts replies does not need to delete mail or move money.
  • Short-lived tokens instead of long-lived keys pasted into tools and scripts.
  • Human approval for risky actions such as payments, deletions, external sharing and production changes.
  • Logging you can actually read, so you can answer “what did this agent do, and on whose behalf?”
  • Plain-English acceptable-use guidance that says what is encouraged, what needs approval and what is off limits, and who to ask.

The aim is not fewer agents. It is agents you can see, explain and switch off.

Three questions to start with

  • If we asked every member of staff which AI tools act on their behalf, would we be surprised by the answer?
  • Could we tell an agent's actions apart from a person's in our email, file and finance logs?
  • If one agent misbehaved tonight, do we know how to stop it without locking out the person who owns it?

Sources