---
title: 'AI-Infra-Guard: Securing AI Actions'
url: https://www.emergentmind.com/topics/ai-infra-guard
type: topic
---

# AI-Infra-Guard: Securing AI Actions

Searching arXiv for recent papers on AI infrastructure guardrails, runtime validation, agent security, and guard layers.
AI-Infra-Guard denotes an infrastructure-level safeguarding layer that mediates between AI computation and consequential effects on external systems. In the cited literature, that layer appears in multiple forms: a mandatory runtime validation envelope for autonomous telecom control decisions, a tool-invocation policy enforcer for LLM agents, a security-first middleware for Model Context Protocol integrations, a 3D-integrated hardware safety layer for edge AI, a multi-role dependability orchestrator for cyber-physical systems, and graph-level containment for malicious propagation in multi-agent systems [2607.02210]. This suggests AI-Infra-Guard is best understood not as a single product or standard, but as a family of architectures that intercept, score, constrain, validate, and log AI-driven actions before those actions alter infrastructure, tools, data, or other agents.

## 1. Historical emergence and problem setting

The concept arises from a common failure mode across otherwise distinct AI deployment settings: models and agents increasingly operate in the critical path of real systems, yet their outputs are often trusted too early. In autonomous telecommunications, the problem is explicit. At **Autonomous Network Levels 4–5**, AI agents directly control parameter tuning, resource allocation, cell activation or deactivation, and policy actions in near real time, while existing 3GPP mechanisms such as `AIMLInferenceEmulationFunction` provide pre-deployment sandboxing only; there is no standardized runtime gate between an `AIMLInferenceFunction` output and a live network action [2607.02210]. The motivating failure is not merely a bad prediction but an unvetted infrastructure mutation, exemplified by an energy-saving agent deactivating the only cell covering an EMERGENCY slice.

An analogous shift appears in tool-using LLM agents. AgentGuardian characterizes the primary risk as misuse of legitimate tools rather than compromise of the raw LLM itself: filesystem, email, network, and command-execution tools can be chained in malicious or hallucination-driven ways unless an external governance layer constrains both control flow and tool arguments [2601.10440]. MCP Guardian makes the same point at the protocol layer. MCP standardizes connectivity between AI applications and tool servers, but does not itself standardize authentication, authorization, rate limits, audit logging, tracing, or input/output security checks, leaving a broad attack surface that includes tool poisoning, tool shadowing, installer spoofing, command injection, token theft, and rug pulls [2504.12757].

In cyber-physical and edge settings, the same architectural gap appears in more tightly coupled form. DURA-CPS argues that classical V&V methods struggle with the scalability, coverage, and unpredictability of AI behaviors in closed-loop CPS, motivating a persistent assurance framework that supervises an AI component in context rather than only offline [2506.06381]. The 3D Guard-Layer pushes the idea into hardware: the safeguard is no longer only a software wrapper but a physically distinct safety compute layer co-packaged with the primary AI, with direct access to sensor telemetry, model I/O streams, and failover control lines [2511.08842].

Across these settings, the common target is not “unsafe text” in isolation but **unsafe actuation**: tool calls, network changes, model serving requests, CPS control actions, or propagated multi-agent decisions. This suggests that AI-Infra-Guard is fundamentally about governing the transition from model output to system effect.

## 2. Core architectural motifs

A recurrent architectural principle is the creation of a **mandatory chokepoint** through which AI-originated actions must pass. In telecom Guard Rail Validation, the runtime pipeline is explicitly: **AgentDecision → CriticalityEvaluation → GraduatedValidation → Enforcement**, with additional conflict resolution and conformance logging around the validation stages [2607.02210]. AgentGuardian places the chokepoint at the tool boundary: a tool call is allowed only if the control-flow path to the tool is valid in a learned Control Flow Graph and the tool input plus numeric attributes match one of the learned cluster-derived rules [2601.10440]. MCP Guardian realizes the same pattern by overriding `invoke_mcp_tool`, inserting authentication, rate limiting, WAF scanning, logging, and tracing before any MCP tool execution [2504.12757].

The guarded layer may be software, middleware, orchestration, or hardware, but its functions are structurally similar.

| Instantiation | Protected boundary | Primary mechanism |
|---|---|---|
| GRV | Inference output → network action | Criticality scoring and graduated validation |
| AgentGuardian | Planned tool call → tool execution | CFG + per-tool access-control policy |
| MCP Guardian | MCP request → tool invocation | Auth, rate limiting, WAF, logging |
| 3D Guard-Layer | Edge AI I/O and telemetry → failover/control | Dedicated safety compute layer |
| DURA-CPS | AI planner output → CPS action | Multi-role orchestration and recovery planning |

