stop adding agents. map the one already running.
the next openclaw upgrade isn’t another model or tool. it’s a registry that shows what your current assistant can reach.
installation isn’t an openclaw problem anymore really..
the real mess here is when your useful setup becomes too big to remember.
a weekend test turns into a browser task.
repo access gets added for one coding job.
research starts landing inside a local workspace.
memory saves a few facts that feel useful.
some scheduled check begins running while you’re away.
none of this looks reckless in the moment of course.
one month later, your assistant has channels, tools, memory, browser access, mcp experiments, scheduled runs, and keys you haven’t reviewed since setup day.
that’s agent sprawl.
microsoft now treats this as a control problem. agent 365 is built around discovering, governing, and securing agents across devices, clouds, tools, identities, and local runtimes. microsoft’s security blog names openclaw as one of the local agents enterprises may need to discover and manage.
openclaw isn’t the villain in that sentence.
the category grew up.
openclaw is useful because it touches real work. the official repo describes a local-first gateway that acts as one control plane for sessions, channels, tools, and events, with support for whatsapp, telegram, slack, discord, signal, imessage, microsoft teams, matrix, mattermost, nextcloud talk, and more.
that reach needs a map.
not later.
before the next tool.
make one file first
create this file:
openclaw-agent-registry.yamlstore it here:
~/.openclaw/operator/openclaw-agent-registry.yamluse these commands if the folder doesn’t exist:
mkdir -p ~/.openclaw/operator
touch ~/.openclaw/operator/openclaw-agent-registry.yamlan agent registry is a plain map of your setup.
it records where the agent runs, how messages reach it, which tools are enabled, where memory lives, what browser profile gets used, where secret categories exist, and which actions stay blocked.
beginners should treat the file as a permission list.
technical operators should treat it like a local control-plane record.
no registry replaces sandboxing, separate hosts, os-level isolation, allowlists, private ingress, or real security review.
without one, your setup turns into folklore inside your own head.
start with this beginner template
copy the template.
fill in what you know.
leave rough edges alone.
registry_version: "0.1"
owner: "your name"
last_reviewed: "2026-05-19"
agents:
- name: "main openclaw assistant"
purpose: "messages, research, admin prep, and workflow review"
runs_on: "local machine"
environment: "personal"
channels:
- "telegram"
- "whatsapp"
tools:
- "browser"
- "file read"
- "file write"
memory:
path: "~/.openclaw/workspace/MEMORY.md"
rule: "save durable facts only when they should be reused later"
browser:
profile: "separate openclaw browser profile"
logged_in_accounts:
- "none yet"
secrets:
api_keys:
- "anthropic key from environment variable"
oauth:
- "none"
allowed_actions:
- "draft messages"
- "summarize files"
- "prepare calendar suggestions"
blocked_actions:
- "send email without approval"
- "delete files"
- "buy anything"
- "deploy code"
- "connect a new mcp server without review"
next_review: "2026-05-26"plain english version:
owner:
the person responsible for the setup.
runs_on:
the computer, server, vps, or container running openclaw.
channels:
the apps, bots, webhooks, dms, or group routes that can reach the agent.
tools:
the actions the agent can use.
memory:
the saved facts the agent may reuse later.
browser:
the browser profile the agent uses.
secrets:
keys, tokens, oauth, passwords, or anything else that grants access.
allowed_actions:
normal jobs the agent can help with.
blocked_actions:
hard stops.
next_review:
the date you check the setup again.don’t paste the real api key into this file.
write the category and storage location instead.
run the built-in audit
openclaw already gives you security checks.
run the standard audit:
openclaw security audittry the deeper scan next:
openclaw security audit --deepuse json output when a script or ci job needs to read the result:
openclaw security audit --jsonthe security docs say the audit checks common footguns such as gateway auth exposure, browser control exposure, elevated allowlists, filesystem permissions, permissive exec approvals, and open-channel tool exposure. those docs also say --fix stays intentionally narrow. it can flip common open group policies to allowlists, restore sensitive-log redaction, and tighten file permissions, but it doesn’t rotate tokens, disable tools, change gateway bind or auth choices, remove plugins, or remove skills.
those limits are healthy.
machine checks don’t know your operating intent.
your registry records the intent.
both belong in the workflow.
upgrade the registry when real work enters
the starter file works for day one.
client files, production repos, admin dashboards, business workflows, payments, crm access, or shared team channels need more detail.
registry_version: "0.2"
owner: "josh"
last_reviewed: "2026-05-19"
default_policy:
external_send_requires_approval: true
destructive_actions_blocked: true
memory_writes_need_reason: true
production_access_default: "blocked"
existing_browser_session_default: "blocked"
agents:
- id: "oc-main-assistant"
name: "main openclaw assistant"
status: "active"
owner: "josh"
purpose: "operator assistant for messages, research, admin prep, and workflow review"
runtime:
host: "mac-mini-m4"
os_user: "openclaw"
gateway: "local"
environment: "personal"
trust_boundary:
boundary_name: "josh-personal"
shared_with_untrusted_users: false
separate_gateway_required: false
channels:
- name: "telegram"
policy: "allowlist"
allowed_senders:
- "josh"
- name: "whatsapp"
policy: "allowlist"
allowed_senders:
- "josh"
tools:
- name: "browser"
mode: "managed-profile"
approval: "ask-before-login"
risk: "medium"
- name: "file-system"
scope: "~/.openclaw/workspace"
approval: "ask-before-write-outside-workspace"
risk: "medium"
- name: "shell"
scope: "disabled-until-needed"
approval: "always-ask"
risk: "high"
mcp_servers:
- name: "github"
status: "planned"
credential_owner: "josh"
allowed_repos:
- "none yet"
risk: "high"
memory:
source_of_truth:
- "~/.openclaw/workspace/MEMORY.md"
save_policy: "save durable facts only when source and reason are clear"
review_cadence: "weekly"
poison_review: true
automations:
- name: "heartbeat"
cadence: "30m"
action_limit: "observe-only unless approved"
blocked_actions:
- "send external messages without approval"
- "delete files"
- "rotate secrets"
- "modify production"
- "purchase anything"
- "connect new mcp server without registry update"
review:
owner: "josh"
last_reviewed: "2026-05-19"
next_review: "2026-05-26"
evidence_required:
- "openclaw security audit output"
- "enabled tools list"
- "channel allowlist check"
- "active mcp server list"
- "browser profile check"runtime shows where the agent lives.
trust boundary explains who belongs near that gateway.
tool scope limits the action area.
mcp entries expose outside tool systems entering the setup.
review evidence keeps the file from turning into dead documentation.
openclaw’s security docs are direct about trust boundaries. one gateway is meant for one trusted user or trust boundary, and mutually untrusted users should be split across separate gateways, credentials, and ideally separate os users or hosts.
write that down before a shared setup gets messy.
forgotten access causes more damage than a bad prompt
bad prompts fail loudly.
old permissions fail quietly.
a browser profile may still be logged into an admin dashboard.
shell access might remain enabled after one test.
memory may hold a stale client rule.
an mcp server may keep a token longer than expected.
group access may include people who were never meant to steer a tool-enabled agent.
your first review question should be blunt:
does this agent still need this access this week?mark the permission disabled, planned, or blocked when the answer is no.
future usefulness is not a reason to keep risky access alive.
give memory a human owner
openclaw memory is plain markdown on disk. the docs say the model only remembers what gets saved to disk, with no hidden state. MEMORY.md holds long-term facts, preferences, and decisions, while memory/YYYY-MM-DD.md stores running context and observations.
inspectable memory is a strength.
saved text still needs judgment.
saved does not mean true.
written does not mean current.
stored does not mean safe to reuse everywhere.
use this prompt once a week:
review this openclaw memory file as an operator.
your job is to find entries that should not be trusted yet.
check for stale facts, missing sources, vague preferences, old commands, global memory that should be project-specific, sensitive details that should not be reused, policy conflicts, and facts that need human confirmation.
return these categories:
- keep
- edit
- delete
- move to project-specific memory
- needs human confirmation
don't rewrite the memory file yet.
produce the review list only.new users should read MEMORY.md once per week.
experienced operators should review memory before enabling browser, shell, github, crm access, payments, or new mcp servers.
run a registry review script
this script reads your registry.
it does not inspect openclaw internals.
its job is narrower: find stale reviews, missing owners, risky tools without approval rules, suspicious browser profile notes, and mcp entries missing ownership.
install pyyaml:
python3 -m pip install pyyamlsave the script as:
registry_review.py#!/usr/bin/env python3
import sys
import yaml
from datetime import datetime, date
HIGH_RISK_TOOLS = {
"shell",
"exec",
"browser",
"file-system",
"mcp",
"github",
"payments",
}
def parse_date(value):
if not value:
return None
if isinstance(value, date):
return value
try:
return datetime.strptime(str(value), "%Y-%m-%d").date()
except ValueError:
return None
def load_registry(path):
with open(path, "r", encoding="utf-8") as file:
return yaml.safe_load(file) or {}
def tool_needs_approval(tool):
name = str(tool.get("name", "")).lower()
risk = str(tool.get("risk", "")).lower()
approval = str(tool.get("approval", "")).lower()
high_risk_name = name in HIGH_RISK_TOOLS
high_risk_label = risk == "high"
approval_exists = "ask" in approval or "disabled" in approval or "always" in approval
return (high_risk_name or high_risk_label) and not approval_exists
def main():
if len(sys.argv) != 2:
print("usage: python3 registry_review.py openclaw-agent-registry.yaml")
sys.exit(1)
registry = load_registry(sys.argv[1])
agents = registry.get("agents", [])
today = datetime.utcnow().date()
findings = []
for agent in agents:
agent_id = agent.get("id") or agent.get("name") or "unknown-agent"
if not agent.get("owner"):
findings.append((agent_id, "missing owner"))
review = agent.get("review", {})
next_review = parse_date(review.get("next_review") or agent.get("next_review"))
if not next_review:
findings.append((agent_id, "missing next review date"))
elif next_review < today:
findings.append((agent_id, f"review overdue since {next_review}"))
if not agent.get("blocked_actions"):
findings.append((agent_id, "no blocked actions listed"))
for tool in agent.get("tools", []):
if tool_needs_approval(tool):
tool_name = tool.get("name", "unknown")
findings.append((agent_id, f"high-risk tool lacks approval rule: {tool_name}"))
browser = agent.get("browser") or {}
browser_profile = str(browser.get("profile", "")).lower()
risky_browser_words = ["existing", "real", "personal", "default chrome"]
if any(word in browser_profile for word in risky_browser_words):
findings.append((agent_id, "browser profile may reach real signed-in accounts"))
for server in agent.get("mcp_servers", []):
server_name = server.get("name", "unknown")
if not server.get("status"):
findings.append((agent_id, f"mcp server missing status: {server_name}"))
if not server.get("credential_owner"):
findings.append((agent_id, f"mcp server missing credential owner: {server_name}"))
if not findings:
print("registry review passed")
return
print("registry review findings:")
for agent_id, finding in findings:
print(f"- {agent_id}: {finding}")
sys.exit(2)
if __name__ == "__main__":
main()run it:
python3 registry_review.py ~/.openclaw/operator/openclaw-agent-registry.yamlfix the registry before changing the live setup.
that order matters.
otherwise you end up editing the machine while the map stays wrong.
keep a weekly review file
copy this into:
weekly-openclaw-registry-review.mdweekly openclaw registry review
date:
reviewer:
agent:
channels:
write down every app, webhook, dm, group, or account that can reach this agent.
tool access:
name the enabled tools. mark the riskiest one. remove anything the agent does not need this week.
browser:
record the profile name. confirm whether it is separate from your personal browser. note signed-in accounts without storing passwords.
files:
write the read scope and write scope. check whether any output landed outside the expected workspace.
memory:
review new entries since the last check. mark questionable entries as edit, delete, move, or confirm.
mcp:
name active servers. record credential owner, reachable resources, and risk level.
automations:
list scheduled runs. describe what happens if one fires at the wrong time.
blocked actions:
check whether temporary permissions became normal by accident.
evidence:
paste the latest security audit summary.
add channel status notes.
add active tool notes.
add memory review notes.
decision:
keep as-is:
tighten:
disable:
delete:
review again on:don’t make the review beautiful.
use it like a workbench.
pretty documentation dies fast.
operator notes survive because they help you make decisions.
package this as a service
“i’ll install openclaw” is easy to underprice.
a registry audit is easier to explain.
use this offer if you help clients with openclaw:
i'll inventory your openclaw setup, map every agent and tool, review browser and mcp exposure, separate trust boundaries, check memory discipline, run the built-in security audit, and leave you with a registry your team can maintain.founders don’t need every plugin detail.
one question lands faster:
what has access to what?that question is worth money.
what this won’t fix
a registry won’t sandbox unsafe tools.
one shared gateway still doesn’t become true per-user isolation.
old secrets need rotation outside the registry.
public endpoints still need proper network decisions.
separate os users, separate hosts, allowlists, private ingress, and real security review still matter.
memory entries still need a human looking at them.
openclaw’s own security guidance points in the same direction: run audits regularly, use the smallest access that still works, and split trust boundaries when different users or environments should not share authority.
the registry gives you a habit.
without that habit, the stack gets useful faster than your memory keeps up.
start here
make the registry file.
add one agent.
fill in channels, tools, browser profile, memory path, secret categories, blocked actions, and next review date.
run the audit:
openclaw security auditremove one permission the agent doesn’t need this week.
more agents can wait.
first, make sure the one already running isn’t carrying access you forgot you gave it.
This is by far the most useful post I’ve read this month. We know we need to fill security gaps. This
post gives us a playbook. Thank you. 🙏
we already have all the tools we need! just a matter of orchestrating better