Paper deep dive

Constrained-Action AI Remediation for SIEM/XDR via a NeMo-Guardrails Proxy

Georgios Koutidis, Nikolaos Kekatos, Tom Nianios, Alexios Lekidis

Year: 2026Venue: arXiv preprintArea: cs.CRType: PreprintEmbeddings: 41

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%

Last extracted: 10/11/2026, 3:30:27 AM

Summary

This paper presents a constrained-action architecture for Security Operations Centers (SOCs) that integrates Large Language Models (LLMs) with SIEM/XDR systems while mitigating risks like prompt injection and unauthorized command execution. The solution employs a NeMo-Guardrails proxy to screen inputs and outputs against adversarial attacks and data leakage, and a control plane that restricts LLM outputs to a closed intent vocabulary, validated by an argument validator before execution by thin endpoint agents. Evaluation shows the proxy significantly improves injection recall (94.5%) with minimal false positives.

Entities (13)

LLM · technology · 99%NeMo-Guardrails · software-framework · 98%Prompt Injection · threat · 97%SIEM · system · 95%XDR · system · 95%MITRE ATT&CK · framework · 92%Clone Systems · organization · 90%University of Thessaly · organization · 90%Wazuh · software · 90%AdvBench · dataset · 88%HarmBench · dataset · 88%JailbreakBench · dataset · 88%Loghub · dataset · 85%

Relation Signals (8)

NeMo-Guardrails → mitigates → Prompt Injection

confidence 96% · The stock proxy lifts injection recall from 25.0% to 94.5%

NeMo-Guardrails → usedby → Constrained-Action Architecture

confidence 95% · We present a constrained-action architecture with two coordinated layers... (ii) a NeMo-Guardrails proxy

Constrained-Action Architecture → prevents → Unauthorized Command Execution

confidence 93% · the closed intent vocabulary and argument validator contain the observed LLM failure modes before any command crosses the trust boundary

SIEM → integratedwith → LLM

confidence 92% · LLMs are increasingly proposed as reasoning engines that triage alerts... in autonomous deployments

Wazuh → basisfor → Constrained-Action Architecture

confidence 90% · An agent–manager system derived from the Wazuh/OSSEC line

JailbreakBench → usedinevaluationof → NeMo-Guardrails

confidence 88% · JailbreakBench [26]... evaluated out-of-the-box

HarmBench → usedinevaluationof → NeMo-Guardrails

confidence 88% · HarmBench [27]... evaluated out-of-the-box

AdvBench → usedinevaluationof → NeMo-Guardrails

confidence 88% · Adversarial inputs draw on three published jailbreak benchmarks: AdvBench [25]... evaluated out-of-the-box

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Security Operations Centers (SOCs) for information technology and operational technology share one incident-response problem: a flood of correlated alerts and too few analysts. Large Language Models (LLMs) are increasingly proposed as reasoning engines that triage alerts and, in autonomous deployments, issue commands that block IPs, kill processes, or quarantine files on production hosts. This coupling introduces a new risk: a single adversarial alert can become a remote code path through the LLM's reasoning, leading it to recommend an action the SOC then executes. We present a constrained-action architecture with two coordinated layers: (i) a SIEM/XDR control plane that grounds remediation in correlated host events and confines the LLM's output to a closed intent vocabulary whose templated commands are executed by thin endpoint agents, backstopped by an argument validator; and (ii) a NeMo-Guardrails proxy that wraps the SOC-analyst LLM with input- and output-rail policies, evaluated out-of-the-box against a SOC-specific adversarial corpus we release. The stock proxy lifts injection recall from 25.0% to 94.5% at a 0.1% false-positive rate, and a live red-team exercise confirms that the closed intent vocabulary and argument validator contain the observed LLM failure modes before any command crosses the trust boundary. As an architectural fit (not yet a measured operational-technology deployment), the constrained-action property suits critical-infrastructure settings where a wrong remediation has physical, not merely operational, consequences. The loop is best run human-in-the-loop or delayed: the measured rail latency keeps inline control out of scope.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

37,384 characters extracted from source content.

Expand or collapse full text

