Who Watches the Agents? Enterprise Governance Across 7 AI Agent Platforms

The Governance Problem

AI agents are no longer toys. They execute shell commands, write files, call APIs, spend money, and make decisions. In a personal context, a mistake is annoying. In an enterprise context, a mistake is an incident — a leaked API key, a deleted production database, an unauthorized charge.

AllClaws analyzed the governance architectures of 7 tracked platforms to understand how the ecosystem is solving the “who watches the agents” problem. The results reveal four distinct governance dimensions, each solved differently, with no single platform covering all of them.

Dimension 1: Credential Isolation — Can the Agent Steal Your Keys?

An agent needs credentials to do useful work. It needs API keys to call external services, OAuth tokens to access user accounts, database passwords to run queries. But an agent that holds raw credentials can leak them — through error messages, through logs, through prompt injection attacks that trick it into exfiltrating secrets.

Four approaches exist in the wild, ranked by how close the agent gets to raw credentials:

IronClaw: The Agent Never Touches Them

IronClaw’s WASM-based tool execution creates a hard boundary between the agent and the host system. Credentials live in an encrypted PostgreSQL vault (AES-256-GCM with per-secret HKDF-SHA256 key derivation). When a WASM tool needs to make an HTTP call, the host process:

Checks the tool’s allowed_secrets list
Decrypts the credential in memory (never inside WASM)
Injects it directly into the HTTP request
Scans the response for credential leakage before returning it to the agent

The agent code physically cannot access the credential. The WASM sandbox boundary is a memory boundary — there is no pointer to follow, no environment variable to read, no file to open. And every credential access is logged to a secret_usage_log database table with the tool ID, user ID, and target host.

This is the gold standard. No other platform achieves this level of isolation.

HiClaw: The Credentials Never Enter the Container

HiClaw takes a different approach with the same outcome. Each worker agent runs in a Docker container. When a worker needs to call an external service (GitHub, Slack, a database), it invokes mcporter — a CLI tool that routes the request through the Higress AI Gateway. The gateway injects the credentials. The worker container has zero secrets.

Worker → mcporter → Higress Gateway → MCP Server
                          ↑
                   GitHub token injected here

If an attacker compromises the worker container, there are no credentials to steal. The credential lives only in the gateway configuration, which the worker cannot access.

GoClaw: Encrypted at Rest, Validated at Injection

GoClaw encrypts API keys with AES-256-GCM before storing them in PostgreSQL. But unlike IronClaw, the agent does see credentials at runtime — they’re decrypted and passed to MCP servers as environment variables.

Where GoClaw excels is in validating which environment variables can be injected. Its env_denylist.go blocks 25+ dangerous variables:

Path hijacking: LD_PRELOAD, LD_LIBRARY_PATH, LD_AUDIT
Interpreter injection: NODE_OPTIONS, NODE_PATH, PYTHONPATH, PYTHONHOME
Shell injection: BASH_ENV, ENV (Shellshock-class vectors)
Git manipulation: GIT_SSH_COMMAND, GIT_SSH, GIT_CONFIG_SYSTEM
System overrides: PATH, HOME, USER, SHELL, PWD

This denylist is a direct response to real attack vectors. An agent that injects LD_PRELOAD=/tmp/evil.so into an MCP server’s environment can hijack any shared library call. GoClaw blocks this at the validation layer.

Hermes: Filter and Scan

Hermes takes the lightest approach: only explicitly configured env keys are passed to MCP server subprocesses (no blanket inheritance), and MCP server packages are checked against the OSV vulnerability database before startup. This is adequate for personal use but lacks the cryptographic guarantees of IronClaw or the proxy isolation of HiClaw.

Dimension 2: Human-in-the-Loop — Who Approves Dangerous Actions?

When an agent wants to run rm -rf /tmp/old_builds or write to ~/.ssh/authorized_keys, someone needs to say yes. But “someone” ranges from “the user, right now, in their terminal” to “a separate admin, via a messaging platform, 30 seconds later.” Five distinct patterns emerged.

Hermes: The Unconditional Floor

