How to Secure Your OpenClaw Deployment: A Practitioner’s Guide to AI Agent Security

Why AI Agent Security Is Different From Traditional Application Security

Traditional application security assumes software does what it’s told. You secure the inputs, validate the outputs, lock down the endpoints. The application runs the same logic every time.

AI agents break that assumption. They make autonomous decisions about which tools to call, what files to read, what commands to execute, and how to respond to inputs they’ve never seen before. A traditional web application won’t decide on its own to execute a shell command. An AI agent might, if its instructions are manipulated through the input channel.

The numbers reflect how unprepared most organizations are for this shift. Gravitee’s 2026 State of AI Agent Security report found that 88% of organizations experienced AI agent security incidents, and only 14.4% of agents made it to production with full security approval. Meanwhile, 82% of executives believed their existing security policies were sufficient, while only 21% had actual visibility into what their agents were accessing.

That gap between confidence and visibility is where incidents happen.

Non-human identities are projected to outnumber human employees 80:1 in enterprise environments. Each identity represents credentials, access patterns, and potential attack surface that traditional identity management wasn’t designed to handle.

We run four autonomous agents in production on OpenClaw, handling everything from SEO research to content publishing to analytics. Over the past year, we developed a 12-domain security framework through the unglamorous process of discovering what can go wrong when agents operate independently around the clock. This guide is that framework, made public.

The 12-Domain Security Framework

Most security guides for AI agents read like theoretical checklists. They cover the obvious stuff (use strong passwords, enable 2FA) and stop short of the operational reality of running autonomous systems in production.

Our framework covers 12 domains because that’s how many distinct areas we found where something could go wrong. Some are familiar from traditional security. Others, like inter-agent communication monitoring and automation restriction, exist only because autonomous agents create attack surfaces that traditional applications don’t have.

Here’s the full list, with the operational details behind each one.

1. Network Architecture and Access Control

The OpenClaw gateway should never be directly exposed to the internet. Bind it to loopback only (gateway.bind: "loopback") and route all external access through a reverse proxy with TLS termination.

This sounds basic, and it is. But a January 2026 CVE discovered by Ethiack demonstrated why it matters: a WebSocket origin validation bypass allowed one-click remote code execution. The attack worked by having a victim visit an attacker-controlled page that connected to the local OpenClaw gateway through the browser. The gateway token was sent in the first WebSocket frame, giving the attacker full operator access. Even a “private” deployment on localhost was vulnerable because the WebSocket request originated from the victim’s browser.

That vulnerability was patched, but the lesson stands. Defense in depth means layering protections so that a single bypass doesn’t give an attacker everything:

• Cloud-level controls (Security Groups, NSGs) to restrict inbound ports
• CDN/proxy layer (Cloudflare, CloudFront) for DDoS protection and TLS termination
• Web Application Firewall to restrict access by IP, geography, or request pattern
• Host-level firewall (ufw/iptables) as an additional backstop
• Application-level authentication on all dashboards and APIs

For dashboard security specifically: never accept authentication tokens in URL query parameters. They leak through server logs, browser history, and HTTP referrer headers. Use header-based token authentication or session cookies with httpOnly, secure, and sameSite flags.

2. Secrets Management That Actually Works

OpenClaw supports environment variable substitution (${VAR_NAME}) in its configuration files and SecretRef objects for formal secrets management. Every API key, bot token, and credential should resolve from a secured .env file or a secrets provider. Plaintext credentials in configuration files that get read frequently, and that someone might accidentally commit to version control, are the most common deployment mistake we see.

What should be externalized:

• Gateway authentication tokens
• Channel tokens (Discord, Telegram, Slack)
• LLM provider API keys (Anthropic, Google, z.ai)
• Third-party service credentials (search APIs, CRM, analytics)
• Webhook signing secrets

File permissions matter too. All files containing secrets should be mode 600 (owner read/write only). That includes .env files, auth-profiles.json, session logs, and integration credentials. The OpenClaw config directory (~/.openclaw/) should be mode 700.

3. Agent Scoping and the Principle of Least Privilege

Each agent should have access to only the tools, files, and commands it needs for its specific job. OpenClaw provides several mechanisms for this:

• tools.fs.workspaceOnly: true restricts filesystem access to the agent’s workspace directory, with explicit allowlists for additional paths
• tools.exec.security: "scoped" limits which shell commands an agent can execute
• subagents.allowAgents: [] prevents agents from spawning or delegating to other agents unless delegation is an explicit design requirement