Two additional motifs recur. First, **role separation**: GRV distinguishes `PRIMARY` agents from `VALIDATOR` agents whose outputs never directly translate to actions [2607.02210]; DURA-CPS decomposes assurance into Generator, SafetyMonitor, SecurityAssessor, FaultInjector, PerformanceOracle, and RecoveryPlanner [2506.06381]. Second, **defense in depth**: MCP Guardian combines token validation, rate limiting, WAF scanning, and logging rather than relying on a single detector [2504.12757], while the 3D Guard-Layer combines behavioral monitoring, hardware monitoring, shadow AI models, failover, and compliance monitoring in one co-located subsystem [2511.08842].

This architectural convergence implies that AI-Infra-Guard is less a specific algorithm than a systems pattern: insert a privileged mediation layer, separate production from validation roles, and make every consequential action auditable.

## 3. Risk scoring, anomaly modeling, and decision policies

A major line of work within AI-Infra-Guard formalizes how to convert an AI output into a risk-bearing object that can be accepted, blocked, delayed, reduced in scope, or escalated. GRV provides the clearest runtime formulation. It assigns each decision a weighted multi-dimensional score over **Action Scope**, **Action Type**, **Service Criticality**, **Agent Autonomy**, **Reversibility**, and **Temporal Pattern**, and computes
$$
S = \sum_{i=1}^{6} w_i \cdot d_i .
$$
A hard invariant sets all `READ` actions to `LOW`; otherwise thresholds in `GuardRailPolicy` map $S$ into `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`, which in turn trigger execute-with-logging, bounds checking, single-validator review, or multi-agent consensus [2607.02210]. The temporal dimension is especially important because it scores frequent updates, oscillation, and burst behavior over a sliding window, thereby capturing attacks that are only visible across time rather than in a single action.

AgentGuardian uses a different but related formalism. For tool \(T\), its runtime policy is
$$
ACP_T(x,a,\text{CF}) = (\text{CFG path to }T\text{ is allowed given CF}) \wedge \bigvee_{k=1}^{K_T} R_{T,k}(x,a),
$$
where each \(R_{T,k}\) is a cluster-derived rule over textual inputs \(x\) and numeric attributes \(a\) such as `max_input_tokens`, `max_output_tokens`, `min_hour`, `max_hour`, `max_idle_time`, and `max_processing_time` [2601.10440]. In other words, the policy joins **structural validity** with **input conformity**. A tool call may be blocked because it is the wrong next action even if its arguments look benign, or because its arguments violate learned patterns even if the tool is otherwise permitted in that position.

Trajectory Guard extends the scoring problem from single tool calls to full action plans. It models a task \(T\) and trajectory \(\tau = \{s_1,\dots,s_n\}\) with a Siamese Recurrent Autoencoder and trains with the hybrid loss
$$
\mathcal{L} = \mathcal{L}_{\text{contrastive}} + \alpha \cdot \mathcal{L}_{\text{reconstruction}},
$$
so that anomaly detection captures both “wrong plan for this task” and “malformed plan structure” [2601.00516]. The paper reports F1-scores of **0.88–0.94** on balanced sets, recall of **0.86–0.92** on imbalanced external benchmarks, and **32 ms** inference latency, **17–27$\times$ faster than LLM Judge baselines**, which makes synchronous plan screening operationally plausible [2601.00516].

At the network-query level, FlowGuard replaces identity-bound monitoring with density estimation. A Continuous Normalizing Flow trained on legitimate data computes
$$
\log p_1(x) = \log p_0(z_0) - \int_0^1 \mathrm{tr}\left(\frac{\partial f_\theta}{\partial z}(z_t,t)\right) dt,
$$
and flags low-likelihood queries as out-of-distribution before they reach the IDS [2606.03430]. The rationale is that synthetic queries used in data-free model stealing occupy a lower-dimensional manifold than real traffic, so likelihood under the learned flow is systematically lower.

Taken together, these systems suggest that AI-Infra-Guard relies on three broad scoring paradigms: **policy-weighted criticality**, **structure-plus-input conformance**, and **distributional anomaly estimation**. The choice depends on whether the guarded object is a control action, a tool invocation, a plan trajectory, or an external query.

## 4. Tool governance, multi-agent control, and propagation containment