Hermes is the only platform with a hardline blocklist that no configuration can bypass. Even YOLO mode (--yolo), which auto-approves dangerous commands, cannot override the hardline patterns:

HARDLINE_PATTERNS (unconditional block):
  rm -rf /, mkfs, dd of=/dev/sd*, fork bombs, kill -1, 
  shutdown, reboot, sudo -S password guessing

DANGEROUS_PATTERNS (approval-gated, YOLO can bypass):
  writes to ~/.ssh/, ~/.hermes/.env, ~/.hermes/config.yaml,
  shell RC files, credential files, /etc/

This two-tier system is elegant: some commands are too dangerous to allow even with user consent (hardline), while others are dangerous but legitimately needed (approval-gated). The user decides their risk tolerance for the second tier; the platform enforces an unconditional floor for the first.

For write approvals (memory, skills), Hermes stages changes to ~/.hermes/pending/ and reviews via /memory pending or /skills pending — asynchronous, non-blocking, reviewable after the fact.

IronClaw: The Composable Gate Pipeline

IronClaw’s approval system is a priority-sorted pipeline of independent gates:

Gate	Priority	Role
RateLimitGate	50	Per-user per-tool rate limiting
RelayChannelGate	80	Auto-deny approval-requiring tools on non-interactive channels
ApprovalGate	100	Core human approval check
AuthenticationGate	200	Credential presence verification
HookGate	300	BeforeToolCall extension hooks

First Pause or Deny wins. This is the most extensible design — new governance policies can be inserted as additional gates without touching the core approval logic.

Four execution modes change how gates evaluate:

Interactive: Pause for approval (default)
InteractiveAutoApprove: Auto-approve “unless auto-approved” tools; still pause for “always” tools
Autonomous: Allow most tools; deny “always” tools entirely (cannot run autonomously)
Container: Allow all (trusted environment)

The Autonomous mode is the key insight: some operations are too dangerous to run without a human, period. An autonomous agent simply cannot execute them — it gets a Denied response, not a Pause.

AgentScope: The Mode System with a Bypass Immune Flag

AgentScope introduces five permission modes (DEFAULT, EXPLORE, ACCEPT_EDITS, BYPASS, DONT_ASK) and a critical innovation: the bypass_immune flag on ASK rules.

A bypass_immune ASK is an operation so dangerous that no allow rule can auto-approve it, and even BYPASS mode must prompt the user. In DONT_ASK mode (no user available), it’s converted to DENY rather than silently allowed.

This is the safety valve that every other platform lacks. Hermes’ hardline blocklist is binary (block everything matching), but AgentScope’s bypass-immune flag is per-operation and mode-aware — it allows fine-grained “this specific action is always dangerous” policies without a global blocklist.

GoClaw: Five Layers of Enterprise RBAC

GoClaw’s governance is built on hierarchical roles — Owner > Admin > Operator > Viewer — and five layers of permission evaluation:

Gateway auth (token scopes: admin, read, write, approvals, pairing, provision)
Global tool policy (allow/deny lists, tool profiles)
Per-agent policy (each agent can have its own tool restrictions)
Per-channel policy (each messaging channel can restrict tools)
Owner-only tools (some tools require the sender to be the owner)

The system is fail-closed by design: unclassified API methods return RoleNone, which is denied for everyone. This prevents a misconfiguration from accidentally granting access to unauthenticated users.

Nanobot: No Human Needed

Nanobot takes a radically different approach: no interactive approval at all. Instead, it relies on bubblewrap (bwrap) sandboxing — read-only system mounts, tmpfs workspace, process isolation. Commands are evaluated against static deny patterns (blacklist) and allow patterns (whitelist). If a command matches the deny list, it’s blocked. If it doesn’t match either, it’s executed. No human is asked.

This is the “sandbox everything” philosophy: instead of asking permission for each dangerous action, make the environment safe enough that dangerous actions don’t matter. Simpler, more scalable, but less flexible — you can’t do things the sandbox doesn’t allow, even with approval.

Dimension 3: Multi-Tenant Authorization

