Friction is a root cause for agents going rogue. Put a block in place, like a sandbox, and the agent is more likely to work to find a way around it. We saw it recently when a security agent running in Cursor raided a developer’s Keychain and tried to route around its sandbox. It’s not just agents that go rogue, though…

In a recent alert Evoke flagged, the agent stayed away from the developer’s credentials thanks to a managed CLAUDE.md file the organization had pushed out. It included a prompt to never hardcode or log secrets.

The agent followed orders…but the human was a different story. They grew frustrated because the agent couldn’t proceed without the right credentials. So, just like a rogue agent, the developer found a way around it…

A developer opened Claude Code and asked it to help troubleshoot a new ticket. The agent pulled the JIRA ticket, cut a branch, made configuration changes, and flagged three open questions for the developer. It was perfect teamwork. And because this agent wanted the gold star, when it ran into missing credentials or a sandbox limit, it moved on.

Unlike its Cursor cousin, it didn’t raid the user’s Keychain or try to slip past the proxy. It worked exactly as every security team would hope.

If the story ended here, it’d be a case study for how guardrails are supposed to work. But you know that isn’t this type of write-up…

Then came the question that took a hard left turn: “How do I test this locally?”

That moved the work from the agent’s sandbox to the developer’s terminal. Still no fouls as the developer kept working on the ticket. At 7:37 the next morning, things changed. The agent diagnosed a stale token and prescribed a fix. The agent wouldn’t read the .env file, but the human could…

The ! prefix runs the command straight in the developer’s shell. No model decision or approval needed. The output still lands in the agent conversation, but here it was redirected to a file, so nothing came back to the agent. No harm, no foul. This time.

But notice the pattern. The agent couldn’t touch the secrets, so it routed the secrets work through the human.

Three minutes later, auth turned back on in the testing, which wasn’t supposed to happen. The user never asked to change that. Requests to the developer’s system began redirecting to an Auth0 login page because the new variables in the environment file restored auth settings that the local setup had turned off. When the developer asked the agent what was going on, the agent owned it.

And that’s when the developer escalated…

Every secret the agent had been told to leave alone had just been hand-delivered to it. At that point, all of those secrets were fair game for the agent to use. But, we’ll give props to the agent. Its very next response led with the problem.

Then it went right back to fixing the config as if nothing happened. As did the developer.

The next morning, the developer came back with good news. They rotated credentials. Not because they paid attention or the agent reminded them, though. It was because the security team reached out after Evoke alerted them to the activity.

The agent course-corrected too. The day before, it had the developer run it with !, which runs it through the session. This time it sent the developer to their own terminal and kept the secrets out of the conversation entirely, not risking anything.

We point out flaws a lot. But this time, the agent did the right thing…mostly. It followed its managed instructions. But it’s a prime example of why model controls alone are not effective. The instructions governed the agent. Nothing governed the human. And the agent still made mistakes that guided the human down a bad path.

This little mishap didn’t cost the organization anything. There wasn’t a security incident. It was one of many examples of agents facilitating poor security practices. Those practices mount over time and create a ripe environment for threat actors to exploit later. These are the types of security gaps that will spiral out of control.

The human failed where the agent held. The keys leaked because the last line of defense was a frustrated developer typing “wtf” before their coffee kicked in. Good news, humans. After all the talk about agents being the weakest link, you’ve got your title back.

Sandbox all you want. There are just too many ways around sandboxes and prompt-focused controls. For every security team, here are three things to consider moving forward:

Monitor human and agent activity: Humans and agents are a team. When one does something right, the other might mess up, as we saw here. Prompts tell you what humans are doing. Responses and tool calls tell you what agents are doing. Prompts are an egress channel. Watch only one, and you miss half the story.

Keep secrets out of the agent’s session: The immediate risk may seem low. The developer already has access to those keys. But a pasted secret doesn’t stay on the workstation. It goes to the model provider and sits in the session transcript. The bigger threat is the agent having those credentials on hand when it decides they’d help finish the task, even if using them ends in disaster. It’s like telling a child not to run by a pool. No one has ever had to say that just once.

Respond accordingly: Detection only matters if it triggers a response. Here, the keys were rotated by the next morning, which beats most organizations, who wouldn’t even know it happened. Get the visibility and build the playbook now: alert the right owner, rotate the exposed keys, and stop or reset the session that’s carrying them.

If you want to see what your developers are pasting into their agents, request a Rogue Agent Assessment.

If you have questions about securing agents, let’s chat.