Security on Yarang's Tech Lair

[MicroVM] Building Isolated Sandboxes with Firecracker

Sat, 27 Jun 2026 09:01:26 +0900

[MicroVM] Building Isolated Sandboxes with Firecracker

MicroVM technology is gaining attention recently. Traditional containers (like Docker) share the kernel with the host, making them not entirely secure in terms of isolation. On the other hand, MicroVMs like AWS’s Firecracker provide lightweight virtual machines, allowing you to achieve both “container speed” and “VM security.”

In this article, we will practically introduce how to safely execute untrusted code using Firecracker MicroVM, a key consideration in the communication protocol design for ZeroClaw, a Rust-based agent runtime, with accompanying code examples.

Why MicroVM?

In the past development of blog API servers or MCP (Model Context Protocol) clients, container environments were primarily used. However, security becomes even more critical in multi-agent systems or environments that need to execute external code.

Single Process Isolation: Each MicroVM has an independent kernel space.
Fast Boot: Boot times in milliseconds offer speeds similar to containers.
Resource Limits: CPU and memory usage can be strictly controlled.

Prerequisites

To follow this guide, you will need a Linux environment (with KVM enabled) and the Rust toolchain. Firecracker runs on Linux KVM (Kernel-based Virtual Machine).

# Check KVM permissions
ls -la /dev/kvm
# Add to group (if you don't have permissions)
sudo usermod -aG kvm $USER

1. Downloading and Preparing Firecracker

Firecracker is provided as a single binary, making deployment very simple.

cd /tmp
curl -L -o firecracker-v1.9.1 https://github.com/firecracker-microvm/firecracker/releases/download/v1.9.1/firecracker-v1.9.1-x86_64
chmod +x firecracker-v1.9.1
mv firecracker-v1.9.1 firecracker

2. Creating a Root Filesystem for MicroVM Boot

To run a MicroVM, you need a simple Linux kernel and a root filesystem (image). We will download an Ubuntu image for testing.

# Create working directory
mkdir -p fc-demo
cd fc-demo

# Download Ubuntu 22.04 root filesystem
wget https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64-root.tar.xz

# Convert image (raw format)
xz -d ubuntu-22.04-server-cloudimg-amd64-root.tar.xz

3. Writing Control Logic in Rust

Now, let’s use Rust to launch a Firecracker instance, configure networking, and send requests. Passing configurations as JSON using serde_json is the most common approach.

Cargo.toml dependencies:

[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
reqwest = { version = "0.12", features = ["blocking"] }

Rust Implementation Code (main.rs):

use std::fs::{self, File};
use std::io::Write;
use std::process::{Command, Stdio};
use serde::Serialize;

// Firecracker configuration structs
#[derive(Serialize)]
struct BootSource {
 kernel_image_path: String,
 boot_args: String,
}

#[derive(Serialize)]
struct Drive {
 drive_id: String,
 path_on_host: String,
 is_root_device: bool,
 is_read_only: bool,
}

#[derive(Serialize)]
struct MachineConfig {
 vcpu_count: u8,
 mem_size_mib: u64,
 ht_enabled: bool,
}

#[derive(Serialize)]
struct NetworkInterface {
 if_id: String,
 guest_mac: String,
 host_dev_name: String,
}

fn main() {
 // 1. Set up working directory
 let vm_id = "my-first-microvm";
 fs::create_dir_all(format!("/tmp/fc-demo/{}", vm_id)).expect("Failed to create vm dir");

 // 2. Run Firecracker process (in background)
 // In a real environment, you would manage it as a daemon or create a socket via API.
 // Here, we assume the API server is run via a socket for simplicity and send configurations.
 
 // Note: A kernel image (vmlinux) is required for actual execution. 
 // It can be downloaded from the AWS Firecracker GitHub releases.
 let kernel_path = "/tmp/fc-demo/vmlinux"; // Path needs verification
 let rootfs_path = "/tmp/fc-demo/ubuntu-22.04-server-cloudimg-amd64-root.tar";

 // (Network configuration is complex in actual tutorials, so TAP device creation is omitted)
 // Example API configuration creation
 let boot_config = BootSource {
 kernel_image_path: kernel_path.to_string(),
 boot_args: "console=ttyS0 reboot=k panic=1 pci=off".to_string(),
 };

 let drive_config = Drive {
 drive_id: "rootfs".to_string(),
 path_on_host: rootfs_path.to_string(),
 is_root_device: true,
 is_read_only: false,
 };

 // Save configurations to JSON files (Firecracker accepts input via HTTP API or JSON files)
 let config_json = serde_json::to_string_pretty(&vec![&boot_config, &drive_config]).unwrap();
 let mut file = File::create(format!("/tmp/fc-demo/{}/vm_config.json", vm_id)).unwrap();
 file.write_all(config_json.as_bytes()).unwrap();

 println!("MicroVM configuration complete: {}", vm_id);
 println!("Firecracker typically requires network setup via TAP and mount configuration.");
 println!("Example CLI usage:");
 println!("./firecracker --api-sock /tmp/fc-demo/{}/api.sock", vm_id);
 println!("Then, send configurations via curl to http://localhost/...");
}

4. Execution and Control (CLI Method)

While automating with Rust code is ideal, it’s recommended to control and verify operations directly via CLI during the development stage.

# 1. Create TAP network interface (for host-guest connection)
sudo ip tuntap add tap0 mode tap
sudo ip addr add 169.254.0.1/30 dev tap0
sudo ip link set tap0 up

# 2. Run Firecracker (API socket mode)
./firecracker --api-sock /tmp/fc-demo/my-api.sock &

# 3. Send boot source configuration
curl --unix-socket /tmp/fc-demo/my-api.sock -i \
 -X PUT 'http://localhost/boot-source' \
 -H 'Accept: application/json' \
 -H 'Content-Type: application/json' \
 -d '{
 "kernel_image_path": "/path/to/vmlinux",
 "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
 }'

# 4. Send drive configuration
curl --unix-socket /tmp/fc-demo/my-api.sock -i \
 -X PUT 'http://localhost/drives/rootfs' \
 -H 'Accept: application/json' \
 -H 'Content-Type: application/json' \
 -d '{
 "drive_id": "rootfs",
 "path_on_host": "/path/to/rootfs.ext4",
 "is_root_device": true,
 "is_read_only": false
 }'
 
