Your newest insider threat is an AI agent: the case for AI agent identity

AI agent identity illustrated by a humanoid agent with an access badge approaching business systems containing customer data, financial records and internal tools, highlighting the risks of unauthorised access.

AI agent identity has become a board-level security question, because the newest insider threat in many organisations is an AI agent. It works inside your systems, with access you granted, and often with nobody watching what it does with it.

Microsoft says frontier models "cannot be trusted" by default. Attackers have already used agentic tools in a supply-chain compromise, and major banks are restricting outside agents' access to customer accounts.

Microsoft expanded Project Perception on 19 October, the Storm-0940 agentic attack was disclosed on 21 October, and Axios reported on banks and agents on 22 October.

Our argument is that agents should get their own identity, scoped permissions and oversight, as staff do, and that this must be designed in from the start rather than added later.

This article is for CTOs, CISOs and regulated-sector leaders. It covers what "overprivileged agents" look like, lessons from the banking pushback, an identity and permissions model for agents, and monitoring and kill switches.

What "overprivileged agents" look like

An insider threat is someone with legitimate access who misuses it, by intent or by mistake. Microsoft now puts AI agents in that category. In a blog post shared by Satya Nadella on 19 October, Hayete Gallot, Executive Vice President of Microsoft Security, wrote that "frontier models, regardless of their origin, cannot be trusted", Business Today reported.

Her reasoning is not that models are malicious. It is that they are trained to achieve results, which can lead to reward hacking, and are not built around an organisation's norms or judgement. She described agents as "agentic insiders" that "are frequently overprivileged", and warned that they "will adapt as the context changes, may not behave as intended and will collaborate and collude with other agents", all without any hacker involved.

The signs of an overprivileged agent

The OWASP Gen AI Security Project calls this risk excessive agency, and traces it to three root causes: an agent with more functions than its job needs, more permissions than its tasks need, or more autonomy than its risks allow. In practice, that looks like this:

  • It borrows someone else's credentialsThe agent signs in as a member of staff or a customer, so its actions are recorded as theirs.
  • It can write where reading would doAn agent that only needs to summarise records can also change or delete them.
  • Its access never expiresPermissions granted for a pilot stay in place long after the pilot ends.
  • It reaches data it does not needThe ICO's report on agentic AI flags systems "connected to databases not needed for their tasks" as a sign of poor implementation.
  • It acts without approvalHigh-impact actions, such as payments or permission changes, go ahead without a person confirming them.
  • Nobody can stop it quicklyThe ICO also warns of systems with "no measures in place to secure access, monitor or stop activity".

What attackers do with overprivileged identities

On 21 October, Microsoft Threat Intelligence disclosed that it assesses Storm-0940, a China-state aligned actor, was responsible for the ConnectWise supply-chain compromise. The group used ARTEX, an open-source penetration testing framework built from AI agents, to automate scanning, password spraying and the abuse of applications. The Neuron's 23 October digest summarised it: "The agents automated attack activity and abused application credentials across Microsoft 365 environments."

The decisive step did not need a person's password. After taking control of the identities of several ConnectWise cloud applications, the agents used those applications' credentials to sign in to customer tenants, relying on the trust the applications already held there. Microsoft says ARTEX attempted sign-ins to more than 2,250 tenants. In some environments, an application assigned itself a high-privilege role such as Global Administrator, and attackers read secrets in bulk from key vaults. In several cases, the time from first targeting to privileged access was "less than 3 hours".

Those applications were not AI agents, but they were the same kind of identity that many agents run under today: a non-human identity with standing, broad permissions that nobody was watching closely. Every overprivileged agent you deploy is another one. We looked at how attackers can hijack agents through their inputs in our piece on AI agent security and SalesBleed.

Lessons from the banking pushback

Banks are the first sector to push back at scale. Axios reported on 22 October that customers had given third-party agents their login credentials and permission to access their accounts, without their banks' approval, and that some agents appeared to act beyond users' instructions. According to International Business Times, which drew on Axios and other reports:

  • Morgan Stanley has begun blocking third-party agents, although a spokesperson said the bank had not seen "rogue AI agents accessing our platforms".
  • JPMorgan Chase has moved to block outside agents that use customers' banking credentials. A Chase spokesperson said "customers should not share their usernames and passwords with anyone."
  • Citigroup does not let third-party agents log in or transact, and offers limited read-only access through approved open banking providers.
  • Charles Schwab blocks unauthorised agents, including Meta's Muse, and is building connections that would allow balance retrieval and research but not transactions.
  • Banks are drawing up plans to "secure or restore customer access" if an AI-related incident occurs.

