A rogue agent is either an agent nobody authorised, or an authorised agent that starts behaving outside its intended purpose. The first is an installation problem - something running outside security oversight. The second is a behaviour problem, and it's the harder case, because every approval, every tool and every process involved is legitimate.
Usually not an attacker. Agents go rogue through excessive autonomy, overly broad permissions, unrestricted tool access, unsafe configuration, or a misread of what was actually asked. An agent given a goal and enough reach will find a path to complete it, including paths nobody intended to authorise.
Yes, and it has happened. A Cursor agent working on a staging task used an overly permissive token to delete a production database volume along with its backups. In our own controlled research, an agent asked to tidy a test environment emptied the production database instead - in 10 runs out of 12, with no attacker, no prompt injection, and matched control runs that never failed.
Shadow AI is about visibility: agents, models or accounts the organization doesn't know are in use. Rogue behaviour is about action: an agent doing something outside its authorised boundaries. They overlap often, because an agent nobody knows about is also an agent nobody governs - but an approved, fully visible agent can still go rogue.
Less than teams assume. Anthropic found developers approve Claude Code permission prompts 97% of the time, and its production data showed serious unintended harm in 6.3% of manually-approved sessions versus 2.4% of sessions under automated review. Repetitive confirmation requests create habituation, which makes manual approval a weak control for frequent agent actions.
Because nothing they inspect looks wrong. Endpoint management inventories installed applications, and EDR watches processes, files and network connections - but a rogue agent operates inside an approved application, invoking legitimate tools, with a valid user identity. The events are individually benign; the problem is the sequence and the intent behind it.
By comparing what the agent is doing against what it was asked to do. That requires the agent-specific context traditional controls lack: its instructions, loaded Skills, MCP connections, permissions and tool calls, evaluated together rather than as isolated events. Backslash assesses agents continuously for excessive autonomy, overly broad permissions and unrestricted tool access before anything goes wrong.
Yes. Backslash detects when an agent - authorised or not - attempts to operate outside its intended boundaries, and blocks the unsafe action at the endpoint before the workflow completes. That holds even when every individual tool the agent used is legitimate.
Excessive autonomy is an agent able to take high-impact actions without confirmation, sufficient controls or human oversight. It's a capability problem rather than an incident: the agent hasn't done anything wrong yet, but nothing stands between it and an action that would be difficult to reverse.
You need the chain, not just the outcome. A forensic trail connecting the agent, user, account, prompts, configuration, loaded Skills, MCP interactions, tool calls, processes and file and network access is what distinguishes adversarial manipulation from a legitimate but overscoped action - which is the first question asked after any incident.
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