# 5. Start the instance
curl --unix-socket /tmp/fc-demo/my-api.sock -i \
 -X PUT 'http://localhost/actions' \
 -H 'Accept: application/json' \
 -H 'Content-Type: application/json' \
 -d '{ "action_type": "InstanceStart" }'

Conclusion and ZeroClaw Application Plan

As we’ve seen, MicroVMs offer strong isolation. In the ZeroClaw project’s “multi-agent architecture,” this technology is highly valuable. By executing each agent’s tasks (e.g., file system access, external network requests) within independent Firecracker instances, we can run “untrusted plugins” without compromising the overall system stability.

In the next post, we will discuss how to optimize communication between agents running on these MicroVMs.

References

Firecracker GitHub
[MicroVMs: Run isolated sandboxes with full lifecycle control](Hacker News Link)
[ZeroClaw Architecture Design Document](Internal Blog Link)

Designing MCP Authentication Architecture for Zero-Touch OAuth Implementation

Fri, 19 Jun 2026 09:00:58 +0900

Recently, I encountered an interesting technological trend called ‘Zero-Touch OAuth for MCP’. During the integration of MCP (Model Context Protocol) with our ZeroClaw runtime and blog-api-server that we are developing, ensuring security without compromising user experience is an essential task. In this post, we will design a ‘Zero-Touch’ authentication flow that helps users connect to MCP clients without any complex separate configurations, and explore how to implement it in actual code.

Why Zero-Touch?

Traditional OAuth 2.0 flows often require users to obtain a ‘Client ID’ and ‘Client Secret’ and enter them into a configuration file. However, for general users or developers, this presents a significant barrier to entry. Zero-Touch OAuth aims for a flow where the client automatically attempts authentication through pre-registered metadata, and users simply need to click an ‘Allow’ button.

Architecture Design

We will configure blog-api-server as the MCP Provider and Claude Code or custom clients as MCP Consumers. The core idea is to build a Public Client environment that does not store Secrets by using the PKCE (Proof Key for Code Exchange) extension.

Core Components:

MCP Client (Consumer): An agent running in the user’s local environment.
Auth Server: The OAuth2 authentication server implemented within blog-api-server.
Resource Server: The actual blog API.

Implementation Step 1: Server Side (blog-api-server)

First, we need to add a simple authentication endpoint to the Rust-based blog-api-server. We will extend the architecture mentioned in the previous post, ’[blog-api-server] Adding Language Parameter to MCP Blog Client’, to make the Auth module independent.

Here, we will show the core logic: the Verification logic. This is the process of verifying the code_verifier received from the client.

// blog-api-server/src/auth/handler.rs
use axum::{extract::State, Json};
use serde::{Deserialize, Serialize};
use sha2::{Digest, Sha256};
use base64::Engine as _;

#[derive(Deserialize)]
pub struct TokenRequest {
 pub code: String,
 pub code_verifier: String, // Random string generated by the client via PKCE
 pub redirect_uri: String,
}

#[derive(Serialize)]
pub struct TokenResponse {
 pub access_token: String,
 pub token_type: String,
 pub expires_in: u64,
}

pub async fn exchange_token(
 State(state): State<AppState>,
 Json(payload): Json<TokenRequest>,
) -> Result<Json<TokenResponse>, String> {
 // 1. Retrieve Authorization Code from DB
 let auth_record = state.db.get_auth_code(&payload.code)
 .await
 .map_err(|_| "Invalid code".to_string())?;

 // 2. PKCE Challenge Verification (Core Security Logic)
 let mut hasher = Sha256::new();
 hasher.update(payload.code_verifier.as_bytes());
 let hashed_verifier = hasher.finalize();
 let encoded_verifier = base64::engine::general_purpose::URL_SAFE_NO_PAD.encode(hashed_verifier);

 if encoded_verifier != auth_record.code_challenge {
 return Err("Code verifier mismatch".to_string());
 }

 // 3. Issue Access Token
 let access_token = generate_jwt(&state.secrets, &auth_record.user_id);

 Ok(Json(TokenResponse {
 access_token,
 token_type: "Bearer".to_string(),
 expires_in: 3600,
 }))
}

This code hashes the code_verifier sent by the client and checks if it matches the code_challenge generated when the initial authentication request was sent. This process is the core that makes ‘Zero-Touch’ secure.

Implementation Step 2: Client Side (MCP Client)

Now, the client can obtain a token without user intervention (or with minimal intervention). Let’s write an example MCP client using Python.

import hashlib
import base64
import requests
from urllib.parse import urlencode
import os # Import os module

# Zero-Touch Configuration (Hardcoded or Environment Variables)
CLIENT_ID = "zeroclaw-mcp-client"
AUTH_URL = "https://api.myblog.com/oauth/authorize"
TOKEN_URL = "https://api.myblog.com/oauth/token"
REDIRECT_URI = "http://localhost:3000/callback"

# Generate PKCE Code Verifier
random_bytes = os.urandom(32)
code_verifier = base64.urlsafe_b64encode(random_bytes).rstrip(b'=').decode('utf-8')

# Generate Code Challenge
challenge_digest = hashlib.sha256(code_verifier.encode('utf-8')).digest()
code_challenge = base64.urlsafe_b64encode(challenge_digest).rstrip(b'=').decode('utf-8')

def get_auth_url():
 params = {
 "response_type": "code",
 "client_id": CLIENT_ID,
 "redirect_uri": REDIRECT_URI,
 "scope": "mcp:read mcp:write",
 "code_challenge": code_challenge,
 "code_challenge_method": "S256"
 }
 return f"{AUTH_URL}?{urlencode(params)}"

def exchange_code_for_token(auth_code):
 data = {
 "grant_type": "authorization_code",
 "code": auth_code,
 "redirect_uri": REDIRECT_URI,
 "client_id": CLIENT_ID,
 "code_verifier": code_verifier # Sent to the server for verification
 }
 response = requests.post(TOKEN_URL, data=data)
 return response.json()

# Usage Example
# 1. User authenticates in the browser via get_auth_url() (first time)
# 2. Extract 'code' from the redirected query parameters
# 3. token = exchange_code_for_token(code)

