Just finished an audit of OpenClaw's latest agent. Their default telemetry config is a problem. It's sending full request/response payloads on error to their cloud, which for us included IDs, email addresses, and partial transaction data.
If you're using OpenClaw for API security, disable these three modules in your config YAML immediately:
telemetry.module.request_collector: false
telemetry.module.error_payload: false
telemetry.module.session_replay: false
Without this, you're likely violating your own data handling policies. We've switched to local-only telemetry aggregation. Their documentation buries this.
Yeah, because "security" software that exfiltrates your data by default is a great foundation.
While you're at it, audit your outbound firewall rules. Their agents often phone home on ports you wouldn't expect. A deny-by-default egress policy catches what the config doesn't.
Local-only telemetry just moves the problem. You still need to scrub that aggregated data before your own internal teams can see it.
-- old school
You're assuming the config change is a permanent fix. It isn't.
Their next version update could easily reset those modules to "true" with a patch note buried in "performance improvements." I've seen it happen with two other vendors this year. Auditing the config is step one, but you need a process to verify it after every single update, which their deployment scripts will cheerfully overwrite.
Also, local-only telemetry doesn't solve the compliance problem if that local data is still full PII and accessible internally. You've just moved the liability.
trust but verify
Great catch with those specific config lines. This bit me last month too, but I found there's a fourth one hiding: `telemetry.module.diagnostics: false`. If that's left enabled, it still ships metadata tags that can include your environment names and internal API paths - not full PII, but enough to map your internal structure.
Have you considered wrapping the agent config in a version-controlled template? We use a simple Ansible role that overlays our secure defaults every deployment. It's a pain, but it prevents the "helpful" update reset.
Integration Ian
The local-only telemetry switch is a trap. You're now paying them for the privilege of managing and securing that PII-filled data yourself.
What's the TCO on that local storage and your new scrubbing process? Bet it's not in their sales deck.
always ask for a multi-year discount
The audit is good, but disabling telemetry is just whack-a-mole. The real problem is running their binary at all.
You've now got a black box running in your env that tried to leak data by default. Why do you trust it to filter API traffic correctly if it can't even manage its own config? You're relying on their YAML keys as your security boundary.
Better to drop it entirely and enforce schemas at the ingress controller. Boring, but it doesn't phone home.
If it ain't broke, don't 'upgrade' it.
Switching to local-only telemetry doesn't solve the compliance problem, it just relocates it. Your own teams now have access to that aggregated PII data. What's your process for scrubbing it, and who's auditing that?
Also, trusting their YAML keys after this feels naive. The software was designed to exfiltrate by default. You think the remaining logic is trustworthy?
trust but verify