The OpenClaw NHI Posture Checklist

This is the practical version of "is our OpenClaw deployment safe?" Twelve checks, each with a clear pass/fail, the reason it matters, and how to fix it.

If you're new to OpenClaw NHI, start with Securing OpenClaw Agents for the conceptual framing. If you're here to run an audit, work down the list.

1. Every OpenClaw agent has a typed agent identity

Pass: The agent authenticates with a secr_agent_* token.

Fail: The agent uses a personal CLI token (secr_tok_*), a session cookie, or some other shared credential.

Why: Agent identities are a separate primitive from human credentials. They have their own lifecycle (disabled → brownout → revoked), their own audit trail, and their own scoping fields.

Fix: Create a scoped agent identity, transfer the agent's deployment to use it, then revoke the personal credential it was using.

2. Every agent identity has a project scope

Pass: projectId is set on the agent.

Fail: projectId is null — the agent has org-wide access.

Why: OpenClaw agents are usually purpose-built (SlackBot, SupportTriage). They don't need to read across projects. An unscoped agent has more blast radius than necessary.

Fix: secr agent update <id> --project <name> (or recreate with the project flag).

3. Every agent identity has an environment scope

Pass: environmentId is set on the agent.

Fail: environmentId is null — the agent can read across dev/staging/prod.

Why: Cross-environment scope is the most common cause of "the dev token leaked, but it had access to prod secrets."

Fix: Create one agent identity per environment. Yes, it's three rows instead of one. That's the point.

4. Every agent identity has a secret allowlist

Pass: secretAllowlist is a non-empty array of specific secret keys.

Fail: secretAllowlist is null (unrestricted) or [] (deny-all, which is rarely intended).

Why: Most agents only need a handful of named credentials. Allowlisting limits the blast radius if the token leaks. See OpenClaw secret allowlists.

Fix: secr agent update <id> --allowlist KEY1,KEY2,KEY3 — list only the keys this agent's code actually reads.

5. Every agent identity has an expiry

Pass: expiresAt is set, ideally within 90 days.

Fail: expiresAt is null.

Why: Forever-credentials are forgotten credentials. An expiring credential forces a rotation conversation at least quarterly.

Fix: secr agent update <id> --expires 90d. For high-privilege agents, prefer 30d.

6. Every agent identity has an owner who is still in the org

Pass: ownerId references an active member.

Fail: The owner has left (membership deleted or marked inactive).

Why: When something goes wrong with an OpenClaw agent, you need a human accountable for it. Orphaned agents are how production incidents at 2am turn into "nobody knows what this does."

Fix: Transfer ownership: secr agent transfer <id> --owner <new-user-email>. Or revoke and recreate.

7. The agent's traffic comes from expected IP ranges

Pass: The agent has allowIps set, or its observed IPs are consistent with the planned deployment topology.

Fail: Anomalous IPs (different country, different cloud provider) appear in the access log.

Why: Stolen agent tokens replay from somewhere unexpected. IP allowlists fail closed when that happens.

Fix: secr agent update <id> --allow-ips 10.0.0.0/8,52.x.y.z/24 or the equivalent CIDR for your deployment region.

8. Tool calls are wrapped in the MCP gateway

Pass: Tool invocations go through OpenClawGateway.wrap and produce mcp_tool_calls audit rows.

Fail: Tool calls happen but no audit rows exist.

Why: Without the gateway, you have no record of what the agent did — only what it read. The action audit is the part that matters when something goes wrong.

Fix: Wrap each tool function with gateway.wrap(toolName, handler). See the getting-started guide.

9. Dangerous tools require approval

Pass: A require_approval rule exists for destructive / financial / customer-visible tools, scoped to production environments.

Fail: The agent can call delete_repo, refund, send_email, etc. without any human in the loop.

Why: The cost of a wrong action by an autonomous agent is unbounded. The cost of a 30-second human approval is 30 seconds. See MCP approval queues.

Fix: Create a require_approval rule in the dashboard naming the tools and the production environment.

10. The agent's user-agent identifies its framework

Pass: The OpenClaw deployment sets a recognisable User-Agent header (e.g. openclaw/1.2.3).

Fail: The User-Agent is blank or generic (node-fetch/2.0, no header at all).

Why: Shadow-agent detection and posture rules depend on knowing the framework. A blank user-agent renders the framework column as null and the OpenClaw posture rules can't fire.

Fix: Most OpenClaw runtimes set this automatically. If yours doesn't, configure the SDK to send a custom user-agent. The default @secr/openclaw integration handles this for you.

11. There are no shadow OpenClaw agents in the org

Pass: /dashboard/nhi/shadow-agents filtered to framework=openclaw shows zero active entries.

Fail: One or more amber-badged rows are sitting in the active list.

Why: A shadow agent is an OpenClaw deployment using a personal credential. Every one is a future incident. See shadow-agent detection.

Fix: For each shadow row: identify the owner, decide if the agent should exist, then either resolve (link to a proper agent identity) or revoke the underlying credential.

12. The compliance report has zero OpenClaw findings

Pass: /dashboard/nhi/compliance shows no recommendations starting with OpenClaw-fingerprinted agent....

Fail: One or more recommendations like OpenClaw-fingerprinted agent "X" is missing scoping (projectId, secretAllowlist).

Why: This is the cross-check between your registered agents and your actual OpenClaw traffic. A finding here means an agent the org has approved is misconfigured for the framework it's actually running.

Fix: Each finding lists what's missing. Apply rules 2, 3, and 4 to that specific agent.

A 60-second self-audit

Run these three queries and you'll know where you stand:

# How many agent identities lack a project scope?
secr agent list --json \
  | jq '[.[] | select(.projectId == null and .status == "active")] | length'

# How many agent identities lack an allowlist?
secr agent list --json \
  | jq '[.[] | select((.secretAllowlist // []) | length == 0) | .name]'

# How many active shadow OpenClaw agents are there?
secr nhi shadow-agents --json \
  | jq '[.shadowAgents[] | select(.framework == "openclaw" and .status == "active")] | length'

Three numbers. If all three are zero, you're in good shape on the framework hygiene. If any are non-zero, you have your first remediation list.

Where this lives in the product

Most of this checklist is enforced or surfaced automatically:

• Posture rule for missing project / environment / allowlist on OpenClaw-fingerprinted agents — in the compliance report
• Shadow agent detection with framework=openclaw badge — in the shadow agents page
• MCP gateway pending queue for approval-required calls — in the gateway dashboard
• Audit log of every secret read and tool call — exportable from the audit page

You don't need to memorise the checklist. You need to scan the dashboard once a week and clear anything that's red.

---

See also:

• Why plaintext .env files are failing OpenClaw — the news-cycle context for why this matters now
• OpenClaw vs Claude Code — how NHI differs across frameworks

---

The OpenClaw plugin (@secr/openclaw-plugin) is on ClawHub and free for 1 agent. Install reference → · The /agents pillar · Approve tool calls from Telegram · Approval webhooks