The practical insight we’d share: don’t try to build your permission allowlists on day one. Observe first. Audit 2-4 weeks of session logs to map each agent’s actual file access patterns, exec commands, and API calls. Then build allowlists around observed behavior.

The reason is pragmatic, not philosophical. Agents that hit permission errors tend to try creative workarounds, which burns tokens and can produce unexpected behavior. A content writing agent denied access to a directory might try to reconstruct the file contents from memory, wasting API calls and producing inaccurate output. Getting the scope right from the start avoids that cycle.

Credential isolation follows the same logic. A content writing agent doesn’t need social media OAuth tokens. An analytics agent doesn’t need WordPress publishing credentials. Use per-agent environment files or OpenClaw’s SecretRef system to inject only the relevant credentials into each agent’s context.

4. Channel Security and Reducing Your Attack Surface

Every channel through which someone can communicate with your agents is a potential attack vector. An unused but enabled Telegram integration, for example, is attack surface with zero operational value.

The Gravitee report found that 25.5% of deployed agents can create and task other agents. Channel restriction limits this cascade. If an attacker compromises one communication path, a well-scoped deployment limits what they can trigger.

For channel configuration:

• Use dmPolicy: "allowlist" so only explicitly approved users can direct-message agents
• Use groupPolicy: "allowlist" so agents only respond in explicitly approved channels
• Restrict the users list to known operator IDs
• Enable 2FA on all accounts that can communicate with agents
• Remove incoming webhooks from agent channels (webhooks can inject messages that agents treat as legitimate instructions)
• Disable any channel or service you aren’t actively using

5. Model Selection as a Security Decision

This is the domain most security guides skip entirely: the model you choose for an agent directly affects its resistance to prompt injection attacks.

Research published by HelpNetSecurity found that Claude Haiku was bypassed in 72% of prompt injection attempts, while GPT-4o held up against 57% of the same attacks. The gap is significant. A weaker model running a tool-enabled agent is a fundamentally different security posture than a stronger one doing the same job.

Our recommendation:

• Use the strongest available model for any agent with tool access (filesystem, exec, web requests, APIs)
• Reserve smaller, faster models for read-only tasks or tasks without tool permissions
• Configure cross-provider fallback chains (e.g., Anthropic primary, z.ai fallback) for both security resilience and availability
• Remove weak models from fallback chains for tool-enabled agents entirely. A fallback to a weaker model during a provider outage is the exact window an attacker exploits

6. Securing Inter-Agent Communication

In a single-agent deployment, you worry about external inputs. In a multi-agent system, you also worry about agents talking to each other. A compromised agent can attempt to inject malicious instructions into another agent’s workflow through shared channels, filesystem inboxes, or message queues.

This is the domain we had to develop from scratch, because almost nobody else runs multi-agent production systems where agents communicate autonomously. Generic security guides don’t cover it because they don’t have to.

Three practices make this manageable:

Communication monitoring. Log all inter-agent messages with source, destination, timestamp, content summary, and anomaly flags. Watch for unusual volume, new communication patterns, or suspicious content patterns. An agent that suddenly starts sending messages to an agent it has never communicated with before is worth investigating.

Output sanitization. Before an agent’s output flows into another agent’s input, scan for system prompt fragments, tool call syntax that could be interpreted by the downstream agent, base64-encoded content, and markdown/HTML injection patterns. This is the inter-agent equivalent of input sanitization in web applications.

Instruction file integrity. Critical instruction files, agent configurations, shared skills, and system prompts should be monitored for unauthorized changes. Compute and track hashes, and alert if they change outside of expected update windows. If an agent modifies its own instructions or another agent’s instructions, that’s a containment event.

7. Cost Controls and Abuse Prevention

Autonomous agents can generate unbounded API costs. A bug, a runaway loop, or a deliberate attack can rack up thousands in LLM API charges before anyone notices. This isn’t theoretical; it’s the operational risk we worried about most when we first deployed agents on scheduled jobs.

The solution is a spending circuit breaker that runs independently of the agent infrastructure:

• Track rolling daily spend across all agents using a system cron, not an agent-managed process
• Escalate through warning thresholds (50%, 75%, 90% of daily budget) before taking hard action
• Automatically shut down the gateway at a hard spending limit
• Send alerts through a non-AI channel (webhook to a monitoring service, SMS) so notifications work even when the AI system is shut down

