Drip OpenClaw Billing
Security checks across malware telemetry and agentic risk
Overview
This is a coherent instruction-only billing telemetry skill that discloses its Drip API credentials and sanitized usage reporting, with no evidence of hidden code or malicious behavior.
Before installing, confirm you want OpenClaw run and tool-call usage metadata sent to Drip for billing. Use a scoped telemetry key, validate the integration in staging, enforce the no-PII/no-raw-prompt rules, and make sure the registry credential metadata matches what your deployment will actually require.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A configured key or token may allow the agent integration to create or update usage and billing telemetry records.
The skill uses API credentials and an OpenClaw identity token for telemetry endpoints. This is expected for a billing integration, but the credentials could authorize billing or telemetry writes if over-scoped.
credentials:\n primary: DRIP_API_KEY\n alternate: OPENCLAW_IDENTITY_TOKEN
Use a least-privilege Drip telemetry key, avoid broad account-admin tokens, and rotate credentials if they are exposed.
Incorrect integration or duplicate writes could create inaccurate usage or billing records.
The integration writes run, event, and billable usage records to Drip. These API mutations are purpose-aligned, but they can affect billing telemetry and should be controlled.
1) `POST /v1/runs` start run\n2) `POST /v1/events` emit tool/event timeline\n3) `POST /v1/usage` emit billable usage\n4) `PATCH /v1/runs/:id` finalize status
Validate in staging, use stable idempotency keys, and confirm usage meters match intended billable events before production rollout.
Run, tool-call, customer, and usage metadata may leave the local OpenClaw environment and appear in Drip dashboards.
The skill sends operational metadata to an external billing provider and explicitly limits what should be transmitted. This is appropriate, but users should enforce these limits in their integration.
Allowed metadata examples:\n- provider name\n- endpoint name\n- status code\n- latency ms\n- hashed request fingerprints (`queryHash`)\n\nDo not send:\n- raw prompts or model outputs\n- auth tokens / credentials\n- personal data
Send only sanitized operational metadata, hash request fingerprints, and verify that prompts, outputs, credentials, PII, and raw request/response bodies are excluded.
The install or registry view may not clearly warn users that a Drip API key or OpenClaw identity token is part of the integration.
The registry requirement summary does not advertise credentials, while the artifact files disclose DRIP_API_KEY and OPENCLAW_IDENTITY_TOKEN. This looks like metadata under-declaration rather than hidden credential use.
Required env vars: none\nEnv var declarations: none\nPrimary credential: none
Update registry metadata to declare the documented credentials and environment variables so installers see the credential requirements before setup.