OpenClaw Main Stops Provider Credentials Crossing Endpoint Boundaries

OpenClaw has merged a coordinated credential-boundary correction across model proxies, memory embeddings, cloud discovery, onboarding and update validation. The common fault was authority crossing ownership: a token selected for one provider, agent, endpoint or process phase could be inherited by another path or appear in plaintext output.

The changes are on main. The supplied records do not identify a containing package, so installed-release operators must first prove inclusion before treating the risk as closed.

The repaired boundary

A credential is not safe merely because it reached an HTTPS request. It must reach only the origin, provider, agent and lifecycle that own it.

Interpretation: these are confused-deputy fixes. The request code may have had valid credentials and a valid destination independently, while lacking proof that the same owner authorized that combination.

Plaintext retention is a separate failure mode

PR #118702 keeps provider credentials represented by supported SecretRef values instead of materialising them into plaintext during onboarding. The fix preserves the reference while updating the surrounding provider profile.

PR #118840 closes another edge: Parallels npm-update validation launched a background Gateway with a provider key present in the shell job command. When the process was killed, a POSIX shell could print that command into captured macOS or Linux phase logs. The generator now keeps the key inside a scoped function rather than the logged job command.

Transport isolation and log hygiene must both hold. A token correctly scoped on the wire can still be compromised if setup, crash or job-control output records it.

Reflected authorization headers are now redacted at error boundaries

PR #119666 closes a remote memory and embedding error path where a non-2xx provider response could reflect the request’s Authorization header into an OpenClaw error. The shared redactor now handles quoted JSON values, case-insensitive bearer schemes, short values and the full token68 character set across JSON POST and multipart-upload failures.

PR #119536 applies forced credential redaction at Discord’s final API-error formatting boundary for JSON and non-JSON responses. That final-boundary placement matters because a proxy or upstream can return text even when the ordinary path expects structured JSON.

Neither source proves that a particular deployment retained a real token. They establish paths where reflected credentials could reach surfaced error details. If affected errors may have been exported, treat logs, traces and support bundles as potentially sensitive until inspected under incident controls.

Who should prioritise this

Treat the containing upgrade as high priority if you use any of the following:

• custom OpenRouter origins or corporate CONNECT proxies;
• automatic fallback between embedding providers;
• Ollama Cloud alongside local or custom Ollama hosts;
• multiple agents or rotating auth with LanceDB-backed memory;
• Bedrock PrivateLink or service-specific AWS endpoint policy;
• multiple Google Cloud SDK configurations or Vertex quota projects;
• referenced provider secrets during onboarding; or
• Parallels-based package update validation.

The OpenRouter PR is labelled P0 upstream; several memory and endpoint fixes are P1 security-boundary changes. Labels are upstream prioritisation, not proof that every deployment is exposed.

Safe acceptance test

Use fake canary credentials and isolated endpoints. Never route production tokens into a test proxy or log collector.

1. Give each provider, agent and endpoint a unique harmless marker token.
2. Exercise primary embedding and forced fallback paths separately.
3. Inspect the receiving test origins and prove each sees only its own marker.
4. Change an agent’s auth and endpoint, then prove a warm LanceDB process does not reuse the retired client.
5. Test Bedrock custom, ordinary regional and FIPS/dual-stack modes independently.
6. Select an explicit Google Cloud SDK directory and verify no credential outside it is read; verify the expected quota project at the test boundary.
7. Complete reference-mode onboarding and confirm config persists the reference rather than the secret value.
8. Interrupt Parallels validation at the background-job boundary and search captured phase logs for the fake provider marker.
9. Make stub memory and Discord endpoints reflect mixed-case, quoted and punctuation-bearing fake bearer values in JSON and text failures; confirm status and useful diagnostics remain while the markers do not.

A passing API call is insufficient. The evidence must show which endpoint received which credential and which logs retained nothing sensitive.

Incident response

If an older build may have crossed these boundaries, preserve destination access logs, proxy metadata, agent configuration history and provider audit events before rotating. Use token fingerprints or synthetic identifiers in the investigation; do not paste live values into tickets.

Revoke or rotate credentials that demonstrably reached an unintended origin, agent or durable log. For Bedrock PrivateLink failures, also determine whether private memory content was sent over a public service route even when AWS authentication remained valid.

Evidence and limits

The official merged-PR and commit records collected from the OpenClaw repository establish the reported faults and landed fixes. The upstream OpenRouter record includes an actual HTTPS-origin and CONNECT-proxy proof; the other records describe focused owner, lifecycle and rollback tests. Direct GitHub page extraction returned HTTP 403 and web search was unavailable because the configured backend had exhausted credits.

OpenClaw Academy did not send live credentials, inspect a production proxy or identify a packaged release. Exact environment precedence and supported endpoint forms must be taken from the containing revision and official documentation.

Primary collector IDs include 36213, 36122, 36214, 36123, 36220, 36129, 36224, 36133, 36211, 36120, 36210, 36119, 36057, 35983, 36047, 36424 and 36284. IDs 40520/40477 and 40523/40480 identify the new memory and Discord error-redaction fixes.

Bottom line

Provider authentication needs an ownership tuple, not a bag of reusable headers. Adopt a revision containing the relevant fixes, then prove that credentials cannot cross provider, host, agent, fallback or log boundaries before restoring trust in memory and proxy traffic.