OpenClaw has shipped its most significant update yet—version 2026.8.1 (aka OpenClaw 2.0)—featuring sweeping security enhancements aimed at AI agents, plugins, credentials, and enterprise workflows. Built over nearly two months by a community of 933 contributors (569 of whom are first-timers), this release includes over 16,000 pull requests spanning every major component of the platform. It marks a pause in OpenClaw’s former breakneck cadence—106 releases over 230 days—in order to lay down stronger foundations and provide safer upgrade paths for users.
Credential Management Gets Leaner — and Safer
One of the biggest shifts in OpenClaw 2.0 is how credentials are handled. A private credential request feature lets an agent ask for secrets without exposing them in conversations or model context. Teams can also limit secret substitution to trusted endpoints via an opt-in proxy, cutting down surfaces where credentials might leak. A shared credential store is now available to team environments, backed via SQLite through the CLI and settings interfaces—values are write-only by default, and administrators can bind protected outbound requests to declared hosts. For tighter workflow, OpenClaw now optionally supports integration with 1Password as a broker; this adds curated secret references, service-account authentication, per-secret approval flows, and audit logging without ever revealing the raw secret value.
Plugin, Agent and Workspace Security All Upgraded
The update also imposes stricter review before plugins are enabled or installed: before users proceed, they’ll see details like capability, source, version, and “artifact” metadata. If a plugin comes from an arbitrary executable source, users must pass a –force flag. Plugins from approved origins like trusted catalogs can bypass certain provenance warnings—though still require explicit consent on capabilities. ClawHub packages are now surfaced with security audit details during the install flow, improving visibility into plugin integrity.
Agent execution inherits tighter controls too. OpenClaw introduces explicit session permission modes and workspace restrictions: filesystem access is limited to the agent’s recorded workspace or “worktree,” preventing it from accessing files outside permitted boundaries. In team settings, operator roles can now restrict users’ access to agents, sessions, and administrative features. Importantly, these are collaboration tools—not full isolation for hostile-multi-tenant deployments. Automation likewise gets a security boost: workflows that require approval must be explicitly consented to once, visible later for review or revocation, and changes to previously approved operations trigger re-approval.
Other Defensive Measures & UX Improvements
OpenClaw 2.0 also brings enhancements outside core credential or plugin security. These include model allowlists, configuration-change history with sensitive-value redaction, safer database recovery, and tools for sanitizing prompt context so private information doesn’t accidentally leak in live or streaming replies. On the usability side, the browser UI has been rebuilt as the primary workspace, and shared cloud sessions, browser workflow controls, agent dashboards, and expanded support for both local and external model providers have all been upgraded.
Organizations using OpenClaw agents with production credentials, messaging integrations, or cloud execution paths are especially urged to perform staged rollouts and careful security reviews. Given the scale of changes, unnoticed misconfigurations or legacy settings could present risks during the transition.
As AI agents proliferate in enterprises, protecting secrets, limiting plugin risks, and bounding agent capabilities are no longer optional—they’re essential. OpenClaw 2.0 raises the bar for open-source agent platforms in securing credentials, workflows, and plugins. What to watch next: how well these features hold up under real-world adversarial testing, whether performance remains acceptable under constraints, and how collaboration vs. isolation trade-offs are handled in multi-tenant scenarios.
