PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Georgios Koutidis, Nikolaos Kekatos, Tom Nianios, Alexios Lekidis

arXiv:2610.09906v1cs.CRcs.AIcs.CL

TL;DR

SOCs face high alert volume and limited analyst capacity, while LLM-driven remediation introduces risks from hostile telemetry and privileged actions. This paper combines a constrained-action SIEM/XDR control plane with a NeMo-Guardrails proxy; the proxy raises injection recall from 25.0% to 94.5% at 0.1% FPR, and red-team tests confirm observed action failures are contained. The measured rail latency keeps inline control out of scope, and OT applicability remains architectural rather than evaluated on field devices.

  • Problem

    SOCs face overwhelming false-positive or low-value alerts, and analysts cannot keep pace with correlated incidents as junior-tier turnover thins expertise.

    Source: §I · p. 1

  • Method

    The architecture combines a SIEM/XDR control plane that limits the LLM to validated, templated intents with a NeMo-Guardrails proxy screening prompt and completion paths.

    Source: §I · p. 1, C. Smart manager, thin agent · p. 3, B. Rails · p. 3

  • Results

    25.0% to 94.5% injection recall at 0.1% FPR; a live red-team exercise confirmed that target imprecision and intent drift were contained before commands crossed the trust boundary.

    Source: §I · p. 2

  • Takeaways & Limitations

    The closed intent vocabulary and argument validator bound the observed LLM failure modes before commands cross the trust boundary.

    Source: §VIII · p. 6

    Measured rail latency keeps inline use out of scope, and OT applicability remains architectural because evaluation did not use real OT protocols or field devices.

    Source: §VII · p. 5

Abstract

from arXiv · show

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.

I. INTRODUCTION

SOCs face high alert volume and limited analyst capacity, while LLM-driven response exposes hostile telemetry, privileged actions, and sensitive logs to new risks. The paper proposes a constrained-action SIEM/XDR control plane and a NeMo-Guardrails proxy, reporting improved injection recall and red-team containment of observed failures.

I. INTRODUCTION

  • SOCs face overwhelming false-positive or low-value alerts and analysts unable to keep pace with correlated incidents as junior-tier turnover thins expertise.Source: §I · p. 1
  • Hostile telemetry, privileged remediation actions, and sensitive log contents make naive LLM integration vulnerable to manipulation, outages, and data exfiltration.In OT and critical-infrastructure settings, a wrong action can affect sensors, relays, or controllers.Source: §I · p. 1
  • The action-bounded SIEM/XDR control plane confines the LLM to closed intents, expands them into validated OS-specific templates, and uses thin endpoint agents to execute commands.The split removes the LLM’s ability to synthesize executable strings.Source: §I · p. 1
  • The NeMo-Guardrails proxy wraps the SOC analyst’s LLM with input rails against prompt injection and output rails against PII and infrastructure-data leakage, plus a topical dialog rail.It reuses default rail primitives and can be enabled with a configuration change.Source: §I · pp. 1–2
  • 25.0% to 94.5% injection recall at 0.1% FPR; the live red-team exercise also found target imprecision and intent drift contained before commands crossed the trust boundary.The evaluation used default-configured NeMo Guardrails against a released SOC-specific adversarial corpus.Source: §I · p. 2

II. RELATED WORK

Prior work covers SOC alert triage, agentic prompt-injection threats, and guardrail primitives, but the paper positions end-to-end action containment as its contribution. It also connects the closed action surface to restricted-action principles in IT/OT standards.

LLM-driven SOC response

  • Existing LLM-driven SOC response examples are not reported to constrain the model’s action surface or test robustness on adversarial telemetry.The passage names Microsoft Copilot for Security’s Guided Response and APPATCH as examples.Source: §II · p. 2

Agentic AI and prompt injection

  • Telemetry manipulation, tool-call taint, and destructive-action coercion are established agentic threats that the paper treats as design constraints with corresponding gates.The passage cites AI Oops, Agent-Fuzz, sudo rm -rf, a SoK, and AgentDojo.Source: §II · p. 2

Guardrail primitives

  • Input/output gates provide guardrail building blocks, while the paper distinguishes its contribution as end-to-end containment that bounds actions even if an injection succeeds.The passage names perplexity detection [16], SmoothLLM, backtranslation, Llama Guard [19], Presidio, and OWASP LLM Top-10.Source: §II · p. 2

IT/OT standards

  • NIST SP 800-82r3 and IEC 62443 prescribe restricted action surfaces for industrial response, which the paper’s closed intent vocabulary instantiates for an LLM-driven loop.Source: §II · p. 2
  • Runtime verification also pursues deterministic bounding of untrusted components in edge-IoT settings.Source: §II · p. 2

III. THREAT MODEL AND SYSTEM ARCHITECTURE

The threat model assumes an attacker can influence application logs and monitored-service request content, but not the SIEM manager, LLM, or operator workstation. The architecture mediates telemetry through correlated incidents, guardrails, and constrained execution; the evaluated control plane is host-based.

