Zipsa
Security checks across static analysis, malware telemetry, and agentic risk
Overview
Zipsa is a coherent privacy-gateway skill, but it asks the agent to send very sensitive data to an unspecified local gateway whose implementation, retention, and provenance are not provided.
Before using Zipsa with real PII, health records, business secrets, or credentials, verify the actual Zipsa server source and version, confirm it is bound to a trusted local endpoint, review its logging and retention settings, and test that cloud-bound prompts are actually redacted.
Static analysis
No static analysis findings were reported for this release.
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 user may trust an unverified local service with PII, health records, credentials, or proprietary information.
The skill's safety depends on a local privacy gateway that is not provided or tied to a verifiable install source, even though that gateway would receive highly sensitive prompts.
Source: unknown; Homepage: none; Install specifications: No install spec — this is an instruction-only skill.
Use only with a verified Zipsa server from a trusted source, document the install path/version, and confirm what component receives prompts before processing sensitive data.
Sensitive information could persist in gateway session state longer than expected or be mixed into later work if session IDs or storage are mishandled.
The skill describes retaining a full sensitive conversation thread, but the artifacts do not clearly bound retention, deletion, per-user isolation, or reuse across sessions.
Full thread (private zone): everything, including all your personal, business, and operational context.
Require clear retention/deletion controls, unique per-user session IDs, and documented storage boundaries before using this with real sensitive data.
Any sensitive text passed to the helper will be delivered to whatever service is listening at the configured Zipsa endpoint.
The included helper posts the raw user query to a local HTTP relay. This is central to the stated privacy-gateway purpose, but users should know the gateway receives the raw sensitive input.
requests.post(f"{base_url}/relay", json={"user_query": query, "session_id": session_id}, timeout=10)Confirm the endpoint is a trusted local Zipsa instance, keep it bound to localhost unless intentionally deployed otherwise, and avoid using the helper with secrets until configured.
Credentials could be stored or processed by the gateway if users include them in prompts.
The skill is explicitly intended to activate when credentials or secrets are present. That is purpose-aligned for a privacy filter, but it means credential material may enter the gateway's local context.
Secrets: API keys, credentials, internal system details.
Avoid sending live credentials unless necessary, rotate any credential accidentally included, and verify the gateway blocks or redacts secrets as expected.
Users may over-trust the privacy claim and submit highly sensitive data without verifying the actual running gateway.
This is a strong privacy guarantee, but the provided artifacts do not include the gateway implementation that would prove redaction, routing, and logging behavior.
It ensures that raw private context never leaves the local environment while still allowing the use of powerful frontier models for reasoning.
Treat the privacy guarantee as conditional on the deployed Zipsa service; test redaction behavior and review logs/provider routing before relying on it.