There’s one lesson that always stood out to me in all my time leading incident response engagements: attackers are masters at finding a series of small issues and compounding them into the total compromise of your environment. Well, AI agents do the same thing, only it’s self-inflicted.
The Greek philosopher Heraclitus once said, "No man ever steps in the same river twice." If he were alive in the age of OpenAI and Anthropic, he would update that to say, “No agent ever steps in the same token stream twice.” Why? Because agents are non-deterministic systems operating in very dynamic environments. The risk changes based on what the agent has access to at any given time.
Your starting configuration risk: Every agent journey starts with a single step…err token. But before that first token, there’s the initial configuration you give the agent. It’s the level of access and agency you grant the agent. For the general knowledge worker, that comes down to the MCPs, Agent Skills, data, applications, and even memory that you grant the agent. Mix that in with whether you’re running that agent in YOLO mode so you don’t have to monitor it, and you’ve got quite the risk mocktail.
In a world where agents are only as useful as the tools, data, and access you give them, it’s no surprise that the number one risk we find across our customers is over-permissioned agents.
In traditional systems, risk is bound to the configuration. With a quick configuration check, you can confine the risk. The blast radius is the blast radius, and there are certainly some downstream changes that will compound that risk over time, but it remains fairly consistent and somewhat predictable.
It’s not so simple with agents. The configuration looks static from a distance. Squint and you start to see some issues. The remote MCP you gave that agent access to? It can change on a dime without you knowing until runtime (if ever). The Slack channels you gave your agent access to? That’s always changing with new data being dropped in. Emails and calendar? Yup, same thing. Your configuration may be static in what you point it to, but where you are pointing it is in no way static.
I like to visualize this as every agent starting a journey. It goes to the closet, pulls out a backpack, and looks inside to see what it’s allowed to bring along for the journey. Inside are lots of useful connectors and Skills, many of which are benign. But hidden inside those useful tools is some highly unstable dynamite. That’s your agent’s starting risk.
Each agent turn adds risk: Like a turn-based strategy game, the agent loops through actions until it completes its goal, turn by turn. Each turn is an agent action. In one turn, the agent reviews a network architecture diagram. In the next turn, the agent accesses a local file on a developer’s system that contains production secrets (yes, this happens all the time). That architecture diagram is the map. The secret is the key to open the door. The agent didn’t start off with these, but now that information is sitting in the agent’s context. It’s two new sticks of dynamite the agent added to its backpack in pursuit of its goal, not realizing that when combined, the agent’s blast radius just grew larger.
That’s how PocketOS found out the hard way that with the right ingredients, coding agents don’t always make the recipe you want. In their case, the agent deleted production data in nine seconds when it encountered a credential mismatch during a routine task.
The agent didn’t start out with the ability to delete production data. It gained it over time because, over several agent turns (and poorly configured access keys), it found a new access key and used it to delete production data and the associated backups.
Every turn the agent takes adds more context. Some of that context is helpful, some of it just another risk waiting to explode.
Don’t forget your agent’s friends: We’re just starting to knock on the door of agent-to-agent communication. It happens with subagents today. Most knowledge workers won’t notice, because the agent harness is managing it for you. As agents proliferate and start to talk with one another, now you have your agent’s social network as another risk influencer. It’s not enough to only manage your own agent’s risk. Now you have to factor in who your agent is talking to. Suddenly, your agent's risk is tied to the risks of that sketchy agent that stays out late and bullies other agents.
We will start to see more issues of the confused deputy problem, where an agent starts in one area and may not have permissions to do something, finds another agent that does, and uses that agent to accomplish its task. It’s what human attackers abused to gain access to Instagram accounts when they simply asked the chatbot to hand it over. A willing agent with access to other agents and tools becomes an accomplice.
The blast radius changes fast with agents: You can’t rely solely on the starting configuration and risks to check the box. It may give you a good idea of how much dynamite the agent is holding at the start, but that risk changes with every turn. When agents operate autonomously, the risk shifts exponentially based on what they’re doing.
That’s why you need to start with a low risk profile and monitor every action an agent takes while monitoring that agent’s trajectory. You have to understand the blast radius at any given time to understand whether the action that agent is about to take is truly safe and necessary, or it’s just tossing a match into a backpack full of dynamite.
If you have questions about securing agents, let’s chat.