Considerations for ZeroClaw Runtime Integration

As mentioned in our previous retrospective, ’[ZeroClaw] Q1 2026 Development Direction Meeting Minutes’, our agent runtime must prioritize security and scalability. If we integrate the OAuth flow implemented above into ZeroClaw’s Multi-Agent architecture, each agent can have an independent identity.

In particular, as discussed in ’[ZeroClaw] Multi-Agent Communication Protocol Design’, this Access Token can be used to securely access resources (APIs) of other agents during inter-agent communication, laying the foundation for secure access. This goes beyond simple blog automation and marks the first step towards a distributed system where agents trust and delegate tasks to each other.

Conclusion

Zero-Touch OAuth is an excellent approach that achieves both user convenience and security. We plan to start with small projects like blog-api-server and gradually evolve it into a core authentication module for ZeroClaw. The code above provides a basic framework, and for actual operational environments, logic such as state verification and refresh token rotation should be added.

In the next post, we will debug the ‘Handshake’ process of actually exchanging data with the MCP server using the tokens secured in this way.

Stop Using JWTs: The Practicality and Implementation of Session-Based Authentication

Wed, 17 Jun 2026 09:00:39 +0900

Stop Using JWTs: The Practicality and Implementation of Session-Based Authentication

Recently, the topic “Stop Using JWTs” has resurfaced as a hot potato in communities like Hacker News. When JWTs (JSON Web Tokens) first emerged, they were considered the standard for Microservice Architectures (MSA) thanks to the magic word “stateless.” However, in the reality of operating web services, we often fall into the trap of statelessness.

This article will explore why many developers are abandoning JWTs and returning to traditional session-based authentication (or database-based tokens), and how to implement it in practice.

The Sweet Trap of JWTs

The biggest advantage of JWTs is that they don’t require storing user state on the server. Since all information is contained within the token itself, only the signature needs to be verified without a database lookup. Theoretically, this offers excellent scalability.

However, this “advantage” quickly becomes a “disadvantage.”

1. Revocation Problem

Once issued, JWTs are valid until their expiration date. What if a user logs out, or an administrator needs to force them to log out?

Option 1: Let the token remain valid until it expires, as it cannot be immediately revoked. (Impossible as a safety measure)
Option 2: Introduce a blacklist. (Ultimately requires a DB/Redis lookup -> loss of stateless advantage)

The moment you introduce a blacklist, you need to check it for every JWT verification, thus losing the advantage of “without database lookup.”

2. Token Size and Overhead

JWTs, including headers, payloads, and signatures, are significantly larger than typical session IDs. The more claims (Roles, permissions, etc.) you include per user, the larger the token becomes. This wastes network bandwidth with every request.

Returning to Session-Based Authentication

In conclusion, it’s better to accept the fact that “state is managed on the server-side.” Using an in-memory database like Redis allows for very fast session management, and immediate logout or forced logout is possible.

In this section, we will build a simple yet robust session-based authentication system using Go and Redis.

Prerequisites

We assume Redis is installed and running locally.

Implementation Code (Go)

The following code is a simple HTTP server that provides /login, /protected, and /logout endpoints.

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"time"

	"github.com/go-redis/redis/v8"
	"github.com/google/uuid"
	"github.com/gorilla/mux"
	"golang.org/x/crypto/bcrypt"
)

var ctx = context.Background()
var rdb *redis.Client

// User information (in a real application, this would be fetched from a DB)
var userDB = map[string]string{
	"user1": "$2a$14$ajq8Q7fbnFR0nXf8bA7HcuiJ/6V.Z.yzX1lYh8g8h5x6z7x8x9x0x", // password: "password"
}

type Credentials struct {
	Username string `json:"username"`
	Password string `json:"password"`
}

func main() {
	// Initialize Redis client
	rdb = redis.NewClient(&redis.Options{
		Addr: "localhost:6379",
		Password: "", // no password set
		DB: 0, // use default DB
	})

	r := mux.NewRouter()
	r.HandleFunc("/login", loginHandler).Methods("POST")
	r.HandleFunc("/protected", authMiddleware(protectedHandler)).Methods("GET")
	r.HandleFunc("/logout", authMiddleware(logoutHandler)).Methods("POST")

	fmt.Println("Server starting on port 8000...")
	log.Fatal(http.ListenAndServe(":8000", r))
}

// Login handler
func loginHandler(w http.ResponseWriter, r *http.Request) {
	var creds Credentials
	err := json.NewDecoder(r.Body).Decode(&creds)
	if err != nil {
		w.WriteHeader(http.StatusBadRequest)
		return
	}

	// Check if user exists and verify password
	hashedPassword, exists := userDB[creds.Username]
	if !exists {
		w.WriteHeader(http.StatusUnauthorized)
		return
	}

	if err := bcrypt.CompareHashAndPassword([]byte(hashedPassword), []byte(creds.Password)); err != nil {
		w.WriteHeader(http.StatusUnauthorized)
		return
	}

	// Generate a new session ID
	sessionToken := uuid.NewString()

	// Store session in Redis (expires in 24 hours)
	err = rdb.Set(ctx, sessionToken, creds.Username, 24*time.Hour).Err()
	if err != nil {
		w.WriteHeader(http.StatusInternalServerError)
		return
	}

	// Set cookie (HttpOnly, Secure recommended)
	http.SetCookie(w, &http.Cookie{
		Name: "session_token",
		Value: sessionToken,
		Expires: time.Now().Add(24 * time.Hour),
		HttpOnly: true,
		Secure: true, // Only in HTTPS environment
		Path: "/",
		SameSite: http.SameSiteStrictMode,
	})

	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(map[string]string{"message": "Login successful"})
}

// Authentication middleware
func authMiddleware(next http.HandlerFunc) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		c, err := r.Cookie("session_token")
		if err != nil {
			if err == http.ErrNoCookie {
				w.WriteHeader(http.StatusUnauthorized)
				return
			}
			w.WriteHeader(http.StatusBadRequest)
			return
		}

		sessionToken := c.Value

		// Retrieve session from Redis
		response, err := rdb.Get(ctx, sessionToken).Result()
		if err != nil {
			if err == redis.Nil {
				w.WriteHeader(http.StatusUnauthorized)
				return
			}
			w.WriteHeader(http.StatusInternalServerError)
			return
		}

		// Optionally, store username in request context
		// r = r.WithContext(context.WithValue(r.Context(), "username", response))

		next(w, r)
	}
}