Session duration limits matter too. A cron-triggered status check doesn’t need 30 minutes. A complex content pipeline stage might. Set appropriate timeouts per task type, and treat any session that runs to its limit as worth reviewing.

The most important cost control is also the least obvious: restrict automation creation. Only operators should be able to create, modify, or delete scheduled tasks (cron jobs). An agent that can schedule itself is the primary amplification vector for a compromised system. One malicious instruction, replicated across a dozen scheduled runs, turns a single breach into an ongoing incident.

8. Webhook and API Endpoint Security

Any webhook endpoint that accepts data from external services needs cryptographic signature verification. HMAC-SHA256 with a shared secret, timestamp checking to reject signatures older than 5 minutes (preventing replay attacks), and timing-safe comparison to prevent timing attacks.

Rate limiting belongs on every endpoint, especially authentication endpoints (to prevent brute force), webhook endpoints (to prevent injection flooding), and data query endpoints (to prevent scraping).

These are standard web security practices applied to agent infrastructure. They’re worth stating explicitly because the “agent” framing sometimes leads people to think different rules apply. They don’t.

9. Audit Logging and Forensics

Comprehensive logging captures everything an agent does: tool calls, file operations, web requests, inter-agent communications, authentication events, configuration changes, and external API calls. Without this, incident investigation becomes guesswork.

The challenge with agent systems is that the agents themselves often have shell access, which means they can potentially modify log files. Protect against this with:

• Append-only filesystem attributes (chattr +a on Linux) — prevents modification by non-root processes
• Off-server log shipping to cloud logging services — survives complete server compromise
• Regular integrity verification — compare local logs against remote copies

Complement human review with automated pattern matching that flags unusual command execution, failed authentication attempts, writes to critical system files, communication with unexpected external endpoints, and sessions with anomalous duration or token usage.

Audit trails are the strongest predictor of governance maturity in agent deployments. Organizations that log comprehensively catch problems faster and recover more completely. Organizations that don’t are flying blind.

10. Dependency and Upgrade Security

Never upgrade OpenClaw directly in production. Maintain a staging environment where every upgrade gets tested:

• Apply the upgrade on staging
• Run security scans (npm audit, pip audit, openclaw security audit --deep)
• Diff changed files and review for suspicious additions, particularly new network calls or credential access patterns
• Smoke test: start the gateway, run agent sessions, verify functionality
• Only then apply to production

External skills and plugins deserve special scrutiny. Any skill that reads environment variables and makes network requests should be manually reviewed. The combination of credential access and network egress is the signature pattern of credential harvesting.

11. Data Flow Governance

Maintain a registry of every external service your agents communicate with: what data is sent and received, which agents make which calls, the sensitivity level of the data, and whether the flow is approved by relevant stakeholders.

This is especially important for LLM API calls. Your prompts contain business content, customer data, strategic information, and operational details. That content is transmitted to the model provider with every API call. Know where your data is going and confirm that the data handling policies of your LLM providers meet your requirements.

Data flows change as agents gain new capabilities. Audit session logs quarterly for external API calls that don’t appear in your registry. These represent undocumented data flows that need review and approval before they become permanent.

12. Incident Response: Having a Plan Before You Need One

Before something goes wrong, define:

• Detection — what alerts and monitoring trigger an investigation
• Containment — how to stop all agent activity quickly (openclaw cron disable --all, gateway shutdown)
• Investigation — where to find evidence (audit logs, session transcripts, git history)
• Recovery — how to restore to a known-good state (daily backups, version-controlled configs)
• Post-mortem — how to document what happened and update hardening

The most critical piece is maintaining a break-glass access path. If the agents are compromised or shut down, you need a way to access and diagnose the system that is completely independent of the AI agent infrastructure. SSH access with an interactive terminal session, not routed through the agent system, is the simplest approach.

If your incident response plan depends on an AI agent to execute it, your plan fails the moment it’s needed most.

How to Evaluate an AI Agent Development Partner’s Security Practices

If you’re evaluating vendors to build or manage AI agent systems, these are the questions that separate organizations that take security seriously from those that don’t:

• Do they have a documented security framework? Can they share it?
• Do they run agents in production themselves? (A vendor that builds agents but doesn’t operate them may not understand operational security.)
• Can they demonstrate credential isolation between agents?
• Do they maintain audit logging, and can they show you sample logs?
• Do they have spending controls and circuit breakers?
• Do they test in a staging environment before production?
• Do they have an incident response playbook?
• How do they handle inter-agent communication in multi-agent systems?

