AI-Infra-Guard: Securing AI Actions

• AI-Infra-Guard is an infrastructure-level safeguarding layer that intercepts, scores, validates, and logs AI-driven actions to prevent unsafe effects.
• It integrates diverse techniques such as runtime validation, role separation, and multi-layer defense to manage risk across telecom, CPS, and edge applications.
• Practical implementations include tool policy enforcers, hardware safety layers, and graph-level containment to enhance security and dependability in AI systems.

Searching arXiv for 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 (Sharma, 2 Jul 2026). 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 (Sharma, 2 Jul 2026). 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 (Abaev et al., 15 Jan 2026). 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 (Kumar et al., 17 Apr 2025).

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 (Srinivasan et al., 4 Jun 2025). 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 (Kurshan et al., 11 Nov 2025).

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 (Sharma, 2 Jul 2026). 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 (Abaev et al., 15 Jan 2026). 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 (Kumar et al., 17 Apr 2025).

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 (Sharma, 2 Jul 2026); DURA-CPS decomposes assurance into Generator, SafetyMonitor, SecurityAssessor, FaultInjector, PerformanceOracle, and RecoveryPlanner (Srinivasan et al., 4 Jun 2025). Second, defense in depth: MCP Guardian combines token validation, rate limiting, WAF scanning, and logging rather than relying on a single detector (Kumar et al., 17 Apr 2025), while the 3D Guard-Layer combines behavioral monitoring, hardware monitoring, shadow AI models, failover, and compliance monitoring in one co-located subsystem (Kurshan et al., 11 Nov 2025).

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 (Sharma, 2 Jul 2026). 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 (Abaev et al., 15 Jan 2026). 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” (Advani, 2 Jan 2026). 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$S$0 faster than LLM Judge baselines, which makes synchronous plan screening operationally plausible (Advani, 2 Jan 2026).

At the network-query level, FlowGuard replaces identity-bound monitoring with density estimation. A Continuous Normalizing Flow trained on legitimate data computes

$S$1

and flags low-likelihood queries as out-of-distribution before they reach the IDS (Schwarzer et al., 2 Jun 2026). 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 (Abaev et al., 15 Jan 2026). 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 (Abaev et al., 15 Jan 2026).

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() (Kumar et al., 17 Apr 2025). 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 (Kumar et al., 17 Apr 2025). 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 (Zhou et al., 21 Jan 2026). 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 $S$2, while infected replies are sanitized through a guard LLM $S$3, thereby preserving topology while suppressing propagation. The paper reports state-of-the-art performance, with average Attack Success Rate reduced by 33% (Zhou et al., 21 Jan 2026).

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 (Srinivasan et al., 4 Jun 2025). 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 (Srinivasan et al., 4 Jun 2025). 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 (Sharma, 2 Jul 2026). 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 (Kurshan et al., 11 Nov 2025). 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 (Kurshan et al., 11 Nov 2025). 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 ≈ $S$4 versus a baseline MSE ≈ $S$5 (S et al., 2021). 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 (Fedorov et al., 2024). 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 (Dingeto et al., 1 Jun 2026). 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 (Li et al., 27 Apr 2026). 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 (Sharma, 2 Jul 2026). 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 (Abaev et al., 15 Jan 2026). 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 (Kumar et al., 17 Apr 2025). 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 (Schwarzer et al., 2 Jun 2026).

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 (Sharma, 2 Jul 2026); DURA-CPS is simulation-centric and intended to support iterative assurance rather than provide a complete runtime proof of safety (Srinivasan et al., 4 Jun 2025); the 3D Guard-Layer assumes the guard hardware itself is trusted and does not deeply analyze supply-chain attacks on the guard (Kurshan et al., 11 Nov 2025). 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 (Sharma, 2 Jul 2026). 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.