How to audit exactly what your OpenClaw agent has access to

Most operators set up OpenClaw, get it working, and never look at what they actually gave it access to. After 800+ malicious plugins were confirmed on ClawHub this month, that gap is no longer theoretical. This article is a complete access audit: every surface your agent can reach, in order of risk, with the exact questions to ask it and what to do with the answers. It takes under an hour and most operators find at least one thing they did not intend.

Why your access surface is larger than you think

When you installed OpenClaw, you made a set of decisions about what it could do. Some of those decisions were explicit: you chose which plugins to install, which channels to connect. Many were implicit: the defaults that shipped with your install, the settings you never changed, the plugins that registered tools you did not know about.

Your agent’s access surface is the sum of everything it can do in a single turn: read files, run shell commands, send messages, call external APIs, access memory, schedule future tasks, browse the web. Each capability is either explicitly granted or inherited from defaults. The goal of this audit is to make that list explicit so you can verify it matches what you intended.

The access surface matters for two reasons. First, if a malicious plugin is installed, it can use any tool your agent has access to. A plugin that registers a “summarize this URL” tool can, if written maliciously, also call the exec tool to run commands or the message tool to exfiltrate data. It runs in the same process with the same tool access. Second, even with trusted plugins, scope creep is real: agents given broad access tend to use it in ways operators did not anticipate, and finding out after the fact is worse than auditing before.

Step 1: Enumerate your registered tools

Registered tools are the capabilities your agent can call in a turn. The tool list differs from your plugin list. Plugins can register additional tools on top of the first-party set. The tool list is the ground truth of what your agent can actually do.

List every tool you currently have access to. For each tool, give me its name, a one-sentence description of what it can do, and whether it was registered by a first-party OpenClaw module or by a plugin. If you cannot tell which registered a tool, say so.

Read the full list. For each tool, ask yourself: did I intend to give my agent this capability? Is this tool appropriate for how I use OpenClaw?

Common tools in a standard OpenClaw install:

• read / write / edit: file system access within the workspace directory
• exec: run shell commands on the host machine
• browser: control a web browser, including navigating URLs and extracting page content
• web_search / web_fetch: outbound HTTP to search engines and arbitrary URLs
• message: send messages through connected channels (Discord, Telegram, etc.)
• memory_store / memory_recall / memory_forget: read and write to the memory database
• cron: create, modify, and delete scheduled jobs
• nodes: access paired devices (camera, screen, location, notifications)
• tts: text-to-speech output
• image / pdf: analyze images and documents via external APIs
• sessions_spawn / sessions_send: create and communicate with sub-agent sessions

Any tool not in this list that shows up in your agent’s response was registered by a plugin. Note it and check which plugin registered it in Step 3.

Step 2: Check your exec security settings

The exec tool (if your agent has it) is the highest-risk capability in a standard OpenClaw install. It runs shell commands on your host machine. Two settings control how much latitude the agent has when using it.

The first is security, which controls what commands are allowed:

• deny: exec is blocked entirely. The agent cannot run any shell commands.
• allowlist: only commands on an explicit allowlist can run. Everything else is blocked.
• full: any command can run. This is the highest-risk setting.

The second is ask, which controls whether the agent prompts you before running commands:

• off: the agent runs exec commands without prompting. You see the result after the fact.
• on-miss: the agent prompts only for commands not on the allowlist.
• always: the agent prompts for every exec command before running it.

These two settings combine to define your actual exec risk. security: full with ask: off means your agent can run any shell command on your machine without asking. That may be intentional for a trusted local setup. It should be intentional, not a default you forgot to check.

What are the current values of the exec tool’s security mode and ask mode in your config? Show me the exact values and explain what each one means for what you are allowed to do without my approval.

If you find security: full and ask: off and you are running OpenClaw on a machine with sensitive data or production systems, this is the first thing to change. Set ask: always at minimum so you see every exec command before it runs.

What is your exec allowlist? List every command pattern that is allowed to run without triggering the on-miss approval flow. If no allowlist is configured, tell me that explicitly.

Step 3: Audit your installed plugins

