Insider threats aren’t defined by their job titles, but their level of access: who or what has legitimate credentials, legitimate permissions, and a legitimate reason to be inside your environment. By that definition, an AI agent that can read your inbox, touch your file shares, or execute code on an endpoint checks every box.

If you don’t give an AI agent a clearly defined identity, an attacker can hand it one instead. Without its own login, its own scoped permissions, and its own audit trail, an agent is just an unlabeled set of credentials waiting for someone to pick them up. Once that happens, the agent will do exactly what it’s told, no matter who’s doing the telling. No hesitation, no second-guessing, no gut check.

That’s the piece traditional security controls aren’t built for. A malicious employee still has to type the commands themselves, one at a time, with time to reconsider. A hijacked or misdirected AI agent just keeps going, executing at machine speed with none of the doubt that might make a person stop and ask, "Wait, should I actually be doing this?" These agents are goal-driven, not rule-bound: point one at an objective, and it will find a path to it, even if that path runs straight through your production database or your customer data. A logic error or a single poisoned instruction is all it takes for that path to go somewhere you never approved, and by the time anyone notices, the damage is already done.

This isn’t a future problem. Huntress research has already turned up real examples of AI agents creating the exact kind of risk this guide is built to help you address.

1. Agents with more access than anyone approved

Our investigation into OpenClaw found AI agents showing up as cloud applications in Microsoft tenants with permissions sets indistinguishable from high-value admin tooling: directory-wide read/write access, the ability to modify authentication methods, even the power to grant OAuth permissions on behalf of other users. In many cases, a single employee had granted the agent access to their mailbox or calendar with a single click, and no one downstream ever reviewed what that access actually allowed. The label on the app barely matters once you realize what it’s been handed. That’s an insider threat with a familiar name.

2. Agents that muddy the water during a real incident

Not every risky agent is malicious, or even misconfigured. In one incident our Security Operation Center (SOC) investigated, a legitimate user turned to OpenAI’s Codex to troubleshoot a machine that was, unknown to them, already compromised by cryptominers and credential thieves. Codex’s commands, formatted the same way an attacker formats a command, triggered detections and added noise our analysts had to sort through by hand. The user did nothing wrong. But the AI agent’s activity looked enough like an attacker’s tradecraft that it complicated the very investigation meant to help.

3. Attackers exploiting the trust you place in AI

What might be the most unsettling example doesn’t require an agent to be compromised at all; it just requires you to trust one. Huntress uncovered a campaign where attackers seeded ChatGPT and Grok conversations with malicious instructions for a common search like "clear disk space on macOS," then used classic SEO poisoning techniques to push those ChatGPT and Grok conversations to the top of Google’s results. Victims searched, clicked, and copy-pasted a Terminal command straight from what looked like a helpful AI assistant. That one copy-paste delivered a full Atomic macOS Stealer (AMOS) payload, enabling credential theft, root access, and persistent malware, no phishing email required.

As our team put it, "Malware no longer needs to resemble legitimate software. It just needs to appear helpful."

Traditional access controls make decisions at the level of a user, a device, or an IP address. AI agents don’t fit neatly into any of those buckets, which creates gaps most security stacks weren’t designed to close:

• The identity gap. A single workstation or cloud workload can run multiple agents, each pursuing different goals with different data. If your tools can only see the host and not the agent, you’re left with two bad options: allow everything or block everything.
• The shadow AI gap. Agents get installed through developer tools, browser extensions, and automation scripts, not formal deployment processes. If you can’t see when software is calling an LLM, invoking an MCP server, or moving data between systems, your asset inventory is out of date.
• The judgment gap. Most human employees know, without being told, that proprietary code shouldn’t land in a public forum. An AI agent only knows what it’s been permitted to do. Give it broad enough access, and it will use every bit of it while appearing to act as intended the entire time.

The fix isn’t to lock agents down so tightly they’re useless, and it isn’t to sit back and hope they never get compromised. Both Huntress’s own research and outside experts point to the same answer: treat AI agents the way you’d treat any new hire with real access to your systems.

• Give every agent its own identity. No shared API keys, no riding on a human’s credentials. If you can’t tell which agent did what, you can’t investigate anything.
• Scope permissions like you would for a new employee. Apply least privilege to AI agents the same way you would to a person: give access to exactly what the job requires and nothing else.
• Watch behavior, not just intent. Baseline what "normal" looks like for each agent, including tokens processed, applications touched, and data accessed, then flag the deviations. Treat unusual activity from an agent the same way you’d treat it from an employee.
• Treat every model, plugin, and MCP server like an unvetted vendor. Rogue MCP servers and malicious skills are already circulating. Don’t assume an integration is safe just because it was easy to install.
• Build a response plan for when an agent is compromised, not if. As Brian Madden put it on the Citrix blog, "It doesn’t do much good to worry about whether AI agents can be compromised. They can and they will be." Your job is to make sure you can detect, contain, and respond when it happens.

AI agent security risks aren’t a future problem to plan around later. They’re already showing up in customer environments today, hiding behind the same helpful, productivity-boosting label that got them approved in the first place.

Huntress Managed ITDR gives you a Rogue Applications (Rogue Apps) inventory to find AI agents like OpenClaw operating in your Microsoft 365 and Google Workspace tenants, along with the permissions they’ve been granted and who approved them. Pair that with Huntress Managed SIEM to trace the identity and log activity linked to an agent after it was installed, what it accessed, when, and which other identities it touched.

The goal isn’t to ban AI agents from your business. It’s to give them the same scrutiny you’d give any new insider with the keys to your systems. Get a demo to see how Huntress helps you find, watch, and contain the AI agents already running in your environment.