[KongchangAI]
Tech Frontiers· 2 min read· 1,426 words

Vigil: A Runtime Security Control Plane Built for AI Agents

Vigil: A Runtime Security Control Plane Built for AI Agents

Vigil uses an independent runtime control plane to block prompt injections before tool execution, addressing gaps left by traditional WAFs and static filters.

This article examines security gaps facing autonomous AI agents: traditional WAFs and static prompt filters only guard the initial input and cannot handle indirect prompt injection as agents process files, emails, and multi-step tool calls. Vigil is an independent runtime control plane that blocks malicious payloads before tool execution with under 15ms latency, especially benefiting MCP-connected tool scenarios. The project open-sources its benchmarks with published detection and false positive rates, though the article notes benchmark design affects results and recommends independent validation on real traffic.

ListenDialogue
0:005:35

Traditional WAFs and static prompt filters are no longer adequate for autonomous AI agents. When agents process external files, emails, and multi-step tool calls through frameworks like LangChain and MCP, the attack surface expands from a single initial prompt to the entire execution chain. Vigil, developed by the team behind the project, aims to solve this with an independent runtime control plane — intercepting and blocking malicious payloads before tool execution.

Reddit source post: Vigil – Open runtime control plane for AI agents and prompt injections

Why Traditional Defenses Fall Short

Static prompt filters rest on a core assumption: threats exist only in the first layer of user input. But the working pattern of autonomous agents breaks that assumption. During execution, agents read files, parse emails, and call external APIs — each step can introduce tainted data. Indirect prompt injection exploits these intermediate stages by hiding malicious instructions in content the agent is bound to process.

Traditional WAFs target known attack patterns in HTTP traffic and have virtually no ability to recognize semantic-level attacks embedded in natural language payloads. The developer points out that once agents begin executing multi-step tool calls, static filters simply cannot make blocking decisions before execution — they only see the initial prompt, not the full context that actually drives tool invocations.

Indirect Prompt Injection is an attack class distinct from direct prompt injection. Direct injection refers to an attacker writing malicious instructions directly into conversational input; indirect injection hides malicious instructions in external content the agent inevitably reads during execution — web pages, PDFs, email bodies, repository files, or JSON fields returned by APIs. When the agent uses tools to read this content and splices it into context, the model may mistake the embedded instructions for trusted tasks and execute them — calling sensitive tools, leaking data, or altering its original objective. The danger lies in the fact that the payload never passes through the user entry point, so traditional input filtering never sees it. Moreover, the payload is typically expressed in natural language without fixed signatures, making it difficult to catch with regex or signature matching. Defense approaches generally include source-tagging and trust-grading tool-returned content, policy validation before tool calls, and restricting the tools and permissions agents can reach.

Vigil's Architectural Approach: An Independent Runtime Control Plane

Vigil is positioned not as yet another prompt scanner but as an independent runtime control plane. It intercepts payloads in flight, enforcing blocking decisions before tools are executed. The developer reports interception latency under 15 milliseconds — acceptable for agent workflows that require real-time responsiveness.

The key design is the "pre-execution block" — blocking happens before tool invocation, not in post-hoc auditing. This means even if a malicious payload has already entered the agent's processing chain, Vigil still has a chance to intercept it as long as actual tool execution hasn't been triggered. For scenarios where external tools are connected via MCP, this pre-execution interception is especially important because once a tool executes, side effects may already have occurred.

The developer has also open-sourced a benchmarks repository (vigil-benchmarks) for transparent comparison of detection rates and false positive rates. In the security tooling space, few projects are willing to publish their false positive data — this deserves recognition.

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic to let AI applications connect to external tools, data sources, and services in a unified way. It decouples "tool providers" from "model hosts": servers expose tools, resources, and prompt templates, while clients (agent runtimes) discover and invoke them according to the protocol. MCP's adoption lets agents quickly connect to file systems, databases, messaging apps, and other external capabilities, but it also means the attack surface expands linearly with the number of connected tools — any tool-returned content can become a vector for indirect injection. Pre-execution interception in MCP scenarios requires intervening before the tool-call request is actually sent to the server, inspecting parameters and context provenance. Once the request reaches the server and executes, side effects like writing files or sending emails have already happened — post-hoc auditing can only contain damage, not prevent it. This is the core difference between a runtime control plane and log-auditing solutions.