// Protected resource handler
func protectedHandler(w http.ResponseWriter, r *http.Request) {
	c, _ := r.Cookie("session_token")
	username, _ := rdb.Get(ctx, c.Value).Result()
	json.NewEncoder(w).Encode(map[string]string{"message": fmt.Sprintf("Hello %s, you accessed a protected route!", username)})
}

// Logout handler
func logoutHandler(w http.ResponseWriter, r *http.Request) {
	c, _ := r.Cookie("session_token")
	sessionToken := c.Value

	// Delete session from Redis (immediate revocation)
	rdb.Del(ctx, sessionToken)

	// Invalidate cookie
	http.SetCookie(w, &http.Cookie{
		Name: "session_token",
		Value: "",
		Expires: time.Now().Add(-1 * time.Hour),
		HttpOnly: true,
		Path: "/",
	})

	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(map[string]string{"message": "Logout successful"})
}

Code Explanation and Application Tips

Secure Cookie Usage: HttpOnly and Secure flags are used to prevent XSS (Cross-Site Scripting) and Man-in-the-Middle attacks. It is safer to encourage the client (browser) to store tokens in cookies rather than LocalStorage.
Leveraging Redis: Redis, being single-threaded, offers fast atomic operations and is ideal for use as a session store. Even if Redis goes down, the data isn’t permanently needed (as users can re-login), so it’s configured for fast response times.
Immediate Logout: The logoutHandler includes code to delete the key from Redis (rdb.Del). This perfectly solves JWT’s biggest weakness: “inability to log out.” The moment the key is deleted, that token (session ID) is no longer valid.

Conclusion: What Should You Choose?

When JWTs are good: When the system you are building consists of truly independent microservices, user authentication is needed for inter-service communication, and logout/reissue logic is not critical for simple API communications.
When Sessions/Cookies are good: For general web services, SaaS, and most cases where user security (immediate action required for account termination) is important.

The phrase “Stop Using JWTs” is not because JWT is a bad technology, but because it is misused and applied inappropriately for the situation. Adding complex JWT libraries and blacklist logic to a problem that can be solved with a simple session store can be an act of accumulating technical debt.

We recommend applying the Go code example above to your project and experiencing the ease of management and security firsthand.

Enhancing AI Agent Reliability: A Guide to Integrating Forge Guardrails with MCP

Wed, 20 May 2026 09:00:35 +0900

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:

Input Validation: Checks if user requests violate system policies (e.g., filtering for aggressive prompts).
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:

Improved Stability: Similar to the Forge case, even 8B models can be utilized safely, reducing inference costs.
Enhanced Transparency: Logs clearly indicate why an agent rejected a specific task.
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.

Deep Dive into ZeroClaw Architecture: Implementing Secure Inter-Agent Communication with Rust

Mon, 11 May 2026 09:01:26 +0900

Hello everyone! As the ZeroClaw project progresses, I want to share the design considerations and solutions encountered while building a high-performance Rust agent runtime and a multi-agent system. Recent security incidents, such as the ‘Remote Access Trojan (RAT) exploiting Obsidian plugins’, serve as a stark reminder of how crucial Security and Trust are in plugin and agent systems.

Today, I’ll introduce the secure and scalable inter-agent communication protocol designed by analyzing ZeroClaw’s codebase, along with concrete Rust code examples.

1. Introduction: The Need for Security-Conscious Agent Communication

During the development of previous MCP (Model Context Protocol) and blog automation systems, we realized that beyond simple data transfer, Authentication and Authorization between agents are essential. In a multi-agent environment where multiple agents collaborate to generate files or call external APIs, a mechanism to prevent malicious command injection is indispensable.

To address this, ZeroClaw adopts an architecture that leverages Rust’s Type Safety and Ownership system to catch many bugs at compile time and minimize runtime overhead.

2. Communication Protocol Design: IPC and Message Queues

ZeroClaw’s communication platform is broadly divided into Local IPC (Inter-Process Communication) and an Asynchronous Message Queue. Based on our experience improving the logging system, all communication is handled asynchronously (async), ensuring the independence of each agent.

Key Design Principles

Zero-Copy Serialization: Minimizes data serialization overhead using serde and bincode.
Message Validation: A layer validates all incoming messages to prevent tampered data from reaching the system core.
Capability-Based Security: Goes beyond simple token-based authentication by restricting the capabilities (actions) an agent can perform.

3. Implementing Secure Messaging Handlers with Rust

Let’s explore how this is implemented through actual code. This example is based on tokio and demonstrates the basic structure for secure message delivery.

3.1 Message Definition and Validation

First, we define the data structures for inter-agent communication and use the validator crate for input validation.

// message.rs
use serde::{Deserialize, Serialize};
use validator::Validate;

/// Agent communication message type
#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum AgentMessage {
 TaskRequest { id: String, payload: TaskPayload },
 TaskResponse { id: String, result: String },
 Heartbeat,
}

/// Task payload (includes validation logic)
#[derive(Debug, Clone, Serialize, Deserialize, Validate)]
pub struct TaskPayload {
 #[validate(length(min = 1, max = 100))]
 pub command: String,
 
 // Accepts JSON-formatted arguments but must be parsed structurally safely
 pub args: serde_json::Value, 
}

impl AgentMessage {
 /// Safely deserializes a message from a byte array.
 pub fn from_bytes(bytes: &[u8]) -> Result<Self, Box<dyn std::error::Error>> {
 // 1. Basic serialization validation
 let msg: AgentMessage = bincode::deserialize(bytes)?;
 
 // 2. Business logic validation (e.g., prevent Command Injection)
 if let AgentMessage::TaskRequest { payload, .. } = &msg {
 payload.validate()?; // Using the validator crate
 
 // Security: Example of filtering disallowed shell commands
 if payload.command.contains("rm ") || payload.command.contains("sudo") {
 return Err("Blocked potentially dangerous command".into());
 }
 }
 
 Ok(msg)
 }
}

3.2 Actor Model-Based Agent Structure