A plugin is code that runs inside your OpenClaw process. It can register new tools, intercept messages, access the file system, make network calls, and modify agent behavior. Plugins have the same runtime access as the OpenClaw core. A malicious plugin is not sandboxed. It runs with full access to everything the process has access to.

There are two distinct things to check here: what plugins are installed, and what tools each plugin registers. They are different questions.

List every plugin currently installed and enabled. For each plugin: give me its name, the version, whether it is enabled or disabled, and every tool it registers. If a plugin registers tools that are not in the first-party tool list I got in Step 1, flag those explicitly.

For every plugin that is enabled, verify three things:

1. Do you know where it came from? If you installed it from ClawHub, check the ClawHub listing is still live and has not been flagged. If you installed it from npm, check the npm package still exists and has not been unpublished or taken over. If you wrote it yourself, confirm it is the version you wrote.

2. Does the SKILL.md or README describe what it does, and does that match what you expected?

For each enabled plugin, read its SKILL.md or README and tell me: (1) what it claims to do, (2) what network calls it makes and to which domains, (3) what tools it registers, (4) what data it stores or transmits, and (5) whether anything in its description contradicts what I expected when I installed it.

3. Is there a security scan result for it? If you have the security audit skill installed, run it against each plugin’s SKILL.md before trusting the plugin.

Run the security audit script against every enabled plugin’s SKILL.md or README. Report any flagged lines and whether each flag is a confirmed risk or a false positive in your judgment.

Step 4: Review credentials and API keys in your config

Your openclaw.json contains API keys for every provider you have configured: the AI model provider, memory provider, any plugin that requires credentials, channel integrations. Your agent can read this config. Any plugin with tool access can potentially read it too, depending on how the plugin is written.

The goal of this step is to know exactly what credentials are stored, verify they are the right ones (not leaked or rotated keys you forgot to update), and check that no credentials are stored that you no longer need.

List every API key, token, and credential stored in your config. For each one: tell me which service it belongs to, when it was last rotated if you know, and whether the service it belongs to is still active and in use.

After reviewing the list:

• Any credential for a service you no longer use should be removed from the config and revoked at the provider.
• Any credential that has not been rotated in more than 90 days should go on your rotation schedule.
• Any credential that appears in the config that you do not recognize should be treated as potentially compromised until verified.

Step 5: Check your channel integrations

Channel integrations connect your OpenClaw instance to messaging platforms: Discord, Telegram, Signal, WhatsApp, Slack, and others. Each integration is both an inbound surface (people who can send commands to your agent) and an outbound surface (channels your agent can send messages to).

List every channel integration currently configured. For each one: what platform is it, what is the bot or account identity, who is on the authorized senders list, and can the agent send messages to channels or users not on the authorized list?

The authorized senders list is the inbound access control: it determines who can send messages that your agent will act on. An empty or absent authorized senders list typically means any user who can reach the bot can issue commands to your agent. This is the default on many fresh installs.

The outbound surface matters because your agent can be instructed to send messages to channels, users, or groups. If the message tool is available with broad outbound permissions, a malicious instruction (via prompt injection or a compromised plugin) could use your bot to send messages to anyone in your channels.

For each channel integration: is there an authorized senders list configured? If yes, list the authorized IDs. If no, explain what happens when an unauthorized user sends a message to the bot.

Step 6: Review memory scope access

Memory in OpenClaw is stored in scopes. A scope is a named namespace: agent:main, session, user, or custom scopes defined by plugins. The scope your agent can read and write determines what it can learn and retain across sessions.

Most operators use a single scope (agent:main) and never think about this. But if you have multiple agents or sessions, or if a plugin stores data in its own scope, the question of which scopes each agent can access becomes a data boundary question.

What memory scopes do you have access to? Can you read and write all scopes, or only specific ones? List every scope you can currently access and what is stored in each one.

If your agent has access to scope: * (wildcard, all scopes), it can read everything stored in the memory database across all agents and sessions. This is appropriate for a single-agent setup. In a multi-agent setup, check that each agent’s scope access is limited to what it needs.

