Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Safety Netting

v1.0.0

Automated clinical safety netting for NHS GPs. Follows up with patients after appointments, checks for red flag symptoms, escalates to GP when needed.

0· 40·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Suspicious
medium confidence
!
Purpose & Capability
The skill claims to send follow‑ups across multiple channels and to store audit trails and learning data. The SKILL.md lists OPENMAIL_API_KEY, SUPABASE_URL and SUPABASE_SERVICE_ROLE_KEY as env entries, yet the registry metadata declared no required env vars — that's an internal inconsistency. The skill also references ElevenLabs (voice), Telegram, WhatsApp, SMS and other channels but doesn't declare the credentials those channels would need. Requiring a Supabase service role key and OpenMail API key (per SKILL.md) could be coherent for email + DB storage, but the missing declared requirements and additional unspecified channel credentials suggest the manifest and instructions are not aligned.
!
Instruction Scope
The instructions direct the agent to collect and store highly sensitive personal health information (names, contacts, conditions, exact patient responses) and to keep a learning/ dataset for ML improvements. They require waiting until follow‑up times and sending messages or making voice calls — but provide no mechanism for scheduling, background execution, or how escalation routing to the GP is authenticated/implemented. There's no guidance on consent, retention, encryption, or who may access the stored records. The guidance to 'record everything' and to keep learning data expands scope beyond simple one‑off notifications and creates significant privacy and compliance surface.
Install Mechanism
This is an instruction‑only skill (no install spec, no code files), which reduces local install risk. However, lack of code means you cannot audit runtime network calls; the SKILL.md expects network integrations (email, DB, voice, messaging). Instruction‑only status therefore shifts risk to runtime: the agent will make external API calls carrying PHI if given credentials.
!
Credentials
SKILL.md requests SUPABASE_SERVICE_ROLE_KEY — this is typically a highly privileged key that can bypass row‑level security and access the full DB. That is disproportionate for a single practice agent (a least‑privilege, per‑table or per‑row key would be preferable). OPENMAIL_API_KEY is plausible for email, but other channel keys (e.g., Twilio, Telegram, ElevenLabs) are not declared. Registry metadata claiming no required env vars conflicts with SKILL.md, which is a red flag and could lead to giving out over‑privileged credentials unintentionally.
!
Persistence & Privilege
The skill requires persistent storage of PHI under memory/ and learning/ with no retention, access control, encryption, or deletion policy described. It also implies it must be able to act after a delay (scheduling or background execution). Although always:false (not force‑installed), the need to persist PHI and run at scheduled times increases privilege/attack surface and raises compliance concerns (GDPR/NHS data governance).
What to consider before installing
Do not install or hand over credentials yet. Questions and actions to resolve before use: - Confirm provenance and author identity (homepage and maintainer information are missing). Do not trust unknown sources with patient data. - Do not provide a SUPABASE_SERVICE_ROLE_KEY. Demand a least‑privilege API key or scoped service account (per‑table or with Row‑Level Security) and audit logs enabled. Service role keys can access all data and are over‑privileged for per‑patient follow‑ups. - Ask what credentials are needed for each channel (SMS/WhatsApp/Telegram/ElevenLabs) and why they are not declared in the registry. Prefer per‑channel, least‑privilege credentials. - Require a data protection plan: explicit patient consent, data minimisation, encryption at rest/in transit, retention policy (how long learning/ and memory/ are kept), deletion procedures, and a DPIA (Data Protection Impact Assessment) because this handles PHI. - Clarify scheduling model: how does the agent 'wait' and trigger messages? Will it run as a persistent service or rely on platform scheduling? If persistent, insist on hardened execution, restricted network egress, and admin controls. - Insist on an audit trail and access controls for stored PHI, and on a testing/sandbox mode with synthetic data before any live deployment. - If you must trial it, run in an isolated environment with synthetic patient data and monitor all outbound requests. Prefer a code review or only accept a version with accessible source so security/privacy reviewers can inspect network calls and storage behavior. - Consider disabling autonomous invocation or restricting the skill's access to credentials until you can verify its behavior and governance. Given the current inconsistencies and high‑risk data handling, treat this skill as needing further technical and legal review before production use.

Like a lobster shell, security has layers — review code before you run it.

latestvk970qdw7aeaf0254w535hykx9h83s0qg

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Runtime requirements

Environment variables
OPENMAIL_API_KEYrequired
SUPABASE_URLrequired
SUPABASE_SERVICE_ROLE_KEYrequired

Comments