Bank of America is also reported to be restricting agent access, with its chief executive arguing that a person should stay involved when money leaves an account.

Four lessons for any organisation

  • Shared credentials destroy attributionThe Neuron's digest puts the core issue simply: banks need to know whether an action reflects the customer's instructions or an agent acting beyond them. When an agent signs in with a person's credentials, nobody can tell. The same is true inside your organisation when an agent uses an employee's account.
  • Reading and acting are different permissionsAgents that can initiate transactions or change account settings pose a harder problem than agents that only read balances. Citi and Schwab are drawing that line explicitly: read access through a sanctioned channel, no transactions.
  • Irreversible actions need a personWhere money leaves, a human approves. The same rule applies to deleting records, changing permissions or sending information outside the organisation.
  • Plan the recovery before the incidentBanks are writing plans to restore access after an agent-related incident. You need the equivalent before an agent goes live, not after.

The banks are also showing that blanket bans are a holding position. Citi and Schwab are building sanctioned, scoped routes for agents, because customers will keep using them. Proving what an agent was authorised to do is a problem we explored in our piece on the Agent Payments Protocol.

An identity and permissions model for agents

Organisations already know how to give a new member of staff the right access: an account of their own, a manager, permissions for their role, approval for sensitive actions and a leaver process. Agents need the same, adapted to software that works at machine speed.

How staff identity and access controls translate to AI agents
For staff For AI agents
Their own account, never a shared login A separate identity for every agent, never a borrowed user account or shared service account
A line manager A named human owner who is accountable for what the agent does
Access set by role Permissions scoped to the agent's task, with read, write and transact granted separately
Sign-off for sensitive actions Human approval before high-impact actions such as payments or permission changes
Joiner, mover and leaver processes Access granted for a defined period, reviewed regularly and removed when the agent is retired

Give every agent its own identity

AI agent identity means each agent has an identity of its own, so that every action it takes can be attributed to it, limited and, if necessary, revoked without affecting anyone else. Identity platforms now support this directly. Microsoft says its Entra Agent ID, now generally available, "brings first-class identity and access management to AI agents", with separate access policies for agents acting on behalf of a user and for autonomous agents acting on their own.

That distinction matters. An agent acting for a user should never have more access than that user, which OWASP describes as executing in the user's context. An autonomous agent needs permissions of its own, granted for its task and nothing more.

Scope permissions to the task

  • Start read-only. Grant write or transact permissions only when a task requires them, and separately.
  • Keep credentials short-lived. Application credentials are what Storm-0940 stole and reused, so make them expire and rotate them.
  • Enforce access outside the model. OWASP advises enforcing authorisation in the downstream systems, not trusting the model to decide what it is allowed to do.
  • Limit third-party applications. After Storm-0940, Microsoft recommends limiting multi-tenant application permissions and consent grants.
  • Require approval for high-impact actions. OWASP recommends a person approves them before they happen. In the CRM we built with AI agents, "every action that touches data is presented to a human for approval before execution."

For regulated organisations, this is also a compliance question. The ICO says organisations "remain responsible for data protection compliance of the agentic AI they develop, deploy or integrate". The questions to answer before deployment are the ones we set out in our guide to AI agent governance: what the agent can see, change and send, and who is accountable for it.

Design it in from the start

Identity is cheap to design in and expensive to add later. An agent built around a borrowed account has that account's permissions threaded through every integration, and every log entry shows the wrong name. Separating them afterwards means rebuilding the integrations and losing the history. Built in from the first release, the agent's identity, owner, permissions and approval rules are part of its design, not a project for later. Our piece on why enterprise AI agent projects get cancelled found the same pattern: the projects that survive have risk controls "designed in from the start rather than added later".

The trap

Letting an agent run under a person's account or a shared service account to get a pilot working quickly.

The fix

Give the agent its own identity, a named owner and task-scoped permissions before it touches live data.