How many memories are currently stored in each scope you have access to? Give me a count per scope and the categories represented (preferences, facts, decisions, entities, reflections, other).

This gives you a picture of the accumulated data your agent holds. If the count is much higher than you expect, it may indicate a plugin has been storing data in memory without your awareness.

Step 7: Audit your cron jobs and scheduled tasks

A cron job is a scheduled task that runs your agent autonomously at a set time or interval. Cron jobs run with the same tool access as interactive sessions. A cron job that runs every 15 minutes and has exec access runs exec every 15 minutes, whether or not you are watching.

List every cron job currently configured, including disabled ones. For each job: the schedule, the payload (what it does when it fires), whether it is enabled, and when it last ran. Flag any job that you cannot explain the purpose of.

For each cron job, verify:

• Is it still needed? Zombie cron jobs accumulate over time: tasks created for a specific purpose that outlived their usefulness but were never disabled.
• Is the schedule appropriate? A job that fires every minute is very different from one that fires once a day in terms of its accumulated access and cost.
• Does the payload match the job name? A job named “morning brief” should produce a morning brief, not run an unrelated command.
• Does the job have delivery configured? Jobs with delivery send results somewhere. Know where.

For each enabled cron job: what tool calls does it make when it runs? Does it use exec, file writes, outbound messages, or web access? List the tool surface for each job.

Step 8: Check your file system access

The read, write, and edit tools give your agent file system access. The scope of that access depends on how the tools are configured and whether exec is available. With exec, file system access is effectively unlimited: your agent can read any file the process user has permission to read.

What is your workspace directory? What files and subdirectories are currently in it? Are there any files in the workspace that contain sensitive information: API keys, passwords, personal data, or anything that should not be there?

Beyond the workspace, check whether sensitive files are accessible from adjacent directories:

Can you read files outside of your workspace directory? Try reading ~/.ssh/config (do not show the content, just tell me whether the file exists and whether you can read it). If you can read it, explain what that means for what other files you could access.

Step 9: Verify your gateway exposure

The final audit step checks the network exposure of your OpenClaw gateway to check whether it is reachable from the public internet.

What is the current value of gateway.bind in your config? Is the gateway running on 127.0.0.1 (loopback only, not reachable from outside) or 0.0.0.0 (all interfaces, reachable from the public internet)? What port is it running on?

If the gateway is bound to 0.0.0.0, it is reachable from the public internet on whatever port it is using. The SSH tunneling article (linked in Go Deeper) covers how to change this. For this audit, the goal is to surface the current state.

What to do with the audit results

After running all nine steps, you have a complete picture of your agent’s access surface. Organize what you found into three buckets:

Act immediately: Any plugin you cannot identify or verify the source of. Any credential that may have been exposed. Gateway bound to 0.0.0.0 without a compensating firewall rule. Exec set to security: full, ask: off on a machine with sensitive data. Authorized senders list empty on a public-facing bot.

Schedule to fix: Credentials not rotated in 90+ days. Zombie cron jobs with no clear purpose. Plugins with network calls to unrecognized domains. Memory stores with more data than expected.

Document as intended: Everything else that surprised you but is operating as designed. Write it down. The next audit is easier when you have a baseline.

Based on everything you found in this audit, summarize the top three risks in my current setup ranked by severity. For each one, give me the specific config change or action that would reduce it, and the cost (time, complexity, what it breaks) of making that change.

Troubleshooting: when the audit hits a wall

This usually means the agent does not have the read tool available, or the config file is outside the workspace directory. Ask your agent: “What is the full path to your workspace directory?” Then check whether ~/.openclaw/openclaw.json is inside or adjacent to that directory. If the config is outside the workspace, the agent may not be able to read it with the read tool. Use exec instead: “Run: cat ~/.openclaw/openclaw.json | python3 -m json.tool and show me the output.” If exec is also blocked, you will need to read the config file directly via SSH.

