Case Study: Securing OpenClaw Without Changing Its Code

The Challenge

OpenClaw is a feature-rich AI assistant framework built in TypeScript/Node.js. It is designed as a local-first personal assistant with an impressive range of capabilities:

• Connects to 13+ messaging channels including WhatsApp, Telegram, Slack, Discord, Signal, iMessage, and more
• Direct access to shell commands and file systems
• Browser automation for web interaction
• Arbitrary tool execution with no built-in restrictions

OpenClaw is a powerful tool for personal use. But it was designed as a local-first personal assistant, not with enterprise security in mind. In a corporate environment, deploying it without governance would be a non-starter. An application that can execute arbitrary shell commands, read any file, and communicate across a dozen external channels represents an unacceptable risk surface without policy enforcement, identity verification, and audit trails.

The Approach: Boundary Enforcement

The key insight is deceptively simple: enforce security at the boundary, not inside the application.

Instead of modifying OpenClaw to understand policies, identities, or audit requirements, we wrote a thin adapter layer that translates OpenClaw's application protocols into the gateway's enforcement model. From OpenClaw's perspective, it is talking to its normal backend services. It does not know (and does not need to know) that every request is being evaluated against 13 layers of security middleware before it reaches its destination.

The application does not know it is being governed.

What We Did NOT Do

It is worth being explicit about what this integration did not require:

• We did not fork OpenClaw
• We did not patch it
• We did not add security middleware inside its codebase
• We did not modify a single line of its source code

OpenClaw runs as its upstream maintainers ship it. We track their releases and pull updates without merge conflicts because there is nothing to merge; we have changed nothing in their repository.

What We Did

The entire integration consists of three adapter components totaling approximately 800 lines of Go:

HTTP Adapter openclaw_http_adapter.go

Handles two HTTP endpoints that OpenClaw uses for its core operations:

• /v1/responses: Model inference requests, routed through the gateway's full policy mediation chain
• /tools/invoke: Tool execution requests, subject to admission decisions by the gateway's tool policy engine

WebSocket Adapter openclaw_ws_adapter.go

Manages persistent WebSocket connections for OpenClaw's real-time features:

• /openclaw/ws: Persistent connection for device management, health monitoring, and event streaming
• Role-based access control: operator role grants broad access; node role requires device identity presentation

Contract Layer internal/integrations/openclaw/http_adapter.go

The internal contract layer that bridges OpenClaw's request format to the gateway's enforcement model:

• Request parsing and validation against expected schemas
• Policy target resolution, mapping OpenClaw's tool names to gateway policy identifiers
• Dangerous tool blocking at admission: shell, exec, and session management tools are flagged before they reach the middleware chain

How It Works

Consider what happens when OpenClaw tries to execute a shell command. The following sequence diagram shows the full request lifecycle:

The request never reaches an actual shell. It is denied at step 9 because bash is classified as a critical tool, pushing the session risk score above the step-up threshold. OpenClaw receives a structured denial with a clear reason code.

Policy Contrast: Same Application, Different Outcomes

The power of boundary enforcement becomes clear when you compare two tool invocations from the same OpenClaw instance:

The Only Code Change Required

After tracking 50+ upstream commits to OpenClaw, we encountered exactly one contract drift. The OpenClaw WebSocket protocol changed to require that node-role connections present a device identity. This required a 12-line guard in our WebSocket adapter:

if role == "node" {
    device, hasDevice := frame.Params["device"].(map[string]any)
    nodeDeviceID := ""
    if hasDevice {
        nodeDeviceID = strings.TrimSpace(getStringAttr(device, "id", ""))
    }
    if nodeDeviceID == "" {
        g.writeOpenClawWSFailure(conn, frame.ID, http.StatusForbidden,
            reasonWSDeviceRequired, "node role requires device identity",
            decisionID, traceID)
        return nil
    }
}

12 lines in the adapter. Zero lines in OpenClaw. Zero lines in the gateway core.

This is the entire cost of tracking a rapidly evolving upstream application across 50+ commits. The adapter absorbed the contract change. The gateway was untouched. OpenClaw was untouched. The change was isolated exactly where it belonged: in the thin translation layer between the application and the enforcement boundary.

What This Proves

The OpenClaw integration demonstrates a general principle: you can secure agentic AI applications without modifying them.

1. The adapter pattern is the key insight. Each application integration is a thin translation layer (approximately 800 lines of Go) that maps the application's protocols to the gateway's enforcement model. The application remains unmodified.
2. The gateway is shared infrastructure. The 13-layer middleware chain, the policy engine, the audit system, the identity verification: none of these change when you onboard a new application. They are shared infrastructure that every adapter reuses.
3. New applications are onboarded by writing an adapter, not by retrofitting security. Adding a new application to PRECINCT means writing a new adapter. It does not mean modifying the application, forking it, or injecting security code into its runtime.
4. Security controls evolve independently. OpenTelemetry metrics, structured logging, OPA v1 policy support; all of these were added to the gateway without any changes to OpenClaw or its adapter. The application benefits from improved security without being aware of it.
5. Compliance evidence is centralized. One audit log. One policy engine. One identity system. Auditors review the gateway and its policies, not individual application codebases. This dramatically simplifies compliance posture for organizations running multiple agentic AI applications.

Agent Implementations

Beyond OpenClaw, PRECINCT supports any agent framework through its SDK. The following examples show how popular Python agent frameworks integrate with PRECINCT's governance layer.

DSPy Research Agent

The DSPy research agent demonstrates how a structured LLM programming framework integrates with PRECINCT's governance layer. The agent uses DSPy's module system for prompt optimization while the PRECINCT SDK handles identity and policy enforcement transparently.

# agents/dspy_researcher/agent.py
import dspy
from mcp_gateway_sdk import GatewayClient

# DSPy handles prompt optimization; PRECINCT handles governance
client = GatewayClient()  # Auto-discovers SPIFFE identity

class ResearchAgent(dspy.Module):
    def forward(self, query: str):
        # All tool calls routed through the governed gateway
        result = client.call_tool("web_search", {"query": query})
        return dspy.Prediction(answer=result)

PydanticAI Research Agent

The PydanticAI agent showcases type-safe, structured-output integration with PRECINCT. PydanticAI's agent framework provides schema validation while the PRECINCT gateway enforces runtime policy.

# agents/pydantic_researcher/agent.py
from pydantic_ai import Agent
from mcp_gateway_sdk import GatewayClient

client = GatewayClient()  # SPIFFE identity auto-injected

agent = Agent(
    "openai:gpt-4o",
    system_prompt="You are a research assistant.",
)

@agent.tool
async def search(ctx, query: str) -> str:
    """Search via the governed gateway."""
    return await client.call_tool_async("web_search", {"query": query})

The Numbers