AI & DETECTION · 7 MIN
Rogue Security: Runtime Enforcement for the AI Coding Agent Blind Spot
Coding agents execute shell commands, push to production, and read every secret in the repo. QMasters has added Rogue Security to address the gap nothing else covers: inline blocking before the agent acts.
What is Rogue Security and how does it protect enterprises from AI coding agent risks?
Rogue Security is an inline runtime security platform that sits in the execution path of AI agents — between the prompt and the tool call, shell command, or MCP request — and blocks dangerous actions in under 5 milliseconds using local small language models (SLMs). It covers coding agents like Claude Code, Cursor, Codex, and Copilot running on developer workstations, as well as vendor-embedded agents in SaaS platforms and custom agents built internally. QMasters has evaluated and adopted it to address the gap that traditional EDR and CASB tools cannot reach: the moment before an agent acts.
Rogue Security: Runtime Enforcement for the AI Coding Agent Blind Spot
Here is the event that opened this conversation for us.
In 2025, a single Claude Code agent deleted a production database in nine seconds from one bad prompt. No malicious actor. No privilege escalation chain. One instruction, full execution, nine seconds.
The tools that were supposed to prevent this — EDR, CASB, SIEM, WAF — saw nothing useful, or saw it too late. That is not a configuration problem. It is a structural one.
Traditional security tooling was built for a world where humans execute actions. Coding agents changed that. An agent does not ask for approval. It executes. The gap is not in detection — the gap is in the nine seconds before the damage is already done.
Rogue Security closes that nine seconds. QMasters has evaluated and adopted it. This post explains what it is and how it works.
The three-agent problem
Most security teams are thinking about one of three AI agent channels. Rogue frames the actual problem clearly: there are three, and they arrive through completely different routes.
Figure 1 — The three-agent problem. AI reaches an enterprise through three separate channels simultaneously, each with a different threat profile and a different owner.
Agents you use. Cursor, Claude Code, Codex, GitHub Copilot, Windsurf — running on developer workstations. They execute shell commands, push to production, call APIs, touch databases, and read every secret in the repository. Shadow AI here is not a policy violation. It is the default.
Agents you deploy. AI shipped inside SaaS you already own — Salesforce AgentForce, ServiceNow Now Assist, Microsoft Copilot. Nobody red-teamed them before they went live. Nobody mapped what data they can reach. In most organisations, these agents have been processing requests for months with no security review.
Agents you build. Internal apps built on LangChain, CrewAI, Bedrock, Vertex, Azure OpenAI, and MCP servers. The attack surface: prompt injection (direct and indirect), tool abuse, memory poisoning, confused-deputy attacks, and cross-channel context assembly. Every internal agent your engineering team has shipped in the last eighteen months belongs here.
The existing stack — EDR, SIEM, CASB, WAF — was not built to see what an agent is about to do before it does it. None of those tools operate at the right layer. Rogue does.
How the RISC engine works
The core of Rogue Security is RISC: the Rogue Intent Scanning Core.
It sits inline in the agent's execution path, between the prompt and the action. Every tool call, shell command, and MCP request passes through RISC before it runs. RISC evaluates the intent of the action — not a regex match against known strings, but a read of what the agent is actually attempting — and issues a decision in under five milliseconds: allow or block.
Figure 2 — The RISC decision flow. Every agent action is evaluated before execution. The local SLM issues an allow or block in under 5 ms with no data leaving the customer boundary.
Three design choices define the architecture:
No cloud LLM. RISC uses fine-tuned small language models (SLMs) running locally, at the point of enforcement. Agent traffic, source code, and secrets never leave the customer boundary. Zero bytes egressed. That is not a marketing claim — it is a structural consequence of running inference locally. It is also why the latency is under five milliseconds: there is no round trip.
Intent, not pattern matching. A signature-based approach blocks known bad strings. An intent-based approach reads what the agent is trying to accomplish. An agent attempting to remove all files, regardless of how the prompt is phrased, gets blocked. The same reasoning catches novel attack patterns a signature library has not seen yet.
Override path preserved. A blocked action is logged with a reason. The engineer who triggered it sees the block immediately. If the action was intentional — a legitimate deletion, a deliberate API call — they can prefix the prompt with the override token and resubmit. The action is logged as a conscious override. Audit trail intact; developer not blocked indefinitely.
The five surfaces
The same RISC engine is packaged into five deployable products, each aimed at a different place agents live.
| Surface | Where it sits | Key controls | Deployment |
|---|---|---|---|
| Runtime Guardrails | SDK / proxy / K8s sidecar in front of custom agents | Data-exfiltration prevention, PII masking & redaction, tool allowlisting, privilege boundaries | SDK · Proxy · Sidecar |
| Red Teaming Engine | CI/CD or on-demand against any agent endpoint | 75+ attack techniques, 10,000+ probes per run, CVSS scoring, OWASP Agentic Top 10 / MITRE ATLAS / NIST AI RMF mapped | CI/CD · On-demand |
| IDE Integration | Local hook into Cursor, Claude Code, Copilot, Windsurf sessions | Code-exfiltration prevention, malicious-suggestion blocking, full audit trail, org-wide policy | Local agent |
| Browser Extension | MDM-deployable managed extension | Session monitoring and policy enforcement on ChatGPT, Claude, Gemini, Copilot web | MDM · Browser |
| AI-EDR | Endpoint agent — network and app level | Shadow-AI discovery, AI-SPM posture, risky-skill and MCP-server exposure, real-time agent activity visibility | Endpoint agent |
Three modules: the full capability picture
Around the RISC enforcement core, Rogue delivers three capability modules that cover the full agent security lifecycle — before deployment, at runtime, and across the estate.
| Module | Function | What it does |
|---|---|---|
| AI-SPM | Discover & Govern | Shadow-AI discovery across endpoints and SaaS; automated agent inventory and classification; continuous risk scoring. Answers the question: what AI agents are actually running in my environment right now? |
| AIDR | Detect & Respond | Inline detection of prompt injection, data exfiltration via conversations / tool calls / MCP, privilege escalation, lateral movement between agents, multi-agent coordinated attacks, memory poisoning, and tool misuse. Actions configurable per detection type: block, log, alert. Alerts push to SIEM or any webhook. Dry-run mode available. |
| AI-AppSec | Build Secure | Pre-deployment red-teaming for agents your teams build. 75+ techniques, 10,000+ probes, automated CVSS scoring and remediation guidance. CI/CD integration so security testing runs at the same cadence as code deployment — not after it. |
Underneath all three sits the Rogue Risk Library: a vendor-maintained reputation database of MCP servers and skills. 250,000+ scanned. 5,000+ flagged malicious. Every lookup completes in under 20 milliseconds — before an agent is allowed to load the server.
For customers running QRadar or StrongHold MCSS, Rogue AIDR events push directly into the same SIEM operations queue as any other detection source. An analyst working a case sees the full picture — endpoint, identity, network, and AI-agent behaviour — in one place.
Deployment options
Rogue supports three hosting models, which matters in regulated industries.
| Model | Data residency | Best for |
|---|---|---|
| SaaS | Rogue-hosted cloud | Fastest time to value; standard enterprise environments |
| In-VPC | Customer cloud — no egress | Financial services, healthcare, any environment with strict data-residency requirements |
| On-Premises | Fully air-gapped | Defence, critical infrastructure, classified environments |
The In-VPC and On-Prem options are credible precisely because inference runs on local SLMs. There is no external LLM call to route. The enforcement logic works identically regardless of hosting model.
Instrumentation reaches agents through five paths: SDK embedded in code, gateway/proxy in front of traffic, Kubernetes sidecar for containerised workloads, browser extension for workforce AI, and IDE hooks for coding agent sessions. 220+ integrations cover the AI you use, deploy, and build.
Where to start
If your engineers use Cursor, Claude Code, Codex, or Copilot in any form — approved by IT or not — the first question is what those agents can reach.
The practical first step is discovery: AI-EDR or AI-SPM to map what coding agents and MCP servers are running across the estate, before writing a single enforcement policy. You cannot govern what you cannot see, and in most organisations the shadow-AI picture at the coding-agent layer is genuinely unknown.
From there, the IDE integration is the fastest path to inline blocking. It requires no proxy, no gateway, no network change. It hooks locally into the session and starts enforcing policy immediately.
We will map the coding agent and MCP surface across your environment, show you where the gaps are, and scope the right deployment model for your data-residency posture.
---
References
- Rogue Security, Technical Product Overview v1.0; Executive Data Sheet — Coding Agents (2026).
- Rogue Security, Product Summary & Explanation — Runtime Security Layer for AI Agents, internal brief (QMasters, August 2026).
- OWASP Agentic Security Initiative, Agentic Top 10 (2026).
- MITRE, ATLAS: Adversarial Threat Landscape for AI Systems (2026).
- NIST, AI Risk Management Framework (AI RMF 1.0).
---
Author · Gregori Nazarovsky, CTO, QMasters
Last updated · 2026-08-21
Reading time · 7 min
FAQ
Frequently asked questions.
Rogue Security is a runtime security platform for AI agents. Its core engine — RISC, the Rogue Intent Scanning Core — evaluates every tool call, shell command, and MCP request an agent is about to execute, and decides in under 5 milliseconds whether to allow or block it. It uses fine-tuned small language models running locally, so agent traffic and source code never leave the customer environment.
The three-agent problem describes how AI agents now reach an enterprise through three separate channels: embedded agents shipped inside SaaS products (Salesforce AgentForce, ServiceNow Now Assist, Microsoft Copilot), endpoint coding agents running on developer workstations (Cursor, Claude Code, Codex, Copilot), and custom-built agents using frameworks like LangChain, CrewAI, or Bedrock. None of the three channels is covered by the same existing control, and no traditional security tool was designed to inspect what an agent is about to do before it does it.
RISC stands for Rogue Intent Scanning Core. It is the inference engine at the center of the Rogue platform, powered by fine-tuned small language models (SLMs) that evaluate tool calls and agent actions based on intent rather than pattern matching. Because the SLMs run locally — either in-VPC or fully on-premises — there is no token metering, no usage cap, and no agent data transmitted to an external service.
Rogue hooks locally into the coding agent session and intercepts every shell command, tool call, and MCP request before execution. If an action exceeds policy — a deletion of production data, an API call outside an allowlist, an attempt to exfiltrate source code or secrets — it is blocked immediately with a logged reason. The engineer sees the block and can prefix the prompt with the override token to acknowledge and resubmit if the action was intentional.
Rogue Security supports three hosting models: SaaS (fastest time to value), In-VPC (customer cloud, agent data never leaves the environment), and On-Premises (fully air-gapped). The In-VPC and On-Premises options are viable because inference runs on local SLMs rather than an external LLM, meaning no data egress is required regardless of how the platform is hosted.
ABOUT THE AUTHOR
Practitioners from the QMasters Security Operations Center. We run 24/7 monitoring, detection engineering, and incident response for organisations across regulated industries — and write here from the offense and defense work in front of us.