This happens. Common causes: a plugin that was installed as a dependency of another plugin, a plugin that was installed during an initial setup script, or a plugin installed by someone else who had access to the machine. For each unrecognized plugin, ask your agent: “When was the [plugin name] plugin installed? Check the file creation date on its directory in ~/.openclaw/extensions/ or the npm install date in the node_modules directory.” If it was installed recently and you did not install it, treat it as potentially compromised and disable it before investigating further.

The cron tool may not be in your agent’s tool list, or cron jobs may have been created by a different session. Ask your agent: “Do you have the cron tool available? If yes, list all jobs including disabled ones with the includeDisabled parameter. If no, tell me how cron jobs are stored and how I can view them manually.” If cron is unavailable, the job store is typically accessible via the gateway API at localhost:18789/api/cron/jobs if your gateway is running.

Describe the finding to your agent and ask for the specific remediation steps. For most audit findings, the fix is either a config change (which your agent can help you make) or a plugin removal (which requires disabling the plugin in config and restarting the gateway). For compromised credentials, the process is always the same regardless of what else is wrong: rotate the credential at the provider first, update the config second, then investigate how it was exposed.

FAQ

Run it in full when you first set up OpenClaw, after installing any new plugin, after any security incident or near-miss, and at least once every 90 days as routine maintenance. The plugin audit (Step 3) is worth running on its own whenever you see unexpected behavior from your agent, especially if that behavior involves network calls or file writes you did not request. In a post-ClawHub-crisis environment, the bar for “something seems off, run the plugin audit” should be low. Unexplained latency, unusual API spend, messages sent from your bot that you did not trigger. Any of these warrant a targeted Step 3 run before assuming the cause is something benign.

It depends entirely on what else your agent has access to and what your threat model is. On a dedicated server that only runs OpenClaw, with no other sensitive data, with all plugins verified, exec: full is a reasonable convenience trade-off that enables a lot of useful automation. On a laptop that also holds work files, SSH keys, browser sessions, and personal data, exec: full means your agent can read any of those things and, if prompted maliciously (via a poisoned web page, a rogue plugin, or a crafted message), could exfiltrate them. The risk is not theoretical. Prompt injection attacks that use exec to exfiltrate data have been documented in the wild as of 2026. The question is whether the convenience is worth the risk on your specific machine. If you are unsure, set ask: always. You lose some automation convenience but gain visibility into every command before it runs.

Yes, if exec is available to the plugin’s tool calls or if the plugin is written to directly access the file system. Plugins run in the same process as OpenClaw core and are not sandboxed. A plugin that registers a tool can call exec internally to read any file the process has access to, including openclaw.json, and transmit its contents via an outbound HTTP call disguised as something else. This is exactly the attack pattern used by the malicious plugins identified in the ClawHub crisis. The audit in Step 3 (reading each plugin’s source code and checking outbound network calls) is the defense against this. There is no runtime sandboxing that prevents a plugin from doing this if it is designed to.

A tool is a capability that the agent can call during a turn: read a file, run a command, send a message. Tools are the verbs. A plugin is code that runs alongside OpenClaw to extend its behavior. Plugins can register new tools, intercept incoming messages, add memory backends, connect new channels, and modify how the agent behaves. The relationship: plugins can create tools, but not all tools come from plugins. First-party OpenClaw tools (read, write, exec, browser, etc.) are built into the core and do not require a plugin. Plugin-registered tools look identical to first-party tools from the agent’s perspective. There is no visual distinction in the tool list. This is why the audit asks specifically whether each tool was registered by a plugin.

A disabled plugin should not run and should not register tools. In practice, “fully inactive” depends on how the plugin handles the disabled state in its code. A well-written plugin stops all activity when disabled. A poorly-written or malicious plugin might continue running background processes even when the enabled flag is false. The safest state for a plugin you no longer want is removed, not disabled. To remove a plugin: disable it in config, restart the gateway to confirm the tool it registered is no longer in your tool list, then delete the plugin files from ~/.openclaw/extensions/ or uninstall the npm package. Ask your agent to verify the tool list after the restart to confirm the plugin-registered tool is gone.

