FAQ: OpenClaw 2026.3.1–3.7 Security Upgrades and AI SAFE² Governance

17 questions practitioners are asking about the 3.x releases and what they mean for agentic AI security.

1. Why does the 3.x series represent a fundamentally different kind of security work?

Phases 1 through 6 hardened the agent’s own code: its authentication, its sandbox, its execution pipeline, its credential management, its evasion resistance. Phase 7 is the first time the primary threat being addressed is the ecosystem around the agent, the plugins, skills, webhooks, and community extensions that the core team does not author or control. The attack surface has shifted from the product to the platform. This is the same pattern seen in every successful software ecosystem: the kernel hardens, and the adversary moves to the drivers.

2. What is SecretRef and why does expanding it to 64 targets matter?

SecretRef is a mechanism for dynamically resolving credentials at runtime rather than storing them as hardcoded strings in configuration files. Expanding SecretRef to 64 user-supplied credential targets means the vast majority of places where API keys, tokens, and passwords are used now resolve through the managed secrets pipeline instead of reading from static config values. This eliminates a class of vulnerability where credentials appear in plaintext across configuration files, backups, version control, and generated artifacts.

3. What is the gateway.auth.mode breaking change and how does it affect deployments?

When both token and password authentication are configured for the gateway, OpenClaw now requires an explicit gateway.auth.mode declaration. Previously, the system could silently select the weaker method during ambiguous credential evaluation. Deployments that have both auth methods configured will break until the operator explicitly specifies which mode takes precedence. This is a correct security default: authentication strategy should be declared, not inferred.

4. What is the plugin hook injection policy and what attack does it prevent?

The plugins.entries.<id>.hooks.allowPromptInjection flag controls whether a plugin’s hooks can modify the agent’s prompt. Without this policy, any installed plugin could register hooks that inject content into the system prompt, user prompt, or assistant responses, effectively rewriting the agent’s instructions at runtime. A malicious skill from ClawHub could use this vector to override safety instructions, inject exfiltration commands, or alter the agent’s persona without the operator’s knowledge. The policy validates hook names against a registry and strips prompt-mutating fields when injection is disabled.

5. How does AI SAFE²’s TOOLS.md air-gap address plugin risks that hook policies cannot?

Hook policies operate at the runtime level: they inspect what plugins send and filter dangerous content. The TOOLS.md air-gap operates at the architectural level: it physically separates configuration paths from behavioral instructions. A compromised plugin that bypasses the hook policy filter still cannot reach configuration because the two domains are structurally segregated. This is the difference between a guard who checks IDs and a wall that has no door. The policy depends on correct enforcement. The air-gap depends on structural separation.

6. What are prompt-spoof markers and how does OpenClaw neutralize them?

Prompt-spoof markers are text patterns like [System Message] or line-leading System: that attackers embed in user messages to trick the language model into treating the content as system-level instructions. If the model interprets these markers as authoritative, the attacker can override the agent’s persona, safety instructions, or operational constraints. The 3.x releases actively neutralize these markers in untrusted message content and prevent queued runtime events from being injected into user-role prompt text, closing the vector where internal system events could be reinterpreted as user instructions.

7. How does AI SAFE²’s SOUL.md approach differ from prompt-spoof filtering?

Prompt-spoof filtering is syntactic: it matches known marker patterns and removes them. An attacker who discovers a novel marker format or achieves identity override through semantic manipulation rather than explicit markers bypasses the filter. SOUL.md provides structural alignment: the agent’s identity and operational boundaries are maintained by a constitutional document that the agent references as its core operating context. Identity violation creates instability in the agent’s reasoning rather than simply being filtered from input. One approach enumerates attack patterns. The other makes the attack class structurally ineffective.

8. What is the plugin route authentication fix and what was the vulnerability?

Plugins can register HTTP routes on the OpenClaw gateway to expose their own API endpoints. Before this fix, plugin routes could be registered without authentication, routes with mixed authentication states could coexist (allowing fallthrough from authenticated to unauthenticated handlers), and overlapping routes could create alternate paths that bypassed auth checks. An attacker could install a plugin that registered an unauthenticated route overlapping with a sensitive authenticated endpoint, creating a backdoor to the same handler without credentials.

9. What is the archive traversal fix (GHSA-qffp-2rhf-9h96)?

