Most cybersecurity content about AI agents skips the part that matters. It jumps straight to “here’s your blind spot, here’s your gap, here’s the risk” without explaining how any of that actually happens. So before we get to the security problem, let’s get the fundamentals right.
What an AI agent actually is
When you hear “agent,” hear “automation.”
That’s the simple version. An agent is an autonomous process. It’s automation with a little more brain than the rules-based automation you’re used to (the “if it’s 5pm and X is happening, then do Y” kind). It makes decisions on your behalf and takes action on your behalf.
But here is the part you have to internalize: It operates as you.
From an identity standpoint, an agent is indistinguishable from you. If it goes off and does something antisocial, it’s doing it as you. And you gave it the keys.
This is true whether we’re talking about Claude running locally on your laptop, Agentforce running inside your Salesforce instance, Copilot embedded in Microsoft 365, or an agent your developer spun up on an MCP server last Tuesday. Different shapes, same fundamental truth. The agent is wearing your badge.
How agents are actually built
The big players, OpenAI, Anthropic, Microsoft, Google, have built an enormous stack in the cloud (other people’s computers) that optimizes for memory and execution speed. You pay for it by selecting a model. Model selection matters because it’s really a question of how many tokens (units of money) you’re going to spend to produce the outcome you want.
The agents in the cloud are powered by large language models. LLMs are predictive models. That’s all they do. You type in something, and they predict the next word based on the previous word and the context you’ve given them.
You’re going to hear “context” a lot. Context is the information the agent is given to work with. “I’m a CPO, this is what I need to accomplish today, I need it done by 5pm, I want you to do this every day from now on.” That’s a level of context. You can go much deeper, but that’s the starting point.
The deeper your context, the more autonomous the agent can be on your behalf. The more autonomous it is, the more it can do as you. You can see where this is going.
How agents plug into tools
The term you’ll hear is MCP. Model Context Protocol.
The model is the LLM. The context, as we just covered, is what the agent knows about you and the task. The protocol is the communication language that lets the agent talk to other tools and services.
The MCP world is changing fast. New servers are coming out left and right. If I put my cybersecurity hat on for a second: MCP is a great way to get data out. It’s a great way to steal data. It’s a great way to get compromised.
If you’re more technical, you may think in terms of APIs. APIs are often more deterministic, and depending on what you’re doing, they can be a better choice. MCP often wraps API calls. It’s more opaque to the end user.
Let me give you a concrete example.
I recently ran a test where I connected the Office 365 MCP to Claude on my desktop, pointed at a test instance of 365 (note: this was not production data.) I read out every single permission it asked for.
To do this, the agent needed to talk to my test instance of Microsoft 365. It asked for permissions. It did not let me choose. It said: I want all of this. Read every document, every email, your calendar, your chat messages, and who you’re in a chat with.
In that moment, I needed it to read one document. But if I wanted it to work at all, I had to say yes to everything.
Because I was using a test organization, there was a button at the bottom that I could have pressed as the administrator of that org. The button said: do you want to accept this for everyone in your organization?
In an enterprise, one click on that button grants every employee permission to do all of that. They don’t necessarily know it happened. That permission is sitting there now.
I have not yet revoked those permissions from my test org. My little agent is running back there with full access. I haven’t told it to do anything, but it could.
What it actually looks like when you run one of these
Let me summarize a recent test I ran with Claude on my own machine.
I played the role of a naïve user. No Claude.md instructions, no tuning, just a productivity request any employee might make: pull every spreadsheet from a financial folder, consolidate them into one file on my desktop, then sync that file to Google Drive hourly during work hours.
Here’s what happened next.
The agent asked for desktop access. I said yes. It asked for Google Drive access. I said yes. A sub-agent spawned on my machine. The Claude virtual machine service was sitting at 1.78 gigabytes of memory and had read every file on my desktop, including screen recordings and screenshots that had nothing to do with the task.
CrowdStrike was hanging out, watching the activity go by. I don’t think it was doing anything real, because nothing the agent was doing looked like an attack signature.
And because the agent’s work was happening inside that VM service, the hosting operating system had a much harder time getting a look at what was going on inside it.
That was one test. One user. One productivity request. Now picture that across every employee clicking “yes, I accept” right now on a tool they want to use.
The credentials question, and why “just block it” doesn’t work
The credentials come from where they always come from. OAuth. SAML. Login with Google. Login with Microsoft. Login with GitHub.
When you grant OAuth, you’re granting a long-lived token. That token persists. Most people in cybersecurity understand this in theory, but they don’t internalize it, because the assumption is that the hosting service (365, Google, etc.) has the controls. The controls exist. The granularity is often not where it needs to be, and it requires someone to actually audit them.
Here is the lifecycle I see play out:
Someone gets themselves a token. Something happens. Maybe not a real incident, but something where an administrator goes, “I have to shut this off.” They shut it off. Five minutes later, everyone is at their door saying, “I need this turned back on, right now.” Eventually a VP or a CEO says turn it back on. The administrator faces the question: do I turn it back on for the one person, or do I spray and pray and turn it back on for everyone and hope they all follow my rules?
Meanwhile, long-lived tokens sit around forever. Tokens from deprovisioned accounts can persist. A bad actor with a still-valid token can issue a command to harvest everything before anyone notices the account should be gone.
This is the part most security stacks have no model for.
Human-in-the-loop, and why beginners get it wrong
Human-in-the-loop is one of the terms you’ll hear a lot. The idea is simple: at certain points in the agent’s workflow, it stops and asks you before taking action.
Picture a racetrack. Picture a race car zooming around it. Do you just let it keep zooming, or do you stop it and give it direction? That loop is running fast, really fast. There are going to be points where you need to say, “Wait, ask me before you delete my entire financial history for the last 15 years. Ask me before you do anything destructive.”
For beginners especially, this is critical. Take action on my behalf, but tell me what it’s going to be before you do it.
The thing I see people doing most often is they treat their agentic workflows like the end-user license agreement on their software. Thirty pages of legalese. Scroll, scroll, scroll, “okay fine, I accept.” Then you find out later that you sold your firstborn.
The agent permission screen is the new end-user license agreement. People are clicking through it the same way.
The three buckets of agent risk
When I look at where agents are operating in a typical enterprise today, I see three buckets, and the risk profile is different in each.
1. The endpoint. Agents running locally on the laptop. Claude, ChatGPT, Copilot installed on the device. If I build an agent on my laptop, nothing distinguishes it from me operating off of my laptop. You can tell Claude, “I’m blocked from using this, what can you do?” and it will say, “I can remote control your browser for you.” I have done this. It works. It will upload documents for you by driving your browser. That is literally me, hands on a keyboard, except it isn’t.
2. The first-party SaaS agents. Microsoft Copilot, Google’s first-party AI, the embedded ones inside the platforms you already pay for. These come with enterprise controls, especially in newer license tiers. You can scope by group. Developers get GitHub agentic workflows. Marketing doesn’t. That’s the bucket where most security teams feel some control, because the vendor is providing the guardrails.
3. The mushy middle. ClickUp has an agent. Linear has an agent. Slack has agentic workflows. Every productivity tool now has one. I could create autonomous agents across all of these services right now, this afternoon, that may or may not be under my organization’s control.
Picture a plot. Me in the middle. Data leaving my perimeter, going to a third-party service, transiting to another third-party service, maybe coming back to me. Now picture that diagram a hundred times over, because that’s what’s actually running in your environment.
The mushy middle is where most security teams are flying blind. The endpoint is hard to govern. The first-party agents have some controls. The mushy middle has neither.
So what does this mean for security leaders
Here’s the one thing I’d want a security leader to take away.
Flow with it, because it’s happening. You don’t have a choice. Your board, your leadership, and your employees are all going to push you. Every direction.
The improv theater principle applies. “Yes, and.” If your answer to every agent request is “no, that’s not okay, you may not use agents,” that’s not going to work. Your talent will leave for companies that don’t say no.
The answer is yes, and I have a plan.
Yes, you can have some candy, but not all of it. I can’t have you on a sugar high running around. You can have some because I’ve set up a spot for you, with trust-but-verify in place. Think of it like the camera in the bank: it’s not there because everyone is a thief. It’s there because if something goes sideways, we want to see it, understand it, and respond to it. That’s the deal. The work isn’t about saying no to your people, it’s about having the ability to say yes.
That last part is the part most insider threat programs were never built for. They were built for the disgruntled human. They were not built for an autonomous process operating as that human, at machine speed, across a dozen systems.
The new question isn’t “how do I block agents.” It’s “how do I see what they’re doing once they’re inside, and how do I stop them when they drift.”