GoClaw: Per-Tenant MCP Grants

GoClaw’s multi-tenant model extends to MCP tools. Each tenant can have an allow/deny list for MCP servers:

Tenant A: allow [filesystem, github], deny [postgres]
Tenant B: allow [postgres], deny [slack]
Tenant C: no filter (all tools visible)

Semantics: deny takes priority; non-empty allow means only listed tools are visible; empty allow+deny means no filter. Non-allowed tools never reach the LLM — they’re filtered at registration time.

IronClaw: Cryptographic Agent Identity

IronClaw’s 13-PR attested signing chain gives agents a cryptographic identity — they prove who they are via wallet-based signing (WebAuthn → wallet → chain signing). Agent actions are attested on-chain, creating a tamper-evident audit trail.

In multi-tenant mode (is_multi_tenant_deployment), admin tool policy filtering activates, and per-tenant rate limits are enforced via TenantRateRegistry.

HiClaw: Kubernetes CRDs as Agent Identity

HiClaw expresses agent identity as Kubernetes Custom Resource Definitions: Worker, Manager, Team, and Human. Each is a first-class Kubernetes object with spec, status, and lifecycle management. RBAC, audit, and scaling all leverage the Kubernetes operator ecosystem.

Human participants are also CRDs — a Human object has a role, a Matrix ID, and lifecycle. This is the only platform where “who is the human” is expressed as infrastructure, not configuration.

The Governance Maturity Matrix

Dimension	GoClaw	IronClaw	HiClaw	Hermes	NanoClaw	Nanobot	AgentScope
Credential isolation	★★★	★★★★★	★★★★	★★	★★★	★★	★
HITL approval	★★★★	★★★★	★★★	★★★★★	★★★	★★	★★★★
Multi-tenant RBAC	★★★★★	★★★★	★★★★	★	★★	★	★★★
Agent identity	★★	★★★★★	★★★★	★	★★	★	★
Audit trail	★★★	★★★★★	★★	★	★★★	★	★

No platform scores 4+ on all dimensions. The closest:

IronClaw — 5 on credentials and identity, 4 on RBAC and HITL
GoClaw — 5 on RBAC, 4 on HITL, 3 on credentials and identity

These two platforms are converging on the enterprise gateway position from opposite directions: IronClaw from security/identity, GoClaw from multi-tenancy/operations.

The Unfilled Gap

The ideal enterprise agent governance system would combine:

IronClaw’s WASM credential isolation (agent never sees secrets)
Hermes’ two-tier dangerous/hardline approval (unconditional floor + approval-gated)
GoClaw’s 5-layer multi-tenant RBAC (per-tenant tool visibility)
AgentScope’s bypass-immune mode system (operations too dangerous to auto-approve)
HiClaw’s Kubernetes-native agent identity (CRD-based lifecycle)

No platform has integrated all five. The first to do so will define the enterprise agent governance standard — and likely capture the enterprise market in the process.

What This Means for the Ecosystem

The governance landscape in 2026 looks like the security landscape of web applications in 2010: everyone agrees it matters, approaches are fragmented, and the “obvious” best practices haven’t yet consolidated.

Three predictions for the next 12 months:

The bypass-immune pattern will spread. AgentScope’s per-operation “too dangerous to auto-approve” flag is the most important governance innovation this year. Every approval system needs it. Expect Hermes, IronClaw, and GoClaw to adopt variants within 6 months.
Credential proximity will become a selling point. Today, “the agent never sees your credentials” is IronClaw’s differentiator. Tomorrow, it will be table stakes. Platforms that pass raw credentials to agent code will face enterprise procurement rejection.
Kubernetes-native agent identity will accelerate. HiClaw’s CRD model treats agents as first-class infrastructure objects. As enterprises adopt agent platforms, expressing agent identity, RBAC, and lifecycle in Kubernetes terms (the language their ops teams already speak) will drive adoption.

The platforms that treat governance as a first-class architectural concern — not a feature checkbox — will be the ones enterprises trust with production workloads.

Full analysis: Enterprise Governance Frameworks Analysis

Related research: