Connect
Right now, somewhere in your company, an employee is asking an AI tool to pull data from Salesforce and cross check it against NetSuite. They reviewed what came back and moved on with their day.
At the same time, another AI agent might be running on a schedule, quietly touching systems with nobody watching it happen. It doesn’t wait for a prompt. It just acts on its own, at whatever hour it’s set to run.
These are not the same thing. One has a person steering it. The other doesn’t. But many IT teams are treating them like they’re one, applying the same rules and the same access to both. That’s why AI agent security feels so confusing right now.
Once you see the difference between these two patterns, agentic security looks a lot like the identity and access work you already do every day for your human employees.
Here we break down the two patterns so you can start spotting them in your own environment. For the full guide on how to secure each kind of agent, without adding new tools, you can download our eBook AI Agents Are New. Your Security Foundation Doesn’t Have to Be. It’s built to walk you through this exact distinction.
For now, let’s start with the basics.
Pattern One: The Assistant Path
Let’s say an employee is using Cursor, Claude, or ChatGPT to get work done faster. They ask the assistant to find every closed-won deal this month that doesn’t have a matching invoice, create the missing invoices, and summarize what it found.
The person decided what needed to happen. The AI assistant is just the one touching the systems.
This matters because the person is still the identity here. Nobody needs to create a new digital identity for the assistant itself. What needs attention is the path the assistant travels on. What can it reach? How is it logging in? Is there a clean way to shut off that access if the employee leaves?
This pattern creates serious risks when it’s ignored. Security researchers have documented cases where attackers hide instructions inside emails or documents that an AI assistant later processes. One well known example involved Microsoft 365 Copilot, where a hidden instruction in an email tricked the assistant into pulling sensitive data and quietly sending it out. The assistant wasn’t hacked directly. It was tricked into misusing the access it already had.
That’s the main problem with the assistant pattern. When an AI tool inherits a person’s full permissions, one weak spot can expose everything that person is allowed to touch.
Pattern Two: The Autonomous Path
Let’s consider a different scenario. A RevOps agent runs on its own schedule. It moves through your CRM, finds closed deals, creates invoices, updates records, and posts a summary to Slack. Nobody is prompting it step by step. It just runs.
This is the autonomous pattern, and it’s a different kind of problem. There’s no person at the keyboard in the moment the agent acts, so the agent can’t just borrow someone else’s identity. It needs an identity of its own. That means a human owner, defined access limits, a lifecycle from creation to retirement, an audit trail, and a way to shut it off.
Without that identity, autonomous agents tend to get anchored to generic service accounts or shared API keys. These are hard to track and easy to forget about. When a project ends or an employee leaves, the agent built on top of it often keeps running anyway. This is sometimes called a zombie agent, and it’s a real security risk because nobody remembers it’s there or what it can still touch.
Agents are quickly growing in number. Gartner projects that by 2028, the average large enterprise will run over 150,000 distinct AI agents, up from fewer than 15 in 2025. Some environments already have non-human identities, which includes agents and service accounts, outnumbering human employees by as much as 100 to 1. That’s a lot of unmanaged identity risk if agents aren’t treated as identities from day one.
Why One Fix Doesn’t Cover Both
One mistake a lot of IT teams make is that they try to solve agent security with a single approach, applied evenly across both patterns. But an assistant and an autonomous agent aren’t the same category of problem wearing different clothes.
The assistant pattern is an access problem. The person is still the identity, and the fix is discovering and governing the path the assistant uses.
The autonomous pattern is an identity problem. There’s no person to lean on in the moment of action, so the agent needs a distinct identity, complete with a human owner and a lifecycle, before it can be secured at all.
Applying the same playbook to both leaves security gaps. Lock down assistants too hard, and you slow down real work a person is directing. Leave autonomous agents unmanaged, and you get zombie agents holding onto access nobody is watching.
Two Patterns, One Path Forward
Start by taking stock of what’s actually running in your environment right now.
Make a quick list of the AI assistants your employees are using and the systems those assistants can reach. Then do the same for any agents running on a schedule or trigger, and ask yourself who owns each one and whether you could shut it off today if you needed to. If you can’t answer that last question with confidence, that’s your starting point.
Once you can name which pattern you’re looking at, the security risk becomes much clearer. Is this a person’s access path that needs governing? Or is this an agent that needs an identity, an owner, and a lifecycle of its own?
That distinction is the foundation everything else in agentic security is built on, and it’s exactly where the eBook AI Agents Are New. Your Security Foundation Doesn’t Have to Be picks up. Download the eBook and learn how to secure your AI agents using the identity and access foundation you’re already running today.
