Enterprise security and governance baseline: remove URL tokens, separate secrets, add minimal RBAC and audit events

[webup]

Migrated from issue #114, originally opened by @Thalia325. Moved to a discussion for broader design conversation.

Related capability

Security & Governance (能守护)

Problem or motivation

ClawMaster has decent local single-user usability today, but from an enterprise deployment and production-governance perspective the security / governance baseline is incomplete. Concretely:

1. /api today relies primarily on a single shared service token, and still accepts the token via URL query parameters (e.g. serviceToken / token). This leaks tokens into browser history, into reverse-proxy / API gateway / WAF / APM logs, and into anything that captures shared links, triage notes, or terminal output — and makes per-user audit attribution impossible.

2. Dangerous operations do add an extra header check, but the underlying credential is still the same shared token. That makes today's model closer to "local admin mode" than "governable team mode," and violates least-privilege.

3. Configuration is still centered on plain JSON files. openclaw.json carries provider / channel configuration, and .clawmaster/settings.json is part of the same plaintext system. That means secrets and ordinary config aren't layered, backups / exports / migrations drag sensitive data along, there's no unified secret-storage abstraction, and nothing is set up to later adopt keychain / KMS / Vault.

4. Minimal RBAC and a unified audit-event model are missing. The system can't clearly answer: who changed the config, who enabled a given plugin / skill / MCP, who executed reset / restore / uninstall, and for any change — when, against which object, and whether it succeeded.

5. The Capabilities page is more "visibility" than "governance." It shows installed/enabled counts and runtime summaries, but lacks the metadata enterprise governance actually needs: owner, approval state, risk level, last-reviewed, last-changed-by, policy / scope / quota state.

The README already lists vault, RBAC, and spend caps as planned — the direction is recognized but implementation hasn't reached production-grade quality.

Proposed solution

Treat this as a single "enterprise security & governance baseline" initiative, phased.

Phase 1 — Immediately reduce risk

1. Fully remove query-string token support; do not allow serviceToken / token for authentication.
2. Support only Authorization: Bearer ... or an explicit header.
3. Separate dangerous-operation confirmation from ordinary API access — stop reusing a single shared token.
4. Update docs and the CLI / browser-open logic so no more token-carrying URLs get generated.

Phase 2 — Establish minimal secret & permission abstractions

1. Define the boundary of sensitive fields: provider API keys, channel tokens, third-party access credentials, and other fields that must not live in ordinary JSON config.
2. Introduce a secret-storage abstraction: ordinary config stays in JSON, sensitive fields leave ordinary config, first version can be a local implementation with keychain / KMS / Vault later.
3. Introduce minimal RBAC roles: admin, operator, viewer.

Phase 3 — Build governance & audit capability

1. Define a unified audit-event schema covering at least: config change, runtime/profile change, plugin/skill/MCP install/enable/disable, reset / restore / uninstall, secret change.
2. Extend the Capabilities page from a stats page to a governance page with: owner, source, approval state, risk level, last reviewed at, last changed by.
3. Reserve extension points for future enterprise integration: OIDC / SSO, external secret vault, org-level audit aggregation.

Acceptance criteria

• Query-string token authentication no longer works.
• Secrets are no longer co-stored with ordinary JSON config.
• Minimal RBAC and a unified audit-event structure exist.
• The Capabilities page expresses governance metadata, not just installed/enabled counts.

Alternatives considered

1. Keep query-string tokens and just mark "not recommended" in docs — cheap to implement, does not remove real leakage risk.
2. Keep all configuration in JSON files — simple for local single-user, doesn't meet enterprise secret-management and audit needs.
3. Build a full IAM / policy engine from day one — scope is too large, rollout is too long, and it blocks the minimal viable governance baseline.