Recent advancements in AI agents powered by Large Language Models (LLMs) have been remarkable. A notable case on Hacker News, “Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks,” highlighted how applying appropriate Guardrails can dramatically increase the success rate of specific tasks, often more effectively than simply increasing model parameter count.

For our ongoing projects, ZeroClaw and those based on MCP (Model Context Protocol), agent reliability is paramount. In this post, we will explore the concept of Forge, an open-source guardrail framework, and introduce practical methods for integrating it into our existing MCP architecture to ensure agent stability.

Problem Definition: The Dilemma of Autonomy

Granting agents more autonomy increases the risk of unexpected behavior. For instance, when an MCP request is made to generate a blog post, an agent might attempt to execute system commands or call unauthorized APIs.

Our previous implementation of [blog-api-server] attempted to mitigate this through prompt engineering and basic JSON schema validation, but these proved insufficient in complex multi-agent environments. To address this, we decided to introduce an L1 Guardrail layer for pre-filtering inputs and outputs.

Solution: Applying the Guardrails Pattern

As demonstrated by Forge, the key to improving agent task success rates (53% → 99%) lies in pre-execution validation. We designed a structure where a middleware layer validates the agent’s responses before they are delivered to the user or used to execute tools.

Architecture Overview

A Validator layer is placed between the existing MCP client and the LLM to perform the following:

1. Input Validation: Checks if user requests violate system policies (e.g., filtering for aggressive prompts).
2. Output Validation: Verifies if LLM-generated JSON or function call arguments conform to the schema.

Practical Code Example: Implementing Safeguards in Rust

Let’s implement a lightweight output validator within the Rust environment of ZeroClaw. This example uses serde and regex to safely wrap code execution commands generated by the LLM, without complex external libraries.

1. Implementing Validation Logic

First, here’s a simple validator to determine if a command generated by the agent is safe.

use regex::Regex;
use serde::{Deserialize, Serialize};

// Structure for commands an agent might generate
#[derive(Debug, Serialize, Deserialize)]
struct AgentCommand {
    tool_name: String,
    parameters: String,
}

pub struct Guardrail;

impl Guardrail {
    // Simple example for filtering dangerous strings
    fn is_dangerous(input: &str) -> bool {
        let dangerous_patterns = vec!["rm -rf", "sudo", "eval", "__import__"];
        dangerous_patterns.iter().any(|&pat| input.contains(pat))
    }

    // Validation logic before command execution
    pub fn validate_command(cmd: &AgentCommand) -> Result<&AgentCommand, String> {
        // 1. Check tool name against a whitelist
        let allowed_tools = vec!["blog_post", "search", "read_file"];
        if !allowed_tools.contains(&cmd.tool_name.as_str()) {
            return Err(format!("Attempt to use disallowed tool: {}", cmd.tool_name));
        }

        // 2. Check for dangerous keywords within parameters
        if Self::is_dangerous(&cmd.parameters) {
            return Err("Potentially dangerous command included in parameters.".to_string());
        }

        // 3. If safe, approve the command
        Ok(cmd)
    }
}

2. Integrating into the Agent Loop

Now, we connect the validator to the request processing loop of the MCP server. After the agent generates a response, it must pass through the Guardrail before the actual system executes it.

// Hypothetical agent execution function
fn execute_agent_task(llm_output: &str) -> Result<String, String> {
    // 1. Parse LLM output (in reality, this would involve JSON parsing, etc.)
    // We assume parsing is successful here for simplicity.
    let command = AgentCommand {
        tool_name: "blog_post".to_string(),
        parameters: "title: 'Hello World'".to_string(),
    };

    // 2. Before guardrail passage
    println!("[System] LLM response received: {}", command.tool_name);

    // 3. Execute guardrail validation
    let safe_command = Guardrail::validate_command(&command)?;

    // 4. Execute validated command
    println!("[System] Executing safe command...");
    // Actual tool execution logic (e.g., calling the blog API)
    Ok("Post successfully created.".to_string())
}

fn main() {
    // Normal case
    match execute_agent_task("valid_response") {
        Ok(msg) => println!("Success: {}", msg),
        Err(e) => println!("Blocked: {}", e),
    }

    // Simulate an abnormal case
    let malicious_cmd = AgentCommand {
        tool_name: "system_shell".to_string(), // Not in whitelist
        parameters: "rm -rf /".to_string(),
    };

    match Guardrail::validate_command(&malicious_cmd) {
        Ok(_) => println!("Error: Hacker has infiltrated!"),
        Err(e) => println!("Protected: {}", e), // "Protected: Attempt to use disallowed tool: system_shell"
    }
}

Benefits and Outlook

By establishing this L1 defense line, we gain the following advantages:

1. Improved Stability: Similar to the Forge case, even 8B models can be utilized safely, reducing inference costs.
2. Enhanced Transparency: Logs clearly indicate why an agent rejected a specific task.
3. Maintainability: Security policy changes only require modifications to the Guardrail module.

Moving forward, the ZeroClaw project plans to integrate this validation logic into an asynchronous runtime, enabling real-time safety monitoring during inter-agent communication ([Discord MCP], [Cloud Monitor]).

Instead of solely focusing on improving model performance, the key to deploying AI agents in actual production environments will lie in how we design system-level safeguards like these.

This article was written with reference to architectural design documents related to ZeroClaw and MCP.