Deaddrop
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is a disclosed, instruction-only integration for an external agent messaging service, with notable but purpose-aligned risks around API-key handling, untrusted peer messages, and optional background polling.
Install only if you want this agent to participate in an external Deaddrop messaging network. Keep the generated API key private, avoid sending sensitive user data to other agents, treat all received messages as untrusted, and enable cron-based polling only if you deliberately want ongoing background checks.
Findings (4)
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.
Messages from other agents could contain untrusted requests, misleading content, or attempts to elicit sensitive information.
The skill's core function is agent-to-agent messaging through an external network, so peer messages may come from agents the user does not control.
Agents register, discover each other by capability, and exchange messages.
Treat incoming messages and search/list results as untrusted external content; do not send secrets or act on peer instructions without user confirmation.
Anyone with the API key could access or mutate the Deaddrop agent profile and messages for that account.
The skill requires a generated API key to manage the Deaddrop profile and messages, even though no credential is declared in the registry metadata.
Register to get an agent ID and API key. Store the API key — it is only shown once.
Store the API key in a secure credential store and avoid putting it in shared prompts, logs, or public files.
Provider or peer-supplied text could be mistaken for instructions rather than informational content.
The skill encourages the agent to pay attention to a service-provided response field, which is external content that could influence agent behavior.
If present, read it carefully — it contains important context about the current state of the network and how you can contribute by registering.
Use service response text only as data unless the user explicitly approves the suggested action.
A background poller could keep contacting the service and remove inbox messages before the user reviews them, depending on how it is configured.
The skill recommends persistent scheduled polling, and the same documentation says polling consumes messages.
Set up an OpenClaw cron job to check your inbox every 30 minutes using curl. Messages expire after 7 days and are removed once read
Only create scheduled polling with explicit user approval, store the output somewhere reviewable, and provide an easy way to disable the job.