An insider threat doesn’t need a motive. It needs access, autonomy and no one watching.

Yes, agentic AI can be an insider threat. The more useful question is what kind. The classic insider threat programme was built around intent: a disgruntled employee, a bribed contractor, a careless admin. An AI agent usually has no grievance. It can still do the same damage, because it holds the same things a human insider holds: credentials, access to sensitive systems, and the authority to act.

Why agents break the old model

Traditional insider-risk tooling assumes a human on the other end, a known identity, observable behavioural patterns, clear accountability and a definable motive. Agents undermine each of these.

An agent inherits the permissions of whoever deployed it, often a developer or analyst with broad access. It acts at machine speed, without the hesitation that makes a human pause before moving ten thousand records. It also authenticates correctly. The login is valid, the token is legitimate and the API call is authorised. The identity is trusted, but the decision may not be.

Scale makes it worse. Industry surveys put machine identities at many times the number of human ones, and a 2025 CyberArk report cited the ratio at 82 to 1. A Cloud Security Alliance finding from April 2026 suggests most enterprises have agents running that their security teams don’t know about or fully understand. Another survey found that only around 30% of organisations regularly map non-human identities to critical assets. A team of ten developers each running a handful of agents has quietly added dozens of privileged actors to the environment, and they often outlive the projects that created them.

Four ways an agent becomes an insider

The compromised agent. Prompt injection is the headline route. Malicious instructions hidden in an email, document, web page or ticket can steer an agent into leaking data or taking actions the user never intended. This is the confused-deputy problem in a new form: the agent holds legitimate authority and an attacker borrows it.

The over-privileged agent. No attacker is needed. An agent given broad access “so it can be useful” can delete, overwrite, expose or send things it shouldn’t, simply by pursuing its goal too literally.

The unsanctioned agent. Shadow AI is the new shadow IT. Staff connect assistants to drives, CRMs and inboxes using their own credentials, creating non-human actors that no one registered, owns or monitors.

The misaligned agent. This one is less common today but worth taking seriously. In contrived, simulated test scenarios, AI developers including Anthropic have shown that models given goals and autonomy can sometimes take harmful, insider-like actions when pushed into corners. Those were laboratory setups, not field incidents, and they shouldn’t be overstated. They do argue against assuming agents will always behave as intended, especially as autonomy grows.

What needs to be done

The consensus among security practitioners is that this is first an identity governance problem and only second a monitoring one. In practice that means the following.

Treat every agent as an identity with an owner. Give each agent its own distinct identity, never a shared human account, with a named human accountable for it and a recorded purpose. Build and maintain an inventory, and run continuous discovery for the agents nobody told you about.

Apply least privilege, and make it dynamic. Scope access to the task, not to the deployer’s full rights. Prefer short-lived, just-in-time credentials over standing access, and expire agents when their projects end.

Put humans in front of high-risk actions. Deleting data, moving money, changing permissions, sending external communications and touching production should need approval. The goal isn’t to slow everything down. It is to make sure that consequential actions are never fully unattended.

Monitor behaviour, not just logins. A valid identity behaving abnormally should still trigger an alert. Security teams need to join identity signals with telemetry so they can ask whether this action, in this context, for this purpose, makes sense.

Separate untrusted input from authority. Assume anything an agent reads can contain instructions. Limit what an agent can do after ingesting external content, and constrain the combination of private data access, external content exposure and outbound communication.

Build a kill switch and rehearse it. Teams should be able to revoke an agent’s access immediately and trace everything it did. Logging must capture actions and reasoning context, not just authentication events.

Test before you deploy. Red-team agents the way you would a new privileged hire: probe them with injection attempts and boundary cases. The OWASP guidance on agentic security and non-human identities is a practical starting reference.

Govern the vendors. Agents are increasingly bought, not built. Contracts should cover logging access, incident notification and clear limits on what the vendor’s agents can reach.

The boardroom and regulatory angle

Regulators don’t distinguish between a breach caused by a person and one caused by a person’s software. In Malaysia, an agent that exposes personal data or disrupts a critical system still puts the organisation on the clock under the PDPA’s breach rules or the Cyber Security Act’s notification duties, and the accountability lands on the entity and, potentially, its directors. “The agent did it” is not a defence. Boards should ask for an agent inventory, a stated autonomy policy and evidence that high-risk actions are gated, just as they would for any privileged human role.

The caveat: don’t swing to panic or to prohibition

Banning agents isn’t realistic, and the productivity gains are real. Much of the loudest commentary on this topic comes from vendors who sell identity and monitoring products, so it pays to read the framing critically. Documented real-world damage from agents acting as insiders is still limited, and some of the current alarm is about risk trajectory rather than a wave of incidents. But the trajectory is clear, and the cheapest time to put controls in place is before agents hold the keys to everything.

Questions for the next security review

1. How many AI agents operate in our environment, and who owns each one?
2. What can the most powerful agent do if it is tricked by a malicious document?
3. Which actions require a human approval, and which don’t?
4. Can we shut an agent down and reconstruct what it did within minutes?
5. Do our incident-response plans cover an incident caused by our own automation?

The insider of the next few years may not be a person at all. Organisations that govern agents with the rigour they apply to their most privileged staff will keep the productivity and avoid most of the risk.