OpenClaw vs Claude Code — How NHI Differs Across AI Agent Frameworks

OpenClaw and Claude Code are both production-grade AI coding/agent tools that ship today, but they take very different approaches to identity, credentials, and tool execution. This post is an honest, side-by-side look at the NHI shape of each — written by the team that builds the credential layer underneath both.

Important up front: this is not a "which is better" piece. They're built for different problems. The point is that those different design choices push different responsibilities onto the operator, and if you're running both, you need to understand which is which.

The TL;DR table

The two columns push the operator in different directions. Claude Code makes you trust the developer; OpenClaw makes you trust the credential.

Where Claude Code lives in the NHI taxonomy

Claude Code is a tool a developer runs from their terminal. The credential is an Anthropic API key that lives somewhere accessible to the developer — ~/.claude/, an environment variable, or pulled from a secrets manager.

From a Non-Human Identity perspective, Claude Code is partially human-driven. The agent doesn't take action without a human watching:

• Tool calls show a prompt before execution (file edits, shell commands, network calls)
• The developer can Esc out at any point
• Approvals are interactive, not queued
• The session ends when the developer closes the terminal

This is excellent UX for active development, but it changes how you think about credentials. The credential the agent uses is, effectively, the developer's credential — scoped to whatever the developer can see, operating only when the developer is actively invoking it.

What this implies for NHI:

• You scope the developer, not the agent. The same boundaries that apply to "what can this developer's CLI token read" apply to "what can Claude Code read while they're using it."
• Audit lives at the credential layer. Claude Code itself doesn't keep a long-term audit; the audit lives in whatever secrets/API systems it talks to.
• Shadow detection still matters — Claude Code traffic shows up with a claude* user-agent. If a developer's CLI token is used with the Claude Code user-agent, you'll see it in nhi/shadow-agents with framework=claude-code.

The natural mistake here is treating Claude Code traffic as if it were autonomous-agent traffic. It isn't, mostly — it's developer traffic with extra capabilities. The credential governance you'd apply to a senior developer's CLI access is roughly the right model.

Where OpenClaw lives in the NHI taxonomy

OpenClaw is fundamentally different. It's an autonomous agent designed to plan tasks and act on them — often without a human in the loop for every step. The credential bundle lives wherever the OpenClaw deployment runs: a server, a container, a VM, a teammate's laptop. It can run for hours, days, weeks.

This makes OpenClaw a first-class NHI. It is the canonical example of the thing NHI tooling is built for:

• It needs its own identity, not a borrowed human one
• It needs scoped, expiring credentials
• It needs explicit governance for the actions it can take
• It needs audit independent of any human session

The default OpenClaw setup doesn't provide any of those — it asks you to paste credentials into a config file and call it done. That's the gap that prompted this post (and the OpenClaw posture checklist).

What this implies for NHI:

• You scope the agent. Per-agent identities, per-agent allowlists, per-agent expiries.
• Audit at the agent layer is non-negotiable. Every secret read and every tool call needs to be tied back to the specific OpenClaw agent that did it, not the developer who happened to deploy it.
• Approval flows have to be asynchronous. Unlike Claude Code, the developer isn't sitting at the terminal. When delete_repo needs approval, the call has to queue, an admin has to decide, and the agent has to retry. This is exactly the pattern in OpenClaw MCP approval queues.
• Shadow detection is critical. Anyone in your org who deploys OpenClaw with a personal credential is creating a shadow NHI. The detection is mechanical (user-agent pattern matching) but the posture impact is large.

The same credential layer, different surface area

If you're running both — most teams using AI tooling are — the credential layer can be shared. secr exposes the same agent-identity primitive for both, with different recommended defaults:

For Claude Code seats: mostly use the developer's CLI token, with shadow-agent detection enabled so unusual user-agent activity stands out. Pair with the standard NHI posture rules (token expiry, ownership, brownout pattern).

For OpenClaw deployments: create a dedicated secr_agent_* per deployment with project scope, environment scope, and a tight secretAllowlist. Wrap tool calls with OpenClawGateway. Mark dangerous tools as approval-required. Run the OpenClaw-specific posture rules.

The mistake people make is reaching for the same governance for both. They're not the same shape:

• Treating Claude Code like an autonomous agent leads to over-rotating credentials and friction for developers.
• Treating OpenClaw like a developer tool leads to plaintext credentials, no allowlist, no audit, and a future incident.

A concrete decision tree

If you're standing up new AI tooling and asking what's appropriate:

Is the agent triggered by a human and observed by a human? → Claude Code shape. Scope the human's credentials. Make sure shadow detection is on.

Is the agent triggered by a schedule, a webhook, or another agent? → OpenClaw shape. Create a per-agent identity. Allowlist the secrets. Wrap the tools.

Is the agent a long-running daemon that takes autonomous actions? → OpenClaw shape, but stricter. Per-environment identity, IP allowlisting, business-hours conditional access, and approval-required for anything destructive.

Is the agent something in between (e.g. a developer occasionally hands it off and walks away)? → Treat the "walks away" case as the source of truth. If the agent can act when the developer isn't watching, govern it like an autonomous agent.

What's likely to change

A few directions things are moving:

• OpenClaw is converging on built-in secret-broker support. The IDENTITY.md spec is gaining structure for credential bindings. This will close the worst version of the credential-in-config-file problem at the framework level.
• Claude Code is getting better at being an autonomous agent, not just an interactive one. As that line blurs, the NHI thinking has to follow — long-running Claude Code sessions need the same treatment as OpenClaw deployments.
• MCP is becoming the lingua franca for tool calls across both frameworks. That's why the MCP gateway accepts arbitrary string tool names: governance written for one framework should apply to the next.

The credential layer underneath stays the same. What changes is which agents fall into which side of the table.

What you should do now

Two small actions, regardless of which framework you're running more of:

1. Run the OpenClaw posture checklist against your current deployment. Most of it applies to autonomous-agent setups regardless of the specific framework.
2. Turn on shadow-agent detection if it isn't already. It's free, it's low-overhead, and it's the only way to catch "someone in our org spun up Claude Code / OpenClaw with their personal token" before the next audit.

The frameworks will keep evolving. The credential discipline doesn't change much.

---

See also:

• Securing OpenClaw Agents — the conceptual NHI framing
• Why plaintext .env files are failing OpenClaw
• Detecting shadow OpenClaw agents

---

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