Red flags worth watching for: shared API keys across agents, no session logging, agents with unrestricted filesystem access, no staging environment, and no documented incident response process.

We built this framework through the operational reality of running autonomous agents around the clock. Our AI risk and security assessment applies it to organizations evaluating their own agent deployments.

Security Checklist

Domain	Key Practice
Network	Gateway on loopback, reverse proxy with TLS, WAF, host firewall
Secrets	Externalized via env vars or SecretRef, file permissions 600, never in git
Agent Scoping	Workspace-only filesystem, scoped exec, subagent delegation disabled
Channels	Single controlled channel, allowlisted users, unused channels disabled
Models	Strongest model for tool-enabled agents, cross-provider fallbacks, no weak fallbacks
Inter-Agent	Communication monitoring, output sanitization, instruction file integrity
Cost Controls	Independent spending circuit breaker, session timeouts, restricted automation creation
Webhooks	HMAC signature verification, timestamp checking, rate limiting
Logging	Centralized audit logs, tamper-resistant storage, automated pattern matching
Dependencies	Staging environment, security scans, file diffs before production upgrades
Data Flows	Complete external service registry, quarterly audits, stakeholder approval
Incident Response	Defined playbook, break-glass access path independent of agent system

Frequently Asked Questions

Is OpenClaw safe to run in production?

Yes, with proper hardening. OpenClaw provides the mechanisms for strong security (gateway isolation, scoped exec, credential externalization), but the defaults are permissive by design. Security is a configuration responsibility, not something that happens automatically. The practices in this guide reflect what “properly hardened” looks like in our production environment.

What’s the minimum security setup for an OpenClaw deployment?

At minimum: gateway bound to loopback with a reverse proxy in front, all secrets externalized via environment variables, scoped exec enabled with an allowlist of permitted commands, and a single controlled communication channel with an allowlisted user list. That covers the highest-risk attack surfaces. Add the remaining domains as your deployment matures.

How does NemoClaw compare to manual OpenClaw security?

NemoClaw adds out-of-process policy enforcement through OpenShell, giving you runtime security controls that exist outside the agent’s own context. Manual hardening (this guide) secures the deployment configuration and operational practices. They’re complementary. We covered NemoClaw in detail in our analysis of what NemoClaw means for enterprise agent development.

What are the biggest security risks with AI agents?

Prompt injection (manipulating agents through crafted inputs), over-permissioning (agents with more access than their job requires), shadow AI (unauthorized agent deployments outside IT governance), and inter-agent compromise (a breached agent injecting instructions into other agents). Shadow AI breaches cost $670,000 more than standard security incidents on average.

How do you prevent an AI agent from going rogue?

Principle of least privilege (agents can only access what they need), spending circuit breakers (independent cost monitoring that can shut down the gateway), session timeouts (no indefinite sessions), and restricted automation creation (agents cannot schedule themselves). These layers contain damage even if the agent’s behavior is compromised.

Should AI agents have their own identity?

Yes. Only 21.9% of organizations currently treat agents as independent identity-bearing entities. The rest share credentials across agents or use generic service accounts, which makes it impossible to audit which agent did what. Per-agent credential isolation is both a security practice and a governance requirement.

How often should you audit AI agent security?

Continuous logging with automated alerting handles day-to-day monitoring. Layer quarterly manual reviews on top: check data flows against your registry, audit permission scopes against actual usage, review inter-agent communication patterns for drift, and verify that your incident response playbook still matches your current architecture.

What’s the cost of an AI agent security breach?

It depends on the type. Shadow AI breaches (unauthorized agents operating outside governance) cost an average of $670,000 more than standard security incidents, according to Gravitee’s 2026 report. A survey by EY via the AIUC-1 Consortium found that 64% of companies with over $1 billion in revenue had lost more than $1 million to AI-related failures. The costs compound when you factor in operational disruption, data exposure, and the time required for incident investigation and recovery.

Where This Goes Next

AI agent security is evolving as fast as the agents themselves. The practices in this guide represent what we know works today from running autonomous systems in production. New attack patterns will emerge, new defensive tools will appear, and some of what we’ve written here will need updating.

We’ll continue refining these practices as our deployment grows and as the broader agent security ecosystem matures. If you’re building or evaluating AI agent systems and security is a concern, it should be, and we’re happy to discuss how these practices apply to your specific architecture.

Explore our AI workflow and automation services or learn how AI agent teams operate in business environments.