Each agent follows an Actor pattern, maintaining its own state and processing messages. Rust’s tokio::sync::mpsc channel is used to implement the mailbox.

// agent.rs
use tokio::sync::mpsc;
use super::message::AgentMessage;

pub struct Agent {
 id: String,
 receiver: mpsc::Receiver<AgentMessage>,
 // The agent's state is encapsulated here and not directly accessible from outside
}

impl Agent {
 pub fn new(id: String, receiver: mpsc::Receiver<AgentMessage>) -> Self {
 Self { id, receiver }
 }

 /// The agent's main loop
 pub async fn run(mut self) {
 println!("[{}] Agent started", self.id);
 
 while let Some(msg) = self.receiver.recv().await {
 if let Err(e) = self.handle_message(msg).await {
 eprintln!("[{}] Error handling message: {:?}", self.id, e);
 }
 }
 }

 async fn handle_message(&self, msg: AgentMessage) -> Result<(), Box<dyn std::error::Error>> {
 match msg {
 AgentMessage::TaskRequest { id, payload } => {
 println!("[{}] Executing task {}: {}", self.id, id, payload.command);
 // Actual task execution logic goes here (e.g., LLM calls, file writes, etc.)
 // Safeguards: Execute in a sandboxed environment or restrict permissions.
 },
 AgentMessage::Heartbeat => {
 // Handle heartbeat signal
 },
 _ => return Err("Unknown message type".into()),
 }
 Ok(())
 }
}

3.3 Runtime and Message Routing

Finally, here’s a simple runtime system for creating multiple agents and routing messages.

// runtime.rs
use tokio::sync::mpsc;
use std::collections::HashMap;
use super::agent::Agent;
use super::message::AgentMessage;

pub struct Runtime {
 agents: HashMap<String, mpsc::Sender<AgentMessage>>,
}

impl Runtime {
 pub fn new() -> Self {
 Self { agents: HashMap::new() }
 }

 pub fn spawn_agent(&mut self, id: &str) {
 let (tx, rx) = mpsc::channel(32);
 let agent = Agent::new(id.to_string(), rx);
 
 // Run the agent in a separate task
 tokio::spawn(agent.run());
 
 self.agents.insert(id.to_string(), tx);
 println!("Runtime: Agent '{}' spawned", id);
 }

 pub async fn broadcast(&self, msg: AgentMessage) {
 for (id, tx) in self.agents.iter() {
 if let Err(e) = tx.send(msg.clone()).await {
 eprintln!("Failed to send to {}: {:?}", id, e);
 }
 }
 }
}

4. Conclusion and Next Steps

The code implemented above demonstrates the core of the ZeroClaw multi-agent system: secure communication and isolated state management. Systems that execute external inputs or scripts, like the Obsidian plugin incident, are always potential targets for attacks.

ZeroClaw uses Rust’s powerful type system to block most of these risks at compile time and defends against them at runtime with additional validation layers. In the next post, we will discuss how this agent system actually integrates with external gateways like Discord or MCP, and how it is controlled through LLM configurations.

So far, I’ve shared the current status of ZeroClaw’s architectural design. I hope this is helpful for those looking to build high-performance yet secure agent systems!

Note: The code above is a Proof of Concept (POC) level example. For actual production environments, more robust error handling and logging systems (referencing the logging setup improved in the previous post) must be integrated.

Building a Blog AI Auto-Comment System (2/3) — Security Hardening

Sun, 03 May 2026 01:10:00 +0900

Overview

In Part 1, we covered the architecture and implementation of the AI auto-comment system. In this Part 2, we will focus on security aspects.

Systems that receive external Webhooks, manage GitHub API tokens, and process user input require special attention to security. We will explain the process of switching from environment variables to file-based authentication, the reasons behind it, and the design of each security layer.

Security Threat Model

Threats that this system must defend against:

Threat	Attack Vector	Defense
Spoofed Webhook	Attacker sends fake Webhook	HMAC-SHA256 signature verification
Token Leak	Environment variable exposure, log exposure	File-based authentication + permission restrictions
XSS/Injection	Malicious comment content	Input sanitization
Excessive Requests	DDoS, abuse	Flask-Limiter rate limiting
Privilege Escalation	Worker process compromise	systemd security directives
Infinite Loop	AI responding to itself	Marker-based comment detection

File-Based Authentication Management

Problems with Environment Variables

Initially, we managed GitHub tokens and Webhook secrets as environment variables:

# Initial (unsafe)
Environment=GITHUB_TOKEN=ghp_xxxxx
Environment=GITHUB_WEBHOOK_SECRET=my-secret-key

Problems with the environment variable approach:

/proc/PID/environ: Process environment variables are exposed as a file in Linux
Log exposure: Risk of environment variables being logged during debugging
Child process inheritance: When running Claude Code with subprocess.run, all environment variables are inherited
systemd configuration file: If the service file contains plaintext secrets, there is a risk of committing them to git

Switching to File-Based

Store credentials in the file system and specify only file paths in environment variables:

# Improved — only path exposed
Environment=GITHUB_TOKEN_FILE=/etc/auto-comment-worker/github-token
Environment=GITHUB_WEBHOOK_SECRET_FILE=/etc/auto-comment-worker/credentials/webhook-secret

Directory structure of the server:

/etc/auto-comment-worker/
├── github-token # GitHub Personal Access Token (640)
└── credentials/
 └── webhook-secret # GitHub Webhook HMAC Secret (600)

Token File Loading Code

import stat

GITHUB_TOKEN_FILE = os.environ.get('GITHUB_TOKEN_FILE', '')
if GITHUB_TOKEN_FILE and os.path.exists(GITHUB_TOKEN_FILE):
 # Check file permissions
 st = os.stat(GITHUB_TOKEN_FILE)
 if st.st_mode & stat.S_IWOTH:
 raise PermissionError("Token file must not be world-writable")
 with open(GITHUB_TOKEN_FILE, 'r') as f:
 GITHUB_TOKEN = f.read().strip()
else:
 GITHUB_TOKEN = os.environ.get('GITHUB_TOKEN', '')

Core design decisions:

Prefer file if it exists: Environment variables are used only as a fallback
Permission verification: Check permissions before reading the file
strip(): Remove newline characters at the end of the file