GHSA-qffp-2rhf-9h96 is a vulnerability where crafted tar or zip archives exploit inconsistent safety checks to write files outside the intended extraction directory using hardlink path traversal. The 3.x releases unify tar and zip extraction under a single safety policy that enforces compressed-size limits and uses same-directory temp files with atomic renames. The atomic rename ensures that if extraction fails safety checks, no partial files persist outside the boundary.

10. Why does the persistence hardening for SecretRef matter if secrets are already managed?

The secrets workflow manages credentials through dynamic resolution, secrets are never supposed to be stored as plaintext in config files. However, model generation routines that serialize the agent’s configuration to models.json files were inadvertently resolving SecretRef references and writing the actual secret values to disk as plaintext. This defeated the entire purpose of managed secrets: the credential lifecycle was protected, but a downstream serialization step re-exposed them. The persistence hardening ensures resolved secrets are never written back to generated files.

11. What is auth-before-body webhook parsing and what DoS attack does it prevent?

Traditional webhook processing reads the full request body before checking authentication. An attacker can exploit this by opening connections to webhook endpoints and sending data extremely slowly, occupying server resources for extended periods without ever presenting valid credentials. Auth-before-body parsing reverses this: authentication is checked before any body data is read. Strict pre-auth body and time budgets ensure that unauthenticated connections are terminated before they can exhaust resources. This specifically protects against slow-body denial-of-service attacks targeting Google Chat and BlueBubbles webhook integrations.

12. How does the 800+ malicious skills finding relate to the 3.x security work?

Researchers documented over 800 malicious skills on ClawHub, OpenClaw’s community marketplace, including variants of the Atomic macOS Stealer. This finding demonstrates that the plugin and skill ecosystem is already under active exploitation. The 3.x releases are a direct response: plugin route authentication, hook injection policies, and prompt-spoof neutralization all address vectors through which malicious skills compromise the host agent. The releases are necessary. They are also reactive, the malicious skills existed and were active before these controls were implemented.

13. What are the seven phases of OpenClaw’s security maturity model?

Phase 1 (2026.1.29–2.1): User awareness. Phase 2 (2.13): Code-level fixes. Phase 3 (2.19): Secure defaults. Phase 4 (2.21): Exploit containment. Phase 5 (2.22–2.24): Anti-evasion. Phase 6 (2.25–2.26): Deep boundary enforcement. Phase 7 (3.1–3.7): Ecosystem hardening, securing the platform from its own community-driven extension ecosystem. Each phase addresses a higher-order threat class, progressing from operator education through internal hardening to platform-level supply-chain defense.

14. What compliance gaps remain after the 3.x releases?

OpenClaw’s security improvements are engineering-grade: they reduce exploitability, contain blast radius, and now extend to ecosystem boundaries. They do not produce compliance evidence. There is no immutable audit log with risk scores, no authorization attribution per action, no policy conformance reporting, and no SIEM integration. For organizations subject to ISO 42001, SOC 2, HIPAA, or financial regulatory requirements, the gap between ecosystem hardening and compliance readiness is the gap between engineering confidence and legal defensibility.

15. How does the workspace read-only constraint affect typical deployments?

The primary /workspace bind mount is now read-only by default unless access is explicitly configured to rw. This means skills, plugins, and agent tools that write files to the workspace will fail unless the operator has deliberately granted write access. This is principle-of-least-privilege enforcement at the filesystem level. Most production deployments should review which tools genuinely require write access and configure rw only for those specific paths, keeping the default workspace read-only.

16. How should I sequence the 3.1–3.7 updates with AI SAFE² deployment?

Apply all 3.x updates in staging first, the gateway.auth.mode breaking change and workspace read-only default may require configuration adjustments. Review installed plugins against the new hook injection policy and verify SecretRef migration. Run the AI SAFE² Scanner to assess post-update risk. Deploy the Control Gateway for positional egress enforcement. Implement SOUL.md and IDENTITY.md for structural prompt alignment. Deploy Ghost Files for behavioral governance. Finally, implement the Command Center Architecture for physical data isolation from the ecosystem.

17. What is the most important insight from the 3.x releases?

OpenClaw has reached the ecosystem hardening phase—the point where the primary attack surface is no longer the agent’s own code but its community-driven extensions. This is the platform paradox: success creates the next attack surface. Every plugin, every skill, every webhook integration expands the trust boundary. OpenClaw is now building guardrails to protect the agent from its own ecosystem. That is necessary and impressive. It is also structurally self-referential: the agent is policing the extensions that run inside the agent. External governance, enforcement that operates independently of the runtime being protected is what breaks this circularity. That is what AI SAFE² provides.