The Significance and Limits of Open Benchmarks

The open-source benchmark repository is what distinguishes Vigil from most commercial security products. Prompt injection detection has long lacked a recognized evaluation standard — vendors make their own claims, and users have difficulty comparing across products. Publishing detection and false positive rates at least gives the discussion a shared data foundation.

That said, it's important to be objective: benchmark design itself influences results. Test set coverage, diversity of attack samples, and how normal traffic is simulated all affect the final numbers. The developer's proactive invitation for community feedback on "shortcomings in detection logic" shows the team understands the current approach isn't the endpoint. Teams considering adopting such tools should supplement with validation on their own traffic rather than relying solely on benchmark numbers.

Detection rate and false positive rate are the two fundamental metrics for evaluating a prompt injection detector, but they exist in natural tension. Detection rate is the proportion of malicious samples correctly blocked; false positive rate is the proportion of legitimate requests incorrectly blocked. Raising sensitivity improves detection rate at the cost of more legitimate traffic being blocked. For agent workflows, false positives aren't just a UX problem — they can interrupt multi-step tasks, cause duplicate execution, or create state inconsistencies. Judging by detection rate alone therefore tends to overestimate a solution's value. The industry focuses more on detection rate at a given false positive budget, or on combined metrics like precision, recall, and F1. Additionally, the sample distribution of the benchmark matters greatly: if attack samples come from the same source used for training or rule-writing, results will be optimistically biased; if normal traffic is simulated too cleanly, false positive rates will be underestimated. When evaluating such tools, pay attention to test set construction methods, whether adversarial variants are included, and whether confidence intervals are reported.

Who Should Pay Attention to These Tools

Teams already running autonomous agents in production are the direct audience. This is especially true for scenarios where agents touch external files, email systems, or third-party APIs — the risk of indirect prompt injection grows with agent autonomy. Developers building multi-step tool chains with LangChain or MCP should also evaluate whether a runtime control plane better matches their actual threat model than static filtering.

For teams still in the prototyping stage, the priority can be lower. But reserving hooks for runtime interception during architecture design costs less than retrofitting later. Vigil's open-source benchmark repository has reference value in its own right — even without adopting the SDK, it can help teams understand the evaluation dimensions of prompt injection detection.

Editorial Perspective

Vigil targets a real and underappreciated gap: agent security can't focus only on the entry point. The runtime control plane approach aligns with defense-in-depth logic, and 15ms interception latency with pre-execution blocking is a reasonable engineering trade-off. The open benchmark approach helps build trust, but the actual effectiveness of the detection logic still requires independent verification. The value of security tools is ultimately determined by both false positive and false negative rates — and their performance on real production traffic often diverges from lab benchmarks. The developer's openness to public criticism is a point in their favor; the next question is whether community feedback translates into substantive improvements to detection capability.

One-line Summary

Vigil uses an independent runtime control plane to block prompt injections before tool execution, filling gaps left by traditional WAFs and static filters.

Paragraph Summary

This article discusses security gaps facing autonomous AI agents: traditional WAFs and static prompt filters only guard the initial input and cannot handle indirect prompt injection introduced as agents process files, emails, and multi-step tool calls. Vigil, developed by the team, is positioned as an independent runtime control plane that intercepts and blocks malicious payloads before tool execution, with interception latency under 15 milliseconds. Scenarios involving external tools connected via MCP benefit especially from this pre-execution blocking. The project also open-sources a benchmark repository, publishing detection and false positive rates to improve evaluation transparency in this field. The article also cautions that benchmark design influences results and recommends teams independently validate with real traffic. Teams already running autonomous agents in production, or building multi-step tool chains with LangChain/MCP, are best positioned to evaluate such solutions; prototyping-stage teams can prioritize reserving runtime interception hooks in their architecture.

#AI agent security#prompt injection#runtime control plane#indirect prompt injection#MCP security#LLM security#Vigil
Share:

Related articles