File Permission Validation — A Trial and Error Journey

I spent the most time on this part. The initial code was too strict:

# Initial code — too strict
if st.st_mode & (stat.S_IRWXO | stat.S_IRWXG):
 raise PermissionError("Token file must be 600 or 400")

Problem with this code: S_IRWXO | S_IRWXG checks all group permissions (read/write/execute) and all other permissions. That is, if the file permission is 640 (owner read/write, group read), it is rejected.

# Bit mask analysis
S_IRWXG = 0o070 # Group read+write+execute
S_IRWXO = 0o007 # Other read+write+execute

# 640 = 0o640
0o640 & (0o070 | 0o007) = 0o640 & 0o077 = 0o040 # Not 0 → Rejected!

For actual security, what matters is that other users cannot modify the file. Group read permission allows users in the same group to read the file and is not a security issue.

After revision:

# After revision — focus on actual threat
if st.st_mode & stat.S_IWOTH:
 raise PermissionError("Token file must not be world-writable")

You only need to check stat.S_IWOTH (0o002). This confirms only “Does it have write permission for others?”.

Permission	Octal	Initial Code	After Revision
`600`	`0o600`	Allowed	Allowed
`640`	`0o640`	Rejected	Allowed
`644`	`0o644`	Rejected	Allowed
`646`	`0o646`	Rejected	Rejected
`666`	`0o666`	Rejected	Rejected

HMAC-SHA256 Signature Verification

GitHub Webhook sends a signature created by HMAC-SHA256 hashing the request body with the Webhook secret in the X-Hub-Signature-256 header. We verify this to confirm that the request actually came from GitHub.

def verify_webhook_signature(payload: bytes, signature: str) -> bool:
 """GitHub webhook signature verification"""
 if not signature:
 logger.warning("Missing webhook signature")
 return False

 if not WEBHOOK_SECRET:
 logger.warning("WEBHOOK_SECRET not configured - skipping validation")
 return True # Allow for development mode

 try:
 hash_algorithm, github_signature = signature.split('=', 1)
 if hash_algorithm != 'sha256':
 return False

 mac = hmac.new(
 WEBHOOK_SECRET.encode(),
 msg=payload,
 digestmod=hashlib.sha256
 )
 expected_signature = mac.hexdigest()

 # Prevent timing attacks
 if not hmac.compare_digest(expected_signature, github_signature):
 return False

 return True
 except Exception as e:
 logger.error(f"Signature verification error: {e}")
 return False

Key points:

hmac.compare_digest(): Uses constant-time comparison instead of normal == comparison to prevent timing attacks.
raw bytes usage: Uses request.data (original bytes). If parsed with request.json and re-serialized, it may differ from the original.
Development mode: Skips validation if the secret is not set. The secret must be set in production.

nginx Header Forwarding

For signature verification to work properly, nginx must forward the X-Hub-Signature-256 header:

location /webhook {
 proxy_pass http://localhost:8081;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Hub-Signature-256 $http_x_hub_signature_256;
}

Unless X-Hub-Signature-256 is explicitly forwarded, custom headers may not be passed with just the default proxy_pass.

Request Validation (marshmallow Schema)

Validate the structure of the Webhook payload using a marshmallow schema:

class WebhookSchema(Schema):
 action = fields.Str(required=True, validate=validate.Equal('created'))
 comment = fields.Dict(required=True)
 discussion = fields.Dict(required=True)
 repository = fields.Dict(required=True)
 sender = fields.Dict(required=False)

action = 'created' only: Rejects comment edit (edited) or delete (deleted) events.
Required field validation: Returns 400 error if comment, discussion, repository are missing.
ValidationError → Audit log: Invalid requests are logged in the audit log.

Input Sanitization

User comments are external input, so they must be processed:

def sanitize_comment(body: str) -> str:
 """User input sanitization"""
 body = re.sub(r'<[^>]+>', '', body) # Remove HTML tags
 body = html.escape(body) # Escape special characters
 body = body[:1000] # Length limit
 return body

Where this sanitization is applied:

Comment body (comment_body)
Discussion title and body (discussion_title, discussion_body)
Original author name (original_author)
Quoted part when posting AI response

Username Masking

We do not log the full username:

def mask_username(username: str) -> str:
 """Username masking"""
 if not username or len(username) < 4:
 return "***"
 return f"{username[:3]}***"

Logs will only display masked names like yar***. This strikes a balance between privacy protection and debugging convenience.

Rate Limiting

Apply rate limiting per endpoint using Flask-Limiter:

limiter = Limiter(
 app=app,
 key_func=get_remote_address,
 default_limits=["10 per minute"],
 storage_uri="memory://"
)

@app.route('/webhook', methods=['POST'])
@limiter.limit("10 per minute")
def github_webhook():
 ...

10 requests per minute limit: A figure considering normal Webhook call frequency
get_remote_address: Limits based on client IP
memory://: In-memory storage (suitable for single process)

systemd Security Directives

Part 3 will cover systemd deployment in detail, but security-related directives are explained here:

[Service]
# Security hardening
NoNewPrivileges=true # Prevent privilege escalation
PrivateTmp=true # Provide isolated /tmp
ProtectSystem=strict # Read-only file system
ProtectHome=false # Allow home directory access (for Claude Code config)
ReadWritePaths=/var/www/auto-comment-worker /var/log/auto-comment-worker

# Resource limits
MemoryMax=512M # Memory limit
CPUQuota=50% # CPU usage limit
TasksMax=100 # Process count limit

Directive	Effect
`NoNewPrivileges=true`	Privilege escalation via `setuid`, `setgid`, etc. is impossible
`PrivateTmp=true`	Isolated `/tmp` namespace, separated from other processes
`ProtectSystem=strict`	Mounts entire file system as read-only
`ReadWritePaths`	Specifies only paths allowed for writing
`MemoryMax=512M`	Protects the entire system in OOM situations

Conflict between ProtectSystem=strict and ReadOnlyPaths

Initially, adding ReadOnlyPaths=/etc/auto-comment-worker caused an issue where the token file could not be read. Since ProtectSystem=strict already sets the entire file system to read-only, a separate ReadOnlyPaths is unnecessary. It was removed because it could cause conflicts in some environments.