This is a real question worth thinking about. Your agent reports on itself, and a compromised agent might report inaccurately. For the purposes of this audit, the agent-first instructions are the starting point, not the final word. For any finding that matters (especially in the plugin and credential steps), verify it independently. If your agent says “no unfamiliar plugins,” also check ~/.openclaw/extensions/ via SSH directly and compare. If your agent says “no credentials for inactive services,” also look at the raw config yourself. The agent is a fast first pass. The manual checks are the verification. For a thorough security audit, treat the agent’s self-report as a prompt for manual verification, not as the audit result itself.

It depends on where your bot is deployed. If your Discord bot is in a private server with only you as a member, an empty authorized senders list is inconvenient (anyone in the server could command the bot) but low risk in practice. If your Telegram bot’s link is public or has been shared, an empty authorized senders list means anyone with the link can send commands to your agent. On a public-facing bot, an empty authorized senders list is a significant risk. Anyone who discovers the bot can attempt to prompt-inject it, extract information from it, or use its tool access. Set the authorized senders list to your own user ID as a minimum. Ask your agent: “How do I add my user ID to the authorized senders list for each channel integration? Show me the config change.”

Three stores persist between sessions: the memory database (explicit memories stored by memory_store calls, in a LanceDB or similar vector database), the LCM database (compressed conversation history, in a SQLite database at the path shown in your config), and any files written to the workspace directory. The memory database and LCM database are local files on your server. They are not encrypted at rest by default in most OpenClaw installs. Anyone with file system access to your server can read them. Ask your agent: “Where are the memory database and LCM database stored on disk? What are their file paths and sizes? Are they included in any backup or sync process?”

The most reliable method is network monitoring at the OS level. On Linux, ss -tp shows active TCP connections with the process that owns them. Run it while your agent is processing a turn that should involve a specific plugin, then again at idle. Connections that appear during plugin activity and go to unexpected destinations are worth investigating. A simpler but less complete approach: search the plugin source code for fetch, axios, https.request, http.request, curl, or any URL pattern. Ask your agent: “Search the source code of each enabled plugin for outbound HTTP calls. List every URL or domain the plugin calls, including any that are constructed dynamically at runtime.” Note that dynamically constructed URLs (where the domain is assembled from variables) are harder to catch this way. They require reading the full logic of the plugin.

Disable the plugin immediately before investigating. A disabled plugin stops running. Then: look up the domain in a WHOIS lookup to see who registered it and when. Check if the plugin’s README or SKILL.md mentions the domain as an expected call (some plugins use third-party APIs legitimately). Search for the domain in combination with “malware” or “phishing” to see if it has been flagged. If the domain cannot be explained by legitimate plugin behavior, remove the plugin entirely, check the memory database for any entries that reference external URLs (a sign the plugin may have been storing exfiltration targets), rotate any credentials that were active while the plugin was running, and report the plugin to ClawHub. Do not reinstall until you have read the full source code and identified the exact line responsible for the call.

A lightweight automated version is useful. A cron job that runs the tool enumeration and plugin list checks daily, compares them to a known-good baseline, and sends you a diff if anything changed catches the most important thing: new tools or plugins appearing without your action. Ask your agent: “Write me a daily audit cron job that checks the current tool list and plugin list against a saved baseline in the workspace. If anything is different from the baseline, send me a message with the diff. If nothing changed, do nothing.” The baseline file is written by the first run. This gives you change detection without the overhead of a full nine-step audit every day.

Prompt injection is when a malicious instruction embedded in content the agent reads (a web page, a document, a memory entry) causes the agent to execute unintended commands. Signs include: exec commands appearing in the agent’s tool calls that you did not request, messages sent from your bot that you did not trigger, files created or modified in the workspace with no obvious connection to the current task, or API calls to providers you did not instruct. The agent activity log (if your setup includes one) is the best post-hoc record. Ask your agent: “Show me the last 20 tool calls you made across all sessions. Are there any that you cannot explain as being caused by an explicit instruction from me?” If the agent cannot account for a tool call, that is worth investigating. The broader defense against prompt injection is keeping exec access limited (ask: always) and not feeding the agent content from untrusted sources without awareness of the risk.