III. THREAT MODEL AND SYSTEM ARCHITECTURE

  • The attacker may control an application log source and request content reaching monitored services, pursuing telemetry injection, benign-asset remediation, or reply-based data exfiltration.The LLM provider is semi-trusted and must not receive unredacted PII or infrastructure data; its output must not be executed verbatim.Source: §III · p. 2
  • The pipeline collects host events, shapes correlated incidents, screens prompts and completions through guardrails, and maps recommended intents to whitelisted OS-specific commands.Source: §III · p. 2

IV. SIEM/XDR WITH GUAR​DRAILED ACTIVE RESPONSE

  • The evaluated SIEM/XDR control plane follows the Wazuh/OSSEC host-based HIDS pattern; NDR and ITDR sources are not exercised in this study.Source: §IV · p. 2

A. Telemetry pipeline

The telemetry pipeline collects endpoint events and correlates them into incidents, while the SOC-analyst agent reasons over incident context and emits bounded action intents rather than commands.

A. Telemetry pipeline

  • Endpoint agents collect process, log, file-integrity, registry, and active-response events, then the manager correlates them into incidents with asset identity, derivable MITRE ATT&CK tactics, and rule-engine severity.Agents cover Linux, Windows, macOS, and Linux-based OT collectors; registration uses mTLS and steady-state messaging uses a TLS/AES-256-GCM WebSocket.Source: A. Telemetry pipeline · p. 2
  • Figure 1 depicts distrust boundaries and data forms, with raw attacker bytes progressively sanitized into a whitelisted command; the proxy blocks G1 and G3, while the validator blocks G2.Source: Figure 1 · p. 3

B. SOC-analyst LLM agent

  • The SOC-analyst service runs a ReAct loop bounded by iterations and wall-clock time, using incident context and a redacted log excerpt to produce analysis and action intents.The default backend is a locally served 14B-parameter open-weights model with low sampling temperature.Source: B. SOC-analyst LLM agent · p. 3
  • The analyst emits intents from a closed vocabulary, such as block IP or kill process, with arguments but no execution instructions.Source: B. SOC-analyst LLM agent · p. 3

C. Smart manager, thin agent

The manager constrains remediation through validated templates and a thin agent, while a NeMo Guardrails proxy wraps the SOC-analyst LLM. The design keeps command syntax outside the LLM’s control and screens proxy traffic before it reaches the caller.

C. Smart manager, thin agent

  • The manager validates LLM-supplied arguments against type-specific patterns before inserting them into OS-specific command templates.Linux, Windows, and macOS use their native firewall facilities.Source: C. Smart manager, thin agent · p. 3
  • Before a command leaves the trust boundary, the intent must be in a closed vocabulary and the rendered command must pass binary-whitelist and metacharacter checks.The agent aborts execution when argument strings match shell metacharacters or destructive patterns.Source: C. Smart manager, thin agent · p. 3
  • The engine polls correlated alerts with timeouts, retries, audit trails, batch ceilings, and cooldowns.Retries use exponential backoff; batch ceilings and per-(rule, target) cooldowns limit flooding.Source: C. Smart manager, thin agent · p. 3

V. NEMO GUARDRAILS LLM PROXY

  • The SOC-analyst service places a NeMo Guardrails proxy between itself and the model backend, with an input rail and an output rail screening the request flow.The input rail can block a request before the main LLM is invoked, and the output rail screens the completion before it returns to the caller.Source: §V · p. 3, Figure 2 · p. 3

A. Proxy architecture

The proxy provides an OpenAI-compatible chat-completion endpoint that the SOC-analyst service can use by repointing its existing provider, without application code changes.

A. Proxy architecture

B. Rails

The rails screen incoming messages, outgoing completions, and off-task inputs; each self-check rail invocation is an LLM call.

B. Rails

  • Each self-check rail invocation is an LLM call, and Table I identifies 200 adversarial-corpus variants across sampled benchmark rows and SOC-specific transformation rows.Rows 1–3 are sampled from published benchmarks; rows 4–7 are SOC-specific transformations.Source: B. Rails · p. 3, Table I · p. 4
  • The input rail uses an LLM classifier to forward logs describing security events and block logs containing attacker directives.A blocked request receives a canned refusal, and the main LLM is never reached.Source: B. Rails · p. 3
  • The output rail screens completions for PII, infrastructure data, and content the model should have refused, blocking any hit from returning verbatim.Source: B. Rails · p. 3
  • A topical dialog flow refuses off-task inputs that pass the input self-check, such as jokes, weather, or chat.The passage says this flow fires rarely in production.Source: B. Rails · p. 4

C. Defaults and latency profile

The default rail prompts were not tuned to the evaluation corpus; SOC-specific changes are limited to input phrasing, output data categories, and a topical flow, while sequential calls increase latency.

C. Defaults and latency profile

  • The rail prompts were not hand-tuned to the adversarial evaluation corpus to avoid co-evolving an external baseline with the evaluation set.Source: C. Defaults and latency profile · p. 4
  • Customizations comprise SOC-specific input phrasing, infrastructure-data categories for the output rail, and a small topical flow.Source: C. Defaults and latency profile · p. 4
  • A blocked request costs one roundtrip, while a passed request costs three sequential calls and three round-trips compared with one for a bare call.The sequence is input, main LLM, then output.Source: C. Defaults and latency profile · p. 4