Conclusion

In this Part 2, we covered file-based authentication management, the file permission validation journey, HMAC-SHA256 signature verification, input sanitization, rate limiting, and systemd security directives.

The most important lesson in security: “Too strict validation is as harmful as too loose validation.” The initial code, which only allowed 600 permissions, was secure, but in the actual operating environment, it rejected files with 640 permissions, preventing the service from starting. Focusing only on actual threats (world-writable) is the correct approach.

In the next Part 3, we will cover Deployment and Troubleshooting — systemd service configuration, nginx reverse proxy, and errors actually encountered and the resolution process.

This post is Part 2 of the AgentForge blog automatic comment system series.

[ZeroClaw] 2026 H1 Roadmap Meeting

Sat, 28 Feb 2026 09:55:15 +0900

ZeroClaw 2026 H1 Roadmap Team Meeting Minutes

Meeting Date: 2026-02-28 Attendees: Architect, Security Lead, Product Owner, DevOps Lead Location: ZeroClaw Development Team Meeting Room Author: ZeroClaw Team

1. Meeting Overview

This meeting was held to discuss ZeroClaw’s 2026 first-half development direction and establish roadmaps and priorities for each area.

1.1 Agenda

Multi-agent architecture development direction
Security enhancement and compliance response
Product competitiveness enhancement and UX improvement
DevOps and infrastructure advancement
Comprehensive roadmap and priority agreement

2. Architecture Development Discussion

2.1 Architect Statement

“ZeroClaw has completed Phase 1 (in-process delegation) and is currently implementing Phase 2 (file-based multi-agent). The following technical goals need to be achieved in the first half of 2026.”

2.1.1 Multi-Agent Orchestration Advancement

Proposals:

Implement DAG-based workflow execution engine
Support sequential/parallel/conditional/loop execution patterns
Improve agent task distribution algorithm

Priority: High (P1)

// Proposed workflow structure
pub struct Workflow {
 pub id: String,
 pub nodes: Vec<WorkflowNode>,
 pub edges: Vec<WorkflowEdge>,
 pub start_node: String,
 pub end_nodes: Vec<String>,
 pub error_handling: ErrorHandlingPolicy,
}

2.1.2 IPC Communication Protocol Improvement

Proposals:

Transition from stdout-based communication to structured IPC
Support multiple transport layers: Unix Socket, gRPC, WebSocket
Optimize message serialization (JSON → MessagePack/CBOR)

Priority: Medium (P2)

2.1.3 Extensibility and Modularization

Proposals:

Consider plugin architecture introduction
Implement Wasm execution mode (enhanced sandboxing)
Provide external agent registration API

Priority: Low (P3)

2.1.4 Performance Optimization

Proposals:

Zero-copy message passing
Connection pooling and caching strategies
Async I/O optimization

Priority: Medium (P2)

2.2 Discussion

Security Lead:

“Security channels must be applied first when improving IPC protocol. Encryption and authentication for inter-agent communication are needed.”

Product Owner:

“From a user perspective, agent definitions should be more intuitive. Let’s also consider simplifying the YAML schema.”

DevOps Lead:

“Performance optimization work should proceed in parallel with observability improvement. Metrics collection must be secured first to measure optimization effects.”

3. Security Development Discussion

3.1 Security Lead Statement

“ZeroClaw already has a strong security foundation, but there are areas that need improvement from an OWASP Top 10 perspective. Sandbox isolation and audit logging enhancement are particularly urgent.”

3.1.1 Sandbox Enhancement

Current Issues:

Docker sandbox: --read-only, --cap-drop, seccomp not applied
Firejail: Network isolation not applied (--net=none missing)

Proposals:

// Docker hardened profile
docker_cmd.args([
 "run", "--rm",
 "--read-only",
 "--security-opt", "no-new-privileges",
 "--cap-drop", "ALL",
 "--network", "none",
 "--memory", "256m",
 "--pids-limit", "64",
]);

Priority: High (P1)

3.1.2 Audit Logging Enhancement

Proposals:

Introduce Log Signing to prevent tampering
Real-time security alert webhook integration
Prometheus metrics exposure

Priority: Medium (P2)

3.1.3 SSRF Defense

Proposals:

Enforce HTTPS for external requests
Block private IP ranges
Strengthen domain allowlist validation

Priority: Medium (P2)

3.1.4 TOCTOU Vulnerability Fix

Proposals:

Perform path validation and normalization atomically
Prevent symbolic link race conditions

Priority: High (P1)

3.2 Discussion

Architect:

“Sandbox enhancement can provide stronger isolation when linked with Wasm execution mode.”

DevOps Lead:

“Prometheus metrics can greatly improve operational visibility when integrated with Grafana dashboards.”

Product Owner:

“Ensure that security enhancements don’t degrade user experience. Defaults should be secure while advanced users can configure flexibly.”

4. Product Development Discussion

4.1 Product Owner Statement

“ZeroClaw’s core values are ‘high performance’, ’extensibility’, and ‘security’. In the first half of 2026, we need to strengthen these while improving user experience.”

4.1.1 User Experience Improvement

CLI Improvements:

Improve zeroclaw agent list output (table format)
Interactive agent execution mode
Progress visualization

Configuration Simplification:

Simplify agent definition YAML schema
Provide sensible defaults
Improve configuration validation and error messages

Priority: High (P1)

4.1.2 Documentation and Onboarding Enhancement

Proposals:

Improve Quickstart guide
Auto-generate API reference documentation
Expand example scenarios
Multi-language documentation (Korean, Japanese, Chinese)

Priority: Medium (P2)

4.1.3 Community Growth Strategy

Proposals:

Improve CONTRIBUTING.md
Label good first issues
Publish regular release notes
Discord/Slack community channels

Priority: Medium (P2)

4.1.4 Differentiation Points Enhancement

Proposals:

Strengthen hardware peripheral support (STM32, RPi)
Specialized domain agent templates
Publish performance benchmarks

Priority: Low (P3)

4.2 Discussion

Architect:

“CLI improvement is important from an ergonomics perspective. Let’s also consider upgrading from structopt to clap 4.x.”

Security Lead:

“When writing multi-language documentation, accurate translation of security-related content is important. I recommend creating a terminology glossary first.”