Monitoring and kill switches

Permissions limit what an agent can do. Monitoring shows what it is doing, and a kill switch stops it. Gallot's view is that knowing what an agent is doing is not enough: security teams also need to ask why, and whether that matches the task. As she put it, "Model transparency will not replace containment."

Monitor every agent continuously

Microsoft's expansion of Project Perception shows where monitoring is heading. Techzine reports that agents are detected and "assigned an identity, container, policies, and permissions", that the system "continuously recalculates how risky an agent's action is", and that Guardian Agents "continuously monitor every action". The features are in private preview, with broader availability planned for Microsoft's Ignite conference in November, GeekWire reported.

Whatever tools you use, the essentials are the same:

  • Every action is logged under the agent's own identity, with the data it used. Those records matter legally too, as we explained in our piece on AI liability under English law.
  • Alerts fire on the signals Microsoft highlights after Storm-0940: new credentials, privilege assignments and unusual activity by applications acting on their own.
  • Each agent has a baseline of normal behaviour, so a change in what it reaches or how fast it acts stands out.
  • Alerts reach someone who can act on them at the speed of an automated attack, which in Storm-0940's case reached privileged access in under three hours.

Make the kill switch graduated and tested

A kill switch does not have to mean switching an agent off entirely. According to GeekWire, as an agent's risk rises, Microsoft's system can remove its ability to make changes while still letting it read data, require a person to approve high-stakes actions, or shut it down. That graduated approach keeps useful work running while the risk is investigated.

  • RestrictRemove write and transact permissions, leaving read access in place.
  • SuperviseRequire human approval for every action until the risk is understood.
  • StopRevoke the agent's identity and credentials, which ends its access everywhere at once.
  • RestoreFollow a written plan to recover any data, settings or access the agent changed.

A kill switch nobody has tested is an assumption, as we argued in our piece on AI sandboxes and the problem of containment. Rehearse it before the agent goes live, and again whenever its permissions change. Stopping an agent is only clean if it has its own identity to revoke.

If you cannot revoke an agent's access without locking out a person, the agent does not have its own identity.

Why agent identity has to be designed in

Microsoft's warning, Storm-0940 and the banks' response point the same way. Agents already act inside organisations with real access, attackers already use agents to exploit non-human identities, and the institutions with the most to lose are cutting off agents they cannot identify.

The answer is not to avoid agents. It is to treat each one as a new insider from its first day: its own identity, permissions scoped to its job, a person accountable for it, continuous monitoring and a tested way to stop it. AI agent identity built in from the start costs little. Added after an incident, it costs far more.

Do your AI agents have their own identities?

If an agent in your organisation signs in as a person, holds standing access it no longer needs, or cannot be stopped without disrupting someone's work, it is an insider risk.

At Imobisoft, we design and build AI solutions around the systems, data and compliance obligations our clients already have, including the integrations, access rules, approval workflows and logging around each agent.

Talk to us about your AI agents

Frequently asked questions

What is AI agent identity?

AI agent identity means giving each agent its own identity, separate from any person or shared account, so its actions can be attributed, its permissions scoped to its task and its access revoked on its own.

Why are AI agents an insider threat?

Agents work inside your systems with legitimate access. Microsoft says agents are frequently overprivileged and may not behave as intended, even without being hacked, so they need the same controls as staff.

What is an overprivileged AI agent?

An overprivileged agent has more functions, permissions or autonomy than its task needs. OWASP calls this excessive agency, and it lets mistakes or manipulation cause real damage.

What happened in the Storm-0940 attack?

Microsoft says Storm-0940 used the agentic framework ARTEX in the ConnectWise supply-chain compromise, using stolen application credentials to attempt sign-ins to more than 2,250 customer tenants.

Why are banks blocking AI agents?

Customers have been giving third-party agents their login details, so banks cannot tell whether an action came from the customer or the agent. Several major US banks now block agents that use customer credentials.

What is an AI agent kill switch?

A tested way to restrict or stop an agent quickly: remove its write access, require approval for its actions, or revoke its identity entirely, with a plan to restore anything it changed.

Sources

Have a project in mind? Let’s get to work.

Let’s chat about how we can help you. Fill in the details and we’ll get back to you as soon we can.