OpenClaw is an incredible, local-first personal AI assistant. Because it is designed to run directly on your machine, you can give it access to local files, databases, and terminal commands to write and execute code.

However, this tool-calling autonomy introduces severe security risks. If your agent is exposed to malicious data or suffers from prompt injection, a compromised agent could execute a destructive command (like modifying your host filesystem or running an unapproved shell script).

To secure this without modifying OpenClaw’s core code, you can route its tool-calling pipeline through a policy firewall.

Here is how you can use Loopers (an open-source Go proxy) to intercept Model Context Protocol (MCP) tool calls and validate them against Open Policy Agent (OPA/Rego) rules before they can execute on your host machine.

1. Intercepting the Tool Call

Loopers acts as a local proxy. By pointing OpenClaw’s tool-calling pipeline to the Loopers proxy address, all JSON-RPC 2.0 tools/call requests are routed through the proxy first.

2. Writing the Security Policy (Rego)

You can define fine-grained security rules in a local .rego file (e.g., /policies/security.rego). Loopers compiles and evaluates this on the critical path in less than a millisecond:

regopackage loopers.policy
default allow = false
# 1. Allow the request by default if no deny rules match
allow {
    not deny
}
# 2. Block OpenClaw from executing terminal shell tools in development
deny[msg] {
    input.request.method == "mcp_tool_call"
    input.request.tool_name == "execute_shell_command"
    input.agent.tags.environment == "development"
    msg := "Terminal command execution is blocked in local development."
}
# 3. Restrict sensitive filesystem tools to admin owners only
deny[msg] {
    input.request.tool_name == "delete_file"
    input.agent.owner != "admin"
    msg := sprintf("File deletion restricted. Current owner is: %s", [input.agent.owner])
}

3. Execution & Blocking

When OpenClaw attempts to run a tool:

1. The proxy intercepts the JSON-RPC request and extracts the metadata (tool name, MCP server, agent tags, and owner name).
2. It evaluates the Rego rules.
3. If a deny rule matches, the proxy drops the connection immediately and returns a 403 Forbidden response, preventing the shell command or filesystem write from ever hitting your system.

By separating the agent's execution layer from your security policies, you guarantee that even a compromised agent cannot bypass your guardrails.

We need the community's support!

Loopers is fully open-source (MIT licensed) and self-hosted. As we launch, we need your help to make Agent Runtime Governance a standard:

• Star the repo: If you find this project or the concept of OPA-based agent governance useful, a star on GitHub goes a long way in helping us get visibility. Repo in comments.
• Contribute: We are actively looking for contributors to help us write more framework integrations and client SDK adapters.

How are you currently securing OpenClaw and other local-first agents in your workflows? Are you sandboxing the entire host namespace, or using proxy-level policies? Let's discuss!

I’ve been building autonomous agents and deploying them with MCP. One of the biggest headaches is still runtime safety, specifically, agents getting stuck in recursive tool-calling loops and racking up brutal API bills before anyone notices.

We’ve all heard of the $47k LangChain loop, but even small local loops with tools can burn cash fast.

To solve this, we built Loopers, an open-source, fail-closed reverse proxy that acts as a physical firewall for AI traffic. It uses atomic Redis Lua scripts to check and reserve budget before the request is sent downstream. If the agent hits its limit, Loopers drops a steel door and blocks the connection.

Integrating it with LangChain or any other framework literally takes changing the base URL of your LLM client.

Here is the quick setup:

1. Spin up the proxy (via Docker):

bash# Clone the repository (replace [at] and [dot] with @ and .)
git clone git[at]github[dot]com:CURSED-ME/loopers-oss.git
cd loopers-oss
docker-compose up -d

2. Create a budget key (e.g., $2.00/hr cap):

bashdocker-compose exec loopers /app/loopers keys create --name my-agent --provider openai
docker-compose exec loopers /app/loopers budget set <KEY_HASH> --hourly 2.00 --daily 10.00

3. Point LangChain to Loopers: You can do this with standard ChatOpenAI (Zero-SDK):

pythonfrom langchain_openai import ChatOpenAI
import os
llm = ChatOpenAI(
    model="gpt-4o",
    # Point base_url to your local proxy port 8080
    base_url="localhost:8080/openai/v1", 
    api_key="lp-xxx", # Your proxy key
    default_headers={
        "X-Loopers-Provider-Key": os.environ.get("OPENAI_API_KEY"),
        "X-Loopers-Session-ID": "market-research-task"
    }
)

Or use our drop-in Python wrapper:

pythonfrom loopers_client.integrations.langchain import ChatLoopers
import os
llm = ChatLoopers(
    model="gpt-4o",
    loopers_url="localhost:8080",
    loopers_key="lp-xxx",
    provider_key=os.environ.get("OPENAI_API_KEY"),
    session_budget=5.00,  # Cap this run at $5
    max_steps=20          # Hard limit on steps
)

The project is fully open-source. You can find the repository on GitHub under CURSED-ME/loopers-oss and the Python client package under loopers-client on PyPI.

Would love to hear how you guys are handling budget guardrails right now, or if you've run into any crazy loops yourself!

Like many of you, I've been building and deploying autonomous agents. But there’s a massive elephant in the room that we don't talk about enough: infinite hallucination loops.

We’ve all heard the horror stories like the LangChain pipeline that got stuck in an 11-day loop and racked up a $47,000 API bill.

The problem is that current guardrails (like LangChain's max_iterations) are application-layer, and observability tools (like LangSmith) only tell you that you lost money after the request is already processed.

To solve this for our own agents, we built Loopers, an open-source, fail-closed reverse proxy that acts as a physical firewall for AI traffic. It uses atomic Redis Lua scripts to check and reserve budget before the request is sent downstream. If the agent hits its limit, Loopers drops a steel door and blocks the connection.

Integrating it with LangChain literally takes changing the base_url.

Here is the quick setup:

1. Spin up the proxy (via Docker):

bashgit clone https://github.com/CURSED-ME/loopers-oss.git
cd loopers-oss
docker-compose up -d

2. Create a budget key (e.g., $2.00/hr cap):

bashdocker-compose exec loopers /app/loopers keys create --name my-agent --provider openai
docker-compose exec loopers /app/loopers budget set <KEY_HASH> --hourly 2.00 --daily 10.00

3. Point LangChain to Loopers: You can do this with standard ChatOpenAI (Zero-SDK):

pythonfrom langchain_openai import ChatOpenAI
import os
llm = ChatOpenAI(
    model="gpt-4o",
    base_url="http://localhost:8080/openai/v1",
    api_key="lp-xxx", # Your proxy key
    default_headers={
        "X-Loopers-Provider-Key": os.environ.get("OPENAI_API_KEY"),
        "X-Loopers-Session-ID": "market-research-task"
    }
)

Or use our drop-in Python wrapper:

pythonfrom loopers_client.integrations.langchain import ChatLoopers
import os
llm = ChatLoopers(
    model="gpt-4o",
    loopers_url="http://localhost:8080",
    loopers_key="lp-xxx",
    provider_key=os.environ.get("OPENAI_API_KEY"),
    session_budget=5.00,  # Cap this run at $5
    max_steps=20          # Hard limit on steps
)

The project is fully open-source: https://github.com/CURSED-ME/loopers-oss

Would love to hear how you guys are handling budget guardrails right now, or if you've run into any crazy runaway loops yourself!