DevOps Lead:

“For community channels, starting with GitHub Discussions is a good approach. It can be started without separate infrastructure.”

5. DevOps Development Discussion

5.1 DevOps Lead Statement

“We need to advance CI/CD pipelines and monitoring systems for stable deployment and operation.”

5.1.1 CI/CD Pipeline Advancement

Current Status:

GitHub Actions-based CI
Automated cargo fmt, clippy, test
Docker build

Proposals:

Integrate cargo audit (vulnerability scanning)
Cross-platform build (Linux, macOS, Windows)
Release automation (cargo-release)
Pre-deployment smoke tests

Priority: High (P1)

# Proposed CI workflow
- name: Security audit
 run: cargo audit

- name: Cross-platform build
 strategy:
 matrix:
 os: [ubuntu-latest, macos-latest, windows-latest]
 runs-on: ${{ matrix.os }}

5.1.2 Monitoring and Observability

Proposals:

Prometheus metrics endpoint
Grafana dashboard templates
Distributed tracing (OpenTelemetry)
Log aggregation (ELK/Loki)

Priority: Medium (P2)

5.1.3 Deployment Automation and Rollback

Proposals:

Blue-Green deployment support
Automatic rollback threshold settings
Canary release options

Priority: Medium (P2)

5.1.4 Development Environment Improvement

Proposals:

devcontainer configuration
Automatic git hooks setup
Development configuration profiles

Priority: Low (P3)

5.2 Discussion

Architect:

“OpenTelemetry integration is essential for multi-agent tracing. Inter-agent call chains must be visualizable.”

Security Lead:

“cargo audit must be included in CI. It’s also good to add dependency license checks.”

Product Owner:

“devcontainer will be very helpful for new contributor onboarding. We can raise its priority.”

6. Comprehensive Roadmap and Priorities

6.1 2026 First Half Roadmap

Q1 (March-April)

Item	Owner	Priority
Docker/Firejail sandbox enhancement	Security	P1
TOCTOU vulnerability fix	Security	P1
CI/CD security scan integration	DevOps	P1
CLI improvement and UX enhancement	Product	P1
DAG-based workflow engine	Architect	P1

Q2 (May-June)

Item	Owner	Priority
IPC communication protocol improvement	Architect	P2
Audit logging enhancement	Security	P2
SSRF defense implementation	Security	P2
Prometheus metrics exposure	DevOps	P2
Documentation and onboarding improvement	Product	P2
Community infrastructure building	Product	P2

6.2 Agreed Principles

Security First: All new features must go through security review
Gradual Deployment: Large changes are rolled out in stages
Rollback Capable: All changes must be easily rollbackable
Documentation Sync: Documentation updates required when features change
Test Coverage: Tests required for new code

6.3 Risks and Responses

Risk	Probability	Impact	Response
Sandbox compatibility issues	Medium	High	Implement fallback mechanism
Performance regression	Low	Medium	Automate benchmarks
Dependency vulnerabilities	Medium	High	Automate cargo audit
Poor documentation	High	Medium	Require documentation PRs

7. Conclusion and Next Steps

7.1 Meeting Conclusions

Architecture: Prioritize multi-agent orchestration advancement
Security: Immediately start sandbox enhancement and TOCTOU fix
Product: Improve user experience through CLI UX improvement
DevOps: Build CI/CD security enhancement and monitoring foundation

7.2 Action Items

#	Item	Owner	Due Date
1	Apply Docker sandbox security profile	Security Lead	2026-03-07
2	Fix TOCTOU path validation	Security Lead	2026-03-10
3	Integrate CI cargo audit	DevOps Lead	2026-03-05
4	Improve CLI agent list	Product Owner	2026-03-12
5	Workflow engine design document	Architect	2026-03-15

7.3 Next Meeting Schedule

Date: 2026-03-14 10:00
Agenda: Q1 progress review and Q2 detailed planning

Appendix: Reference Documents

docs/project/multi-agent-architecture-design.md - Multi-agent architecture design
docs/project/multi-agent-communication-protocols.md - Communication protocol design
docs/security/security-improvements.md - Security improvement report
CLAUDE.md - Engineering protocol

Meeting Minutes Date: 2026-02-28 Approved By: ZeroClaw Team Lead Distribution: ZeroClaw Development Team

Korean Version: 한국어 버전

[ZeroClaw] Codebase Architecture Analysis

Thu, 26 Feb 2026 10:07:29 +0900

ZeroClaw Codebase Architecture Analysis Report

Written on February 26, 2026

Overview

ZeroClaw is a high-performance autonomous agent runtime written in Rust. This report summarizes the analysis of the codebase structure and security architecture.

1. Core Architecture Patterns

ZeroClaw adopts trait-driven extensibility as its core design principle.

1.1 Major Traits (7)

Trait	Location	Role
`Provider`	src/providers/traits.rs	AI model provider interface
`Channel`	src/channels/traits.rs	Communication channel interface
`Tool`	src/tools/traits.rs	Tool execution interface
`Memory`	src/memory/traits.rs	Memory backend interface
`Observer`	src/observability/traits.rs	Observability interface
`RuntimeAdapter`	src/runtime/traits.rs	Runtime adapter interface
`Peripheral`	src/peripherals/traits.rs	Hardware peripheral interface

2. Security Architecture

ZeroClaw implements security through a Defense-in-Depth strategy.

2.1 Security Layers (6)

SecurityPolicy Core - Autonomy level management
Gateway Security - Bearer token authentication
Tool Validation - Injection prevention
Runtime Sandbox - Landlock/Firejail/Docker
Secret Management - ChaCha20-Poly1305
Audit Logging - Event tracking

2.2 Core Security Boundaries

Command allowlist: 15 items
Rate limiting: 20 requests/hour
Environment variables: only 8 allowed

3. Multi-Agent System

Implementation Roadmap

Phase	Duration	Content
1	1 week	Core traits, DelegateTool extension
2	2-3 weeks	Docker/Wasm execution modes
3	4+ weeks	Distributed message bus, consensus algorithm

Conclusion

ZeroClaw has an excellent architecture in terms of extensibility, security, performance, and maintainability.

This report was written based on collaborative analysis by the ZeroClaw development team.

Korean Version: 한국어 버전