Tool governance is the most direct operational expression of AI-Infra-Guard. AgentGuardian learns policies during a staging phase by logging prompts, internal “thoughts”, tool calls, tool inputs and outputs, timing, and token usage; it then enforces those policies at runtime by intercepting tool invocation events through LiteLLM custom feedback hooks [2601.10440]. Its evaluation on two real-world applications reports aggregate **FAR = 0.1 (2/20)**, **FRR = 0.1 (8/80)**, and **BEFR = 0.075 (6/80)**, while also showing that many benign failures are actually orchestrator hallucinations rather than pure policy errors [2601.10440].

MCP Guardian addresses a broader integration substrate. It wraps MCP communication with token-based authentication, per-token rate limiting, regex-based WAF scanning, request/response logging, and optional OpenTelemetry tracing, all inside `guarded_invoke_tool()` [2504.12757]. In a local VM test over a weather MCP server, the paper reports baseline median latency of **≈ 25.1 ms** and guarded median latency of **≈ 28.9 ms**, with **absolute overhead ≈ 3–4 ms** and **relative overhead ≈ 10–15%**, alongside explicit blocking of unauthorized tokens, malicious payloads such as `rm -rf /`, and rate-limit violations [2504.12757]. A plausible implication is that always-on inline guarding is feasible for tool calls, at least when LLM latency dominates end-to-end execution.

Once agents interact with one another rather than only with tools, propagation itself becomes the guarded object. INFA-Guard introduces a tri-partition of **attack agents**, **infected agents**, and **benign agents**, formalizing infected agents as those that were initially safe but become compromised across iterations [2601.14667]. Its GNN-based detector uses time-indexed reply and edge embeddings, topology-aware loss, and post-adaptation over graph distance and infection trends to localize both attackers and infected ranges. Remediation is dual: attackers are replaced via a replacement mapping \(RP\), while infected replies are sanitized through a guard LLM \(LM(\cdot)\), thereby preserving topology while suppressing propagation. The paper reports state-of-the-art performance, with average **Attack Success Rate** reduced by **33%** [2601.14667].

DURA-CPS offers a related perspective for cyber-physical environments. Its multi-role orchestrator continuously evaluates a Generator or AI Under Test inside simulation using SafetyMonitor, SecurityAssessor, FaultInjector, PerformanceOracle, and RecoveryPlanner, and logs dependability metrics over iterations [2506.06381]. In its autonomous-vehicle case study, the overall **SafetyMonitor “unsafe” flag rate** is **38.9%** and the **overall collision rate** is **8.9%**, while recovery via `emergency_brake` prevents a majority of unsafe proposals from becoming collisions [2506.06381]. This suggests that AI-Infra-Guard can function not only as a direct runtime gate but also as a persistent assurance loop around an AI controller.

## 5. Domain-specific instantiations and deployment strata

The deployment form of AI-Infra-Guard is strongly shaped by latency, topology, and physical coupling.

In O-RAN telecom, GRV is split across two tiers. The **Non-RT RIC / SMO** hosts full GRV for rApps producing A1 policies or O1 configuration changes, with all six criticality dimensions, validator agents, M-of-N consensus, synchronous temporal pattern detection, and cross-rApp conflict coordination. The **Near-RT RIC** uses a latency-constrained GRV that performs only local bounds checking from a policy cache, does not call external validators synchronously, escalates out-of-bounds or unrecognized actions to the Non-RT RIC via A1, and runs temporal anomaly detection asynchronously as a compensating control [2607.02210]. This yields a general deployment principle: rich guardrails belong in higher-latency management layers, while fast control loops use lighter local checks plus escalation.

At the edge, 3D Guard-Layer realizes AI-Infra-Guard as silicon packaging. It defines a separate hardware layer or interposer containing a **Behavioral Monitoring Agent**, **Hardware Monitoring Agent**, **Shadow AI Model Agent**, **Failover System Agent**, and **Regulatory Compliance Agent**, connected to primary AI layers through TSVs, micro-C4, or 2.5D interposer routing [2511.08842]. Reported **TSV area overhead** is **~0.00–0.05%** for **10K TSV** and **~0.01–0.47%** for **100K TSV**, while **manufacturing cost overhead** is **~3.75%** for high-end systems and **up to ~60%** for low-end cheap devices [2511.08842]. The paper does not provide explicit runtime benchmarks, but its deployment argument is that overhead is mainly manufacturing and area rather than runtime slowdown.