VI. PRELIMINARY EVALUATION

On a 200-variant adversarial corpus and 1,000 benign logs, the evaluation compares raw inference with NeMo Guardrails and tests cheaper front ends. The proxy improves injection recall, while latency and live-response tests expose operational trade-offs and show containment of observed action errors.

VI. PRELIMINARY EVALUATION

  • 94.5% proxy recall versus 25.0% raw recall came with 0.1% versus 0.0% FPR across 200 adversarial variants and 1,000 benign lines.Both endpoints shared the model, sampling parameters, and classification prompt; the guardrail layer was the only comparison variable.Source: Table II · p. 4, §VI · p. 4
  • Base64 recall rose 13.3%→100%, homoglyph 25%→95%, and zero-width 40%→100%, while NeMo recall remained 80% on HarmBench base prompts.The residual gap comprised ten mid-severity behavior requests judged ambiguous rather than adversarial.Source: Table III · p. 4, §VI · p. 4
  • Tier-0 caught all 50 augmented records at 0.00% FPR with zero LLM calls, raising proxy recall to 95.0% and reducing mean calls from 3.00 to 2.88.It did not reduce median latency because benign requests carry no marker; the gate is a recall-safe, zero-cost addition, not a latency fix.Source: §VI · pp. 4–5, Table IV · p. 5
  • Figure 3 shows NeMo latency separating into a ∼0.5 s blocked tail and a ∼10–15 s passed path, while raw inference stays near ∼0.3 s.The passed path traverses three sequential LLM calls; blocked inputs use one.Source: §VI · p. 4, Figure 3 · p. 5
  • Lightweight triage cut median latency to 0.18 s, a 78× reduction at 0.00% FPR, but recall fell to 58.0%; confirming benign verdicts restored 95.0% recall and erased the latency gain.The classifier silently forwards semantic jailbreaks in well-formed log fields.Source: §VI · p. 5
  • Across 54 alerts, 41 actions were emitted; validation rejected a metadata-derived T1059 target, while closed intents bounded T1078 drift, and all actions remained manual-only.The T1110 block-IP actions had correct intent and target, including on a spliced-injection alert; none of the 41 actions was dispatched.Source: §VI · p. 5

VII. DISCUSSION AND LIMITATIONS

The proxy’s sequential rails impose a substantial latency cost that excludes inline control, while the paper’s evidence and action scope leave important deployment boundaries for OT and richer remediation.

Latency vs. depth

  • 14.14 s median proxy latency on benign traffic makes inline control prohibitive; the paper instead places the loop on human-in-the-loop or delayed timelines.A cheaper classifier front-end trades recall for latency; the authors identify reducing rail cost as the recall-preserving route.Source: §VII · p. 5

Threats to validity

  • The proxy is an out-of-the-box baseline rather than a maximum-effort defense: its stock rail prompts were not co-evolved with the corpus, and SOC-tuned variants may improve results.Proposed variants include chain-of-thought self-checking, input-rail perturbation ensembling, and an output rail backed by Llama Guard [19].Source: §VII · p. 5

Other limitations

  • Multi-turn injections across log lines are not modelled, and richer remediation such as patching or configuration rollback requires a wider whitelist or human approval.The proxy evaluates requests independently; the system models human approval as a configurable action mode.Source: §VII · p. 5

Applicability to OT and critical infrastructure

  • The OT fit is architectural, not experimentally validated: evaluation uses host and web telemetry, leaving live ICS/SCADA actions for future work.The proposed manager-and-agent topology is presented as compatible with OT deployments, but not tested on real OT protocols or field devices.Source: §VII · p. 5

Reproducibility

  • The released evaluation artifacts include deterministic sampling and augmentation code, provenance, the harness, and pre-filter and cascade runners with result CSVs.Pinned model digests and package versions mitigate silent upstream re-tags; reported latencies still depend on the accelerator.Source: §VII · pp. 5–6

Ethical considerations

  • Deployment risk remains if the guardrail layer is omitted or the whitelist is permissive, so operators retain responsibility for configuration.The paper says the closed vocabulary, argument validator, and cooldown enforcement bound this risk by design.Source: §VII · p. 6

VIII. CONCLUSION

The conclusion presents a two-layer constrained-action stack for narrowing the LLM’s input, output, and action surfaces. Its proxy improves injection recall, while the red-team exercise confirms observed failures are contained before command dispatch; measured latency keeps inline control out of scope.

VIII. CONCLUSION

  • The two-layer stack combines a SIEM/XDR control plane with a closed, argument-validated intent vocabulary and a NeMo Guardrails proxy that screens prompt and completion paths.The conclusion reports proxy recall rising from 25.0% to 94.5% at 0.1% FPR over 200 adversarial variants and 1,000 benign log lines; red-teaming confirmed target imprecision and intent drift were contained.Source: §VIII · p. 6
Loading 2610.09906v1…