Constrained-Action AI Remediation for SIEM/XDR via a NeMo-Guardrails Proxy Georgios Koutidis1, Nikolaos Kekatos1, Tom Nianios1, and Alexios Lekidis2 Affiliation: 1Clone Systems, Larnaca, Cyprus gkoutidis, nkekatos, tnianios@clone-systems.com 2University of Thessaly, Department of Intelligent Energy Systems, Larissa, Greece alekidis@uth.gr Abstract Security Operations Centers (SOCs) for information technology and operational technology share one incident-response problem: a flood of correlated alerts and too few analysts. Large Language Models (LLMs) are increasingly proposed as reasoning engines that triage alerts and, in autonomous deployments, issue commands that block IPs, kill processes, or quarantine files on production hosts. This coupling introduces a new risk: a single adversarial alert can become a remote code path through the LLM’s reasoning, leading it to recommend an action the SOC then executes. We present a constrained-action architecture with two coordinated layers: (i) a SIEM/XDR control plane that grounds remediation in correlated host events and confines the LLM’s output to a closed intent vocabulary whose templated commands are executed by thin endpoint agents, backstopped by an argument validator; and (i) a NeMo-Guardrails proxy that wraps the SOC-analyst LLM with input- and output-rail policies, evaluated out-of-the-box against a SOC-specific adversarial corpus we release. The stock proxy lifts injection recall from 25.0%25.0\% to 94.5%94.5\% at a 0.1%0.1\% false-positive rate, and a live red-team exercise confirms that the closed intent vocabulary and argument validator contain the observed LLM failure modes before any command crosses the trust boundary. As an architectural fit (not yet a measured operational-technology deployment), the constrained-action property suits critical-infrastructure settings where a wrong remediation has physical, not merely operational, consequences. The loop is best run human-in-the-loop or delayed: the measured rail latency keeps inline control out of scope. Index Terms: SIEM, XDR, OT security, critical infrastructure, large language models, prompt injection, guardrails, SOC automation, constrained-action policy. †footnotetext: © 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. This work has been accepted for publication at the 2026 IEEE International Conference on Cyber Security and Resilience (IEEE CSR 2026). I Introduction Modern Security Operations Centers (SOCs) face two compounding problems. The first is volume: the overwhelming majority of alerts are false positives or low-value triggers [1, 2, 3]. The second is cognition: analysts cannot keep pace with correlated incidents while junior-tier turnover thins expertise [4, 5]. LLM-based “SOC analyst” agents are an attractive answer: given an enriched incident, a large language model (LLM) with reasoning and tool-use [6, 7] can summarise root cause, propose containment, and, if wired to the security-information-and-event-management (SIEM) system’s active-response engine, trigger it directly. Three properties of this deployment surface make naive integration unsafe: 1. The input is hostile by construction. The model reads log lines and alert payloads originating, at least partly, from the very adversary it is trying to detect: HTTP bodies that instruct it to ignore prior directives, Base64 prompts in SSH logs, homoglyphs or zero-width characters in alert metadata. Such telemetry-borne manipulation can subvert LLM-driven information-technology (IT) operations end-to-end [8]. 2. The output drives privileged action. A recommended “block IP” or “kill process” may be executed on every endpoint. Hallucinated arguments, taint-style flows through tool calls [9], or attacker-induced choices become outages or self-inflicted DoS, a highest-impact failure mode in agentic-AI surveys [10]. In operational-technology (OT) and critical-infrastructure contexts the same recommendation can disconnect a sensor, trip a relay, or stop a controller, turning an operational bug into a safety incident. 3. The model itself is a confidentiality boundary. Logs routinely carry credentials, internal IPs, connection strings and user data; forwarding these verbatim to a hosted LLM, or returning them downstream, is a data-exfiltration risk that jailbreaks can amplify [11]. This paper describes a constrained-action AI-remediation pipeline that takes these three properties as first-class constraints. The contributions are: • An action-bounded SIEM / extended-detection-and-response (XDR) control plane (Section IV). An agent–manager system derived from the Wazuh/OSSEC line [12] in which the manager confines the LLM to a closed intent vocabulary, expands intents into OS-specific templated commands validated argument-by-argument before dispatch, and has thin cross-platform agents execute them. The split removes the LLM’s ability to synthesise executable strings. • A NeMo-Guardrails LLM proxy (Section V). An OpenAI-compatible proxy that wraps the SOC-analyst’s LLM with an input rail against prompt injection in log content, an output rail against Personally Identifiable Information (PII) and infrastructure-data leakage, and a topical dialog rail. The proxy reuses default rail primitives, providing a fair external defence layer that can be enabled by a single configuration change. • An open evaluation against default-configured NeMo Guardrails (Section VI). A head-to-head measurement over a SOC-specific adversarial corpus we release shows the proxy lifts injection recall from 25.0%25.0\% to 94.5%94.5\% at 0.1%0.1\% false-positive rate (FPR), and a live red-team across three MITRE ATT&CK chains confirms the control plane intercepts both observed LLM failure modes (target imprecision and intent drift) before any command crosses the trust boundary. The two layers interlock around the LLM core: the proxy hardens the prompt and completion paths against injection and data leakage, while the control plane bounds the action path to a closed, audited intent vocabulary. I Related Work LLM-driven SOC response. Field studies consistently find that a SOC’s dominant cost is not detection but analyst throughput on alerts dominated by false positives [4, 1, 2], and that even structured tier-1 investigations scale poorly [5]; reinforcement-learning triage attacks the same fatigue from the prioritisation angle [3]. LLM-driven response is the emerging answer: Microsoft Copilot for Security’s Guided Response [13] drives a SIEM/XDR control plane with LLM agents, and APPATCH [14] is an analogous “LLM-as-remediator” for patching. Yet neither constrains the model’s action surface nor reports robustness on the adversarial telemetry channel itself. Agentic AI and prompt injection. ReAct [6] and Toolformer [7] established the reason-and-act template our SOC-analyst follows, and its attack surface is now well charted: AI Oops [8] subverts LLM-driven IT operations through telemetry manipulation, precisely our input-side threat; AgentFuzz [9] propagates taint through tool calls; sudo rm -rf [11] coerces agents into destructive shell actions; and a SoK [10] and AgentDojo [15] systematise and formalise the threat. We treat each category as a design constraint with a corresponding gate below. Guardrail primitives. Input/output gates (perplexity detection [16], SmoothLLM [17], backtranslation [18], Llama Guard [19], Presidio [20], and the OWASP LLM Top-10 [21]) supply the building blocks for rails. We are orthogonal to these: our contribution is end-to-end action containment, so that even a successful injection reaches only an action set bounded by the policy engine, not by the model’s compliance. IT/OT standards. Control-set standards already prescribe restricted action surfaces for automated response: NIST SP 800-82r3 [22] bounds automated containment in industrial control systems (ICS) to operator-vetted actions, and IEC 62443 [23] codifies the same restricted-action principle for industrial automation. Our closed intent vocabulary instantiates that prescription for an LLM-driven loop; hierarchical runtime verification pursues the same deterministic bounding of untrusted components on the edge-IoT side [24]. I Threat Model and System Architecture We assume an attacker who controls at least one application log source seen by an endpoint agent and the network content of requests reaching monitored services; we do not assume the SIEM manager, the LLM, or the operator workstation is compromised. The attacker pursues three goals: (G1) make the LLM ignore its task and follow instructions embedded in a log line; (G2) make it recommend a remediation against a benign asset (a self-inflicted DoS, or a stepping stone for lateral movement), especially costly in OT, where the target is a physical asset and a wrong action carries a safety cost; and (G3) exfiltrate sensitive log content through the LLM’s reply. The LLM provider is therefore semi-trusted: it must not see PII or infrastructure data unredacted, and its output must not be executed verbatim. Trust boundaries fall between the agent host, the SIEM/XDR manager, the proxy, the LLM provider, and the active-response executor. Figure 1 shows the resulting trust topology; each arrow names the data form crossing that boundary. Log content(adversary-writable)EndpointagentSIEM/XDRmanagerNeMoproxyblocks G1/G3LLMbackendArgumentvalidator & templateblocks G2Active-responseexecutorattacker-controlledpolicy boundarysemi-trustedraw bytesevents,mTLSincidentscreenedpromptcompletionscreenedcompletionvalidatedintent & argswhitelistedcommand Fig. 1: Trust-boundary view of the remediation pipeline. Shading encodes distrust: dark dashed = attacker-controlled, mid-gray = semi-trusted (LLM provider), light gray with a heavy border = policy boundary (the NeMo proxy, which screens all traffic to and from the LLM), white = fully trusted (SIEM/XDR control plane). Arrow labels name the data form crossing each boundary, as raw attacker bytes are progressively sanitised into a whitelisted command. The proxy blocks G1 (telemetry-borne injection) and G3 (leakage via the reply); the validator blocks G2 (attacker-induced action): the attacker goals of Section I. The pipeline runs in four sequential stages: telemetry collection (endpoint agents forward host events over a mutually-authenticated TLS (mTLS) WebSocket), correlation and incident shaping (the manager emits an incident structure rather than a raw alert), guardrail mediation (the NeMo-Guardrails proxy screens the prompt and completion in both directions for injection, PII and infrastructure data), and constrained execution (the LLM’s recommended intent is mapped to a whitelisted OS-specific command). Sections IV and V detail the stages. IV SIEM/XDR with Guardrailed Active Response The SIEM/XDR control plane is the foundation on which the AI-assisted remediation loop runs. It follows the Wazuh/OSSEC host-based intrusion-detection system (HIDS) pattern, structured to make guardrailed LLM integration first-class. The implementation evaluated here is therefore a host-based instance of the constrained-action pattern; network- and identity-telemetry sources (network detection and response, NDR; identity threat detection and response, ITDR) sit naturally on the same control plane but are not exercised in this study. IV-A Telemetry pipeline Endpoint agents, packaged for Linux, Windows, macOS, and Linux-based OT collectors that aggregate programmable-logic-controller (PLC), human-machine-interface (HMI) and SCADA syslog into one runtime, collect process, log, file-integrity, registry (Windows), and active-response events. Registration runs over mTLS, steady-state messaging over a TLS/AES-256-GCM WebSocket. The manager correlates events into incidents carrying asset identity, MITRE ATT&CK tactics where derivable, and a rule-engine severity score. IV-B SOC-analyst LLM agent Inside the manager, the SOC-analyst service runs a ReAct [6] loop bounded in iterations and wall-clock time. Its inputs are the incident structure, alert level, MITRE tactics, and a redacted excerpt of the originating log; its outputs are an analysis (severity, evidence, reasoning) and a list of action intents. The default backend is a locally-served 14B-parameter open-weights model, with low sampling temperature to reduce variability across reruns of the same incident. Crucially, the SOC analyst does not emit shell commands. It emits intents drawn from a closed vocabulary: block IP, kill process, quarantine file, delete file, disable user, custom-script (manager-templated). Each intent carries the arguments the LLM derived (an IP address, a PID, a filename), but does not specify how to execute them. IV-C Smart manager, thin agent The manager is responsible for translating intents into OS-specific command lines, drawn from a parameterised template store: Linux distributions use the host’s native firewall front-end, Windows uses the built-in firewall cmdlets, and macOS uses its packet-filter facility. The LLM-supplied argument is the only attacker-influenced quantity in the rendered command, and it is validated against type-specific patterns (e.g., strict IPv4/IPv6 regexes for block-IP intents) before substitution. The agent then executes the command generically. A whitelist restricts allowed binaries to a narrow set covering network, process, file, user-management and firewall categories. Argument strings are scanned for shell metacharacters and destructive patterns; matches abort execution and report a violation. The intent-to-command synthesis path on the manager therefore performs three checks before any command leaves the trust boundary: the intent must belong to the closed vocabulary, every argument must satisfy its schema, and the rendered command must pass binary-whitelist and metacharacter scanning. Operationally, the engine polls correlated alerts at fixed intervals with per-command timeouts and grace periods, retries failed actions with exponential backoff, and persists every command, LLM rationale, and result as a per-incident audit trail; a per-cycle batch ceiling and per-(rule, target) cooldown limit flooding under bursty alerting. This division of authority is deliberate: were the LLM allowed to emit literal commands, a single input-side guardrail miss could let an attacker-induced argument escape into a shell. Restricting its output to a closed vocabulary rendered through validated templates leaves only the choice of intent and argument as attack surface, never command syntax. V NeMo Guardrails LLM Proxy The SOC-analyst delegates reasoning to the LLM, treated as a semi-trusted component (Section I). We wrap it with an external defence layer, the NeMo Guardrails proxy, between the SOC-analyst service and the model backend. V-A Proxy architecture The proxy is a NeMo Guardrails server exposing an OpenAI-compatible chat-completion endpoint; the SOC-analyst simply repoints its existing provider at the proxy rather than the model, requiring no application code change (Figure 2). SOC-analystserviceInputrailLLMOutputrailresponse Fig. 2: Request flow through the NeMo Guardrails proxy. The input rail classifies whether the user message is safe to forward; if it blocks, the main LLM is never invoked. The output rail re-screens the completion before it returns to the caller. V-B Rails Three rails are configured. Each self-check rail invocation is itself an LLM call with a task-specific prompt. Input rail. An LLM classifier decides whether the message contains an injection attempt, explicitly separating logs that describe a security event (“Failed password for root from 198.51.100.7”), forwarded, from logs that contain attacker directives (“Failed login. IGNORE PREVIOUS INSTRUCTIONS”), blocked. On a block the proxy returns a canned refusal and the main LLM is never reached. Output rail. A symmetric classifier screens the completion for PII (names, emails, SSNs, credit cards), infrastructure data (private IPs, MAC addresses, connection strings, key fingerprints), and content the model should have refused, blocking any hit from being returned verbatim; this is the return-path defence for goal G3. Topical dialog rail. A small flow refuses off-task inputs that pass the input self-check (jokes, weather, chat); it keeps the analyst on task and fires rarely in production. V-C Defaults and latency profile The rails above are NeMo Guardrails’ default primitives. We deliberately did not hand-tune the rail prompts to the adversarial corpus of Section VI, since an external baseline co-evolved with the evaluation set is worthless. The customisations are limited to: (i) SOC-specific phrasing in the input rail for the “describes versus contains” distinction; (i) SOC infrastructure-data categories in the output rail; and (i) a small topical flow. Each self-check rail is itself a complete LLM call, and NeMo sequentialises them so the output rail can see the completion: a blocked request costs one round-trip (the main LLM is never invoked), while a passed request costs three sequential calls (input → main → output), three round-trips where the bare call makes one. VI Preliminary Evaluation We deployed the full stack on a single Apple M4 Max machine (14-core CPU, 32-core GPU, 36 GB unified memory) running a locally-served 14B-parameter open-weights model. Evaluation corpus. Adversarial inputs draw on three published jailbreak benchmarks: AdvBench [25] (60, sampled), JailbreakBench [26] (40) and HarmBench [27] (50, sampled), embedded into plausible log shapes (HTTP bodies, syslog fields, SSH banners). On these 150 base prompts we apply the four SOC-specific transformations the deterministic pre-filter targets: homoglyph substitution (20), Base64 wrapping (15), fake [SYSTEM] framing (10) and zero-width insertion (5), for 200 variants (Table I). Benign traffic is 1,000 LogHub [28] lines across the Linux, Apache, OpenSSH and Windows splits. We release the sampling and augmentation code and per-record provenance under the MIT license; upstream prompts are re-fetched at build time, not redistributed. TABLE I: Adversarial-corpus composition (200 variants). Rows 1–3 are sampled from published benchmarks; rows 4–7 are SOC-specific transformations. Category Count AdvBench (sampled) [25] 60 JailbreakBench [26] 40 HarmBench (sampled) [27] 50 SOC augmentation: homoglyph (Cyrillic → Latin) 20 SOC augmentation: Base64 wrapping 15 SOC augmentation: fake [SYSTEM] framing 10 SOC augmentation: zero-width insertion 5 Total adversarial 200 Benign [28] 1,000 External-baseline comparison. We compare the bare model (the “raw LLM” baseline) against the same call wrapped in the proxy of Section V. Both endpoints share the model, sampling parameters, and classification prompt, so the only variable across rows of Table I is the guardrail layer. Raw inference classified 50/20050/200 adversarial inputs correctly (recall 25.0%25.0\%) with zero false positives on the benign corpus (FPR 0.0%0.0\%); median latency was 0.310.31 s because the model defaults to answering “NO” on inputs it does not recognise as obviously injection-shaped. The NeMo Guardrails proxy lifted recall to 94.5%94.5\% (189/200189/200 caught at the input rail, an absolute gain of 69.569.5 percentage points) with FPR climbing to 0.1%0.1\% (one benign log mis-blocked); median latency rose to 14.1414.14 s: the passed path makes three sequential rail-plus-main LLM calls, each far longer than the 0.310.31 s bare classification call. The per-category breakdown (Table I) is more informative. The raw classifier’s worst category, Base64-wrapped directives at 13.3%13.3\%, recovers to 100%100\% under the input rail, whose prompt explicitly flags encoded payloads; homoglyph (25%→95%25\%→ 95\%) and zero-width (40%→100%40\%→ 100\%) perturbations are near-fully recovered. The residual gap is HarmBench base prompts (NeMo 80%80\%): ten mid-severity behaviour requests the rail judges ambiguous rather than adversarial, a known limitation of single-call self-check verdicts that a tuned rail would close. TABLE I: Head-to-head injection-defence comparison. Recall is over the 200 adversarial variants of Table I; FPR is over the 1,000 benign LogHub lines. Latencies are end-to-end per call. Configuration Recall FPR P50 (s) P95 (s) P99 (s) Raw LLM (no defence) 25.0% 0.0% 0.31 0.48 1.20 NeMo Guardrails proxy 94.5% 0.1% 14.14 27.41 32.90 TABLE I: Per-category recall on the 200 adversarial records (base prompts wrapped in HTTP/syslog/SSH log shapes; SOC rows further transformed). Category n Raw recall NeMo recall AdvBench (base) 60 21.7% 100.0% JailbreakBench (base) 40 35.0% 100.0% HarmBench (base) 50 20.0% 80.0% SOC aug.: homoglyph 20 25.0% 95.0% SOC aug.: Base64 15 13.3% 100.0% SOC aug.: fake [SYSTEM] 10 40.0% 100.0% SOC aug.: zero-width 5 40.0% 100.0% Latency distribution. Figure 3 shows the end-to-end latency cumulative-distribution function (CDF) per endpoint, faceted by adversarial and benign records. The NeMo endpoint is bimodal: a fast tail for inputs blocked by the input rail (∼ 0.5 s, one LLM call) and a slow tail for inputs that pass all three rails (∼ 10–15 s, three LLM calls). Raw inference, by contrast, collapses near ∼ 0.3 s for both labels. Fig. 3: End-to-end latency CDF (log-scale x-axis), split by endpoint and label: the raw curve concentrates near ∼ 0.3 s; the NeMo curve is bimodal between fast-blocked and full-pipeline traffic. Deterministic pre-filter and cascade triage. Two cheaper front-ends test whether the three-rail proxy’s per-request cost (Section V) can be cut (Table IV). The first is a deterministic pre-filter (Tier-0): a zero-LLM regex and Unicode-normalisation gate inverting the four SOC augmentations of Table I. It blocks only on a positive signature, never declaring a line clean, so it cannot pass a marker-free jailbreak. It recovers all 50 augmented records at 0.00%0.00\% FPR with zero LLM calls; in front of the proxy it lifts recall to 95.0%95.0\% (catching the one homoglyph variant the input rail missed) and trims mean round-trips from 3.003.00 to 2.882.88. But the median request is benign and carries no marker, so Tier-0 does not move the median latency: it is a recall-safe, zero-cost addition, not a latency fix. The second front-end is a lightweight semantic classifier: a small llama3.2:3b model triages each request, escalating only those it judges adversarial to the full proxy. This cuts mean round-trips to 1.151.15 and the median latency to 0.180.18 s (a 78×78× reduction) at 0.00%0.00\% FPR, but recall falls to 58.0%58.0\%: a cheap model cannot adjudicate the benign majority, and its misses (semantic jailbreaks in well-formed log fields) are forwarded silently. Confirming the gate’s benign verdicts with the proxy instead restores recall to 95.0%95.0\% but escalates the benign majority, raising round-trips to 3.643.64 and erasing the latency gain. The cascade thus exposes a strict recall/latency trade-off; the recall-preserving route to lower latency is to cut the rails’ own cost, not to front them with a weaker model (Section VII). TABLE IV: Cascade triage over the full corpus (200 adversarial, 1,000 benign). The deterministic Tier-0 gate inverts the four SOC augmentations of Table I; calls/req is the hardware-independent comparison (pass-path count for the proxy rows; measured mean, including the gate call, for the cascade). Configuration Recall FPR Calls/req P50 (s) Full NeMo proxy (Table I) 94.5% 0.10% 3.00 14.14 & deterministic Tier-0 (recall-safe) 95.0% 0.10% 2.88 14.11 Cheap-gate cascade (fast triage) 58.0% 0.00% 1.15 0.18 Active-response correctness (live). Three MITRE-mapped scenarios (T1110 SSH brute-force, T1059 reverse-shell exec, and T1078 valid-account abuse) were driven against a bootstrapped SIEM/XDR stack with a registered endpoint and the SOC-analyst service set to manual-only mode. Across 54 injected alerts (26+14+1426+14+14), the SOC-analyst emitted 41 action records. T1110 produced 36 block-IP actions targeting the synthesised attacker IP from the brute-force log lines; intent and target were both correct, including on a spliced-injection alert. T1059 produced one kill-process action with intent correct but target extracted from an alert metadata field rather than the PID embedded in the log; the manager’s argument validator rejects targets that do not match the expected schema and would not dispatch this command, illustrating the second-stage backstop role of the control plane. T1078 produced zero disable-user actions; instead the LLM emitted four block-IP actions on the attacker IP visible in the SSH log, an instance of intent drift toward the most prominent log field. The closed intent vocabulary nonetheless bounds the chosen action to the safe whitelisted set. All 41 actions registered as requiring manual approval and none were dispatched; end-to-end dwell time (alert to action) ranged 19–58 s per record. The control plane thus contained both failure modes: imprecise target extraction (T1059, caught by the validator) and intent drift (T1078, bounded by the closed vocabulary). VII Discussion and Limitations Latency vs. depth. The NeMo proxy raises the median per-call cost from 0.310.31 s to 14.1414.14 s on benign traffic traversing all three rails, roughly 46×46× the bare classification call: beyond the three round-trips, each rail call carries its own prompt-construction and generation cost. This is acceptable for active-response timelines (already in the human-in-the-loop minute range) but prohibitive for inline use such as authentication. The cascade study (Table IV) shows that fronting the proxy with a cheaper classifier only trades recall for latency; the recall-preserving optimisation is instead to cut per-request rail cost, e.g. a single fused classifier rail emitting both verdicts in one pass, with verdict caching on canonicalised log fingerprints as a complementary step. Threats to validity. The proxy uses stock rail primitives with only the prompt-text customisations needed for SOC log content. A SOC-tuned deployment (chain-of-thought self-check, input-rail perturbation ensembling, or an output rail backed by Llama Guard [19]) would likely improve the proxy row of Table I; we do not co-evolve the baseline with our corpus, so the NeMo numbers are a fair out-of-the-box baseline, not a maximum-effort one. Other limitations. Multi-turn injections spanning more than one log line are not modelled; the proxy treats each request independently, and a per-asset sliding-window input rail is future work. The closed vocabulary also biases the system toward containment: richer remediation (patching, configuration rollback) needs either a wider whitelist or a human approval step, which we model as a configurable action mode. Applicability to OT and critical infrastructure. OT deployments share the IT SOC’s volume problem at lower event frequency but higher per-event consequence: the closed vocabulary and pre-dispatch validator bound the LLM’s authority before an action can reach a controller or safety relay, the restricted-response surface that NIST SP 800-82r3 [22] and IEC 62443 [23] prescribe. The smart-manager / thin-agent split is also the standard OT topology, with the manager in a hardened zone, agents on field-level gateways, and model weights kept central rather than on edge nodes. This is an architectural fit only: we evaluate on host and web telemetry, not real OT protocols or field devices, so validating the closed vocabulary against live ICS/SCADA actions remains future work. Reproducibility. The corpus is built deterministically from a fixed seed over re-fetched upstream prompts; we release, under the MIT license, the sampling and augmentation code, per-record provenance (with upstream SHA-256), the evaluation harness, and the pre-filter and cascade runner with their result CSVs. All runs use locally-served phi4:14b (proxy/main) and llama3.2:3b (gate) at low temperature, so recall and FPR are near-deterministic and hardware-independent while latencies depend on the accelerator. Pinned model digests and package versions ship with the artefact, mitigating silent upstream re-tags that would otherwise shift verdict distributions. Ethical considerations. The released artefact contains only sampling scripts, augmentation code and provenance metadata; the upstream prompts come from three openly-licensed benchmarks and are re-fetched at build time; the SOC-specific augmentations are mechanical transformations, not new attacker payloads. The active-response surface can be misused if deployed without the guardrail layer or with a permissive whitelist; the closed vocabulary, argument validator and cooldown enforcement bound this risk by design, but operators retain responsibility for deployment-time configuration. VIII Conclusion Autonomous AI remediation is safe only when the LLM’s input, output, and action surfaces are narrowed by construction. Our two-layer constrained-action stack does exactly this: a SIEM/XDR control plane confines the LLM to a closed, argument-validated intent vocabulary, and a NeMo Guardrails proxy screens its prompt and completion paths. The stock proxy lifts injection recall from 25.0%25.0\% to 94.5%94.5\% at 0.1%0.1\% FPR over 200 adversarial variants and 1,000 benign log lines, a zero-cost deterministic pre-filter raises it to 95.0%95.0\%, and a live red-team confirmed both containment modes: target imprecision, which the argument validator blocks from dispatch, and intent drift, bounded by the closed vocabulary. In deployment the loop runs human-in-the-loop or delayed, since the measured rail latency keeps inline control out of scope. The lesson is architectural: keep the LLM at the periphery of a deterministic system, never at its centre. Acknowledgment This work has received funding from the European Union’s Digital Europe Programme under grant agreement No 101190251 (CYBERGUARD). References [1] B. A. Alahmadi, L. Axon, and I. Martinovic (2022) 99% false positives: a qualitative study of SOC analysts’ perspectives on security alarms. In USENIX Security 22, Boston, MA, p. 2783–2800. External Links: Link Cited by: §I, §I. [2] L. Yang, Z. Chen, C. Wang, Z. Zhang, S. Booma, P. Cao, C. Adam, A. Withers, Z. Kalbarczyk, R. K. Iyer, and G. Wang (2024) True attacks, attack attempts, or benign triggers? An empirical measurement of network alerts in a security operations center. In USENIX Security 24, Philadelphia, PA, p. 1525–1542. External Links: Link Cited by: §I, §I. [3] X. Wang, X. Yang, X. Liang, X. Zhang, W. Zhang, and X. Gong (2024) Combating alert fatigue with AlertPro: context-aware alert prioritization using reinforcement learning for multi-step attack detection. Computers & Security 137, p. 103583. External Links: Document, Link Cited by: §I, §I. [4] S. C. Sundaramurthy, J. McHugh, X. Ou, M. Wesch, A. G. Bardas, and S. R. Rajagopalan (2016) Turning contradictions into innovations or: how we learned to stop whining and improve security operations. In Twelfth Symposium on Usable Privacy and Security (SOUPS 2016), External Links: Link Cited by: §I, §I. [5] L. Kersten, T. Mulders, E. Zambon, C. Snijders, and L. Allodi (2023) “Give Me Structure”: synthesis and evaluation of a (network) threat analysis process supporting tier 1 investigations in a security operation center. In Nineteenth Symposium on Usable Privacy and Security (SOUPS 2023), External Links: Link Cited by: §I, §I. [6] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao (2023) ReAct: synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR), External Links: Link Cited by: §I, §I, §IV-B. [7] T. Schick, J. Dwivedi-Yu, R. Dessì, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, and T. Scialom (2023) Toolformer: language models can teach themselves to use tools. In Advances in Neural Information Processing Systems 36 (NeurIPS 2023), External Links: Link Cited by: §I, §I. [8] D. Pasquini, E. M. Kornaropoulos, G. Ateniese, O. Akgul, A. Theocharis, and P. Efstathopoulos (2026) When AIOps become “AI Oops”: subverting LLM-driven IT operations via telemetry manipulation. In USENIX Security 26, External Links: Link Cited by: item 1, §I. [9] F. Liu, Y. Zhang, J. Luo, J. Dai, T. Chen, L. Yuan, Z. Yu, Y. Shi, K. Li, C. Zhou, H. Chen, and M. Yang (2025) Make agent defeat agent: automatic detection of taint-style vulnerabilities in LLM-based agents. In USENIX Security 25, External Links: Link Cited by: item 2, §I. [10] J. Kim, W. Guo, and D. Song (2026) SoK: attack and defense landscape of agentic AI systems. In USENIX Security 26, External Links: Link Cited by: item 2, §I. [11] S. Lee, J. Kim, H. Park, A. Yousefpour, S. Yu, and M. Song (2025) Sudo rm -rf agentic_security. In Proc. ACL: Industry Track, p. 1050–1071. External Links: Document, Link Cited by: item 3, §I. [12] Wazuh Inc. (2024) Wazuh: the open source security platform. Note: https://wazuh.com/ Cited by: 1st item. [13] S. Freitas, J. Kalajdjieski, A. Gharib, and R. McCann (2025) AI-driven guided response for security operation centers with Microsoft Copilot for security. In Companion Proc. of the ACM Web Conference (W Companion), External Links: Document Cited by: §I. [14] Y. Nong, H. Yang, L. Cheng, H. Hu, and H. Cai (2025) APPATCH: automated adaptive prompting large language models for real-world software vulnerability patching. In USENIX Security 25, External Links: Link Cited by: §I. [15] E. Debenedetti, J. Zhang, M. Balunović, L. Beurer-Kellner, M. Fischer, and F. Tramèr (2024) AgentDojo: a dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. In Advances in Neural Information Processing Systems 37 (NeurIPS 2024 Datasets and Benchmarks Track), External Links: Link Cited by: §I. [16] G. Alon and M. Kamfonas (2023) Detecting language model attacks with perplexity. arXiv preprint arXiv:2308.14132. External Links: Link Cited by: §I. [17] A. Robey, E. Wong, H. Hassani, and G. J. Pappas (2025) SmoothLLM: defending large language models against jailbreaking attacks. Transactions on Machine Learning Research. Cited by: §I. [18] Y. Wang, Z. Shi, A. Bai, and C. Hsieh (2024) Defending LLMs against jailbreaking attacks via backtranslation. In Findings of the Association for Computational Linguistics: ACL 2024, p. 16031–16046. Cited by: §I. [19] H. Inan, K. Upasani, J. Chi, R. Rungta, K. Iyer, Y. Mao, M. Tontchev, Q. Hu, B. Fuller, D. Testuggine, and M. Khabsa (2023) Llama Guard: LLM-based input-output safeguard for human-AI conversations. arXiv preprint arXiv:2312.06674. External Links: Link Cited by: §I, §VII. [20] Microsoft (2024) Presidio: data protection and de-identification SDK. Note: https://github.com/microsoft/presidio Cited by: §I. [21] OWASP Foundation (2023) OWASP top 10 for Large Language Model Applications, version 1.1. Note: https://owasp.org/w-project-top-10-for-large-language-model-applications/ Cited by: §I. [22] National Institute of Standards and Technology (2023) NIST Special Publication 800-82r3: guide to operational technology (OT) security. Note: NIST SP 800-82 Rev. 3 External Links: Document, Link Cited by: §I, §VII. [23] International Electrotechnical Commission (2018) IEC 62443: security for industrial automation and control systems. Note: Standard series IEC 62443 External Links: Link Cited by: §I, §VII. [24] N. Kekatos, M. Chintri, P. Katsaros, A. Lekidis, T. Nianios, I. Seitoglou, A. Temperekidis, and S. Basagiannis (2026) Hybrid hierarchical runtime verification for edge-IoT security: combining MonPoly and RTLola. In Proc. of the Int. Conf. on Availability, Reliability and Security (ARES) Workshops (IWASP), Cited by: §I. [25] A. Zou, Z. Wang, J. Z. Kolter, and M. Fredrikson (2023) Universal and transferable adversarial attacks on aligned language models. arXiv preprint arXiv:2307.15043. External Links: Link Cited by: TABLE I, §VI. [26] P. Chao, E. Debenedetti, A. Robey, M. Andriushchenko, F. Croce, V. Sehwag, E. Dobriban, N. Flammarion, G. J. Pappas, F. Tramèr, H. Hassani, and E. Wong (2024) JailbreakBench: an open robustness benchmark for jailbreaking large language models. In Advances in Neural Information Processing Systems 37 (NeurIPS 2024 Datasets and Benchmarks Track), External Links: Link Cited by: TABLE I, §VI. [27] M. Mazeika, L. Phan, X. Yin, A. Zou, Z. Wang, N. Mu, E. Sakhaee, N. Li, S. Basart, B. Li, D. Forsyth, and D. Hendrycks (2024) HarmBench: a standardized evaluation framework for automated red teaming and robust refusal. In Proc. of the 41st Int. Conf. on Machine Learning (ICML), PMLR 235, p. 35181–35224. Cited by: TABLE I, §VI. [28] J. Zhu, S. He, P. He, J. Liu, and M. R. Lyu (2023) Loghub: a large collection of system log datasets for AI-driven log analytics. In Proceedings of the 34th IEEE International Symposium on Software Reliability Engineering (ISSRE), p. 355–366. External Links: Link Cited by: TABLE I, §VI.

Instant research discovery