In smart-city IoT, the guard role is distributed across sensors, edge, gateways, fog, cloud, and a Command and Control Centre. The paper on smart city command-and-control centers presents an LSTM-RNN for traffic-surge detection over `Fwd Pkt Len Mean`, using one LSTM layer with **10 units**, **Dropout(0.2)**, and a linear output head, and reports test **MSE ≈ \(3.4526 \times 10^{-6}\)** versus a baseline **MSE ≈ \(3.428 \times 10^{-5}\)** [2108.00003]. Here AI-Infra-Guard is operationalized as cyber-defense analytics over event logs and traffic streams rather than as per-decision validation, but the infrastructural role is similar: centralized monitoring, anomaly prediction, and operator-facing mitigation.

In multimodal conversational settings, Llama Guard 3 Vision places the guard at the prompt and response boundary for image-understanding conversations, while Llama Guard 3-1B-INT4 shows that a compact safeguard can run on a commodity Android mobile CPU with **at least 30 tokens per second** and **time-to-first-token of 2.5 seconds or less**, at **440MB** model size [2411.17713]. This suggests a further deployment stratum: some AI-Infra-Guard functions can move onto edge devices, yielding local moderation, privacy advantages, and reduced backend exposure.

## 6. Evaluation landscape, limitations, and unresolved questions

The empirical record shows that guard layers can be highly effective, but it also makes clear that they are not equivalent to formal guarantees. AgentRedBench reports that across an eight-model panel over **215** subtle underspecified-authorization scenarios across **24** enterprise integrations, no-guard ASR ranges from **32%** to **81%**, while AGENTREDGUARD cuts panel ASR from **69.9%** to **2.4%** at **0.37% false-positive rate**, outperforming open-source baselines on both axes [2606.02240]. A separate comparative study of commercial and proprietary guardrails reports that DKnownAI Guard achieves **96.5% recall** and **90.4% TNR** on AI agent security scenarios, ranking first among the evaluated systems [2604.24826]. These results indicate that integration-aware and agent-specific guards can substantially outperform general chat-style moderation.

Yet the limitations are equally consistent across the literature. GRV explicitly states that it provides **no formal safety guarantees**, has **no empirical latency/overhead evaluation yet**, currently handles **direct conflict detection only**, and degrades at `HIGH` and `CRITICAL` levels if diverse validators are unavailable [2607.02210]. AgentGuardian depends on a **clean staging phase**, can overgeneralize or undergeneralize, and is sensitive to orchestrator quality; replacing GPT-4.1 with **gpt-4o-mini** caused **24 hallucination-induced failures** for the Knowledge Assistant and **13** for IT Support [2601.10440]. MCP Guardian notes that regex-based WAF scanning is shallow, centralized local logging is not scalable, and compromised tool code is still out of scope for a middleware-only defense [2504.12757]. FlowGuard is robust to distributed Sybil-style model-stealing attacks, but currently focuses on data-free attacks and assumes representative legitimate data for density modeling [2606.03430].

A common misconception is that a guardrail layer can replace offline validation, certification, or primary-model alignment. The literature rejects that view. GRV is described as a **pragmatic runtime layer** rather than a substitute for offline model validation [2607.02210]; DURA-CPS is simulation-centric and intended to support iterative assurance rather than provide a complete runtime proof of safety [2506.06381]; the 3D Guard-Layer assumes the guard hardware itself is trusted and does not deeply analyze supply-chain attacks on the guard [2511.08842]. This suggests that AI-Infra-Guard is most defensible when treated as one layer in a larger assurance stack that also includes model evaluation, sandboxing, isolation, access control, monitoring, and human override.

A second unresolved issue is standardization. Several papers explicitly describe their frameworks as blueprints or templates that generalize beyond the original domain: GRV from telecom to critical infrastructure, AgentGuardian from agent staging traces to infrastructure governance, MCP Guardian from MCP to generic tool middleware, and FlowGuard from energy IDS to other high-value AI services [2607.02210]. This suggests the field is converging on a set of recurring abstractions—runtime interception, policy-driven scoring, validator diversity, conflict arbitration, structured logging, and topology-aware remediation—but those abstractions remain distributed across domain-specific implementations rather than consolidated into a single standard.

In that sense, AI-Infra-Guard currently names an architectural doctrine: every AI-mediated transition from inference to effect should be treated as a security, safety, and governance boundary. The research record shows multiple viable realizations of that doctrine, but also indicates that the hardest open problems remain cross-domain semantics, adaptive adversaries, threshold calibration, topology-aware false-positive control, and the integration of runtime guardrails with deeper assurance methods.

Source: https://www.emergentmind.com/topics/ai-infra-guard