Ecosincronia Supabase
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This looks like a legitimate Supabase helper, but it gives the agent full-access database credentials plus raw SQL and destructive database commands without clear safety boundaries.
Install only if you trust this skill with full Supabase project access. Use a staging or tightly scoped project if possible, review every raw SQL/update/delete/RPC action before it runs, and avoid sending sensitive vector-search queries to OpenAI unless that is acceptable.
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.
If the agent or a mistaken prompt uses this key incorrectly, it may be able to read or change data across the Supabase project.
The required credential is explicitly a full-access Supabase service role key, not a least-privilege credential scoped to specific tables or read-only tasks.
| SUPABASE_SERVICE_KEY | Yes | Service role key (full access) |
Use this only with a project and key you are comfortable exposing to the agent; prefer non-production projects, scoped credentials where possible, and rotate the service key if it is ever exposed.
A wrong command could alter schema, update records, delete data, or call privileged database logic.
The skill exposes broad database-changing tools, including raw SQL and stored procedure calls, without artifact-visible confirmation, allowlisting, dry-run, or rollback controls.
query - Run raw SQL ... update - Update rows ... delete - Delete rows ... rpc - Call stored procedure
Require explicit user confirmation for raw SQL, update, delete, and RPC calls; restrict use to approved tables/functions; and test against a staging database first.
The destructive-operation safeguard may be weaker than the documentation suggests, increasing the chance of unintended updates or deletes.
The script says delete/update require a filter, but the check only verifies that some query string exists; non-predicate options such as limit can satisfy the guard.
--limit) filters+="&limit=${2}" ... if [[ -z "$filters" ]]; then echo "Error: At least one filter required for delete (use --eq)" ... api_request DELETE "$url"Enforce real predicate filters for update/delete, such as requiring --eq or another row-matching condition, and add explicit confirmation before destructive requests.
Sensitive search queries may be sent to OpenAI when vector-search is used.
Vector search sends the search query text to OpenAI to generate an embedding. This is purpose-aligned, but it is an external provider data flow.
curl -s https://api.openai.com/v1/embeddings ... "input": $(printf '%s' "$query" | jq -Rs .)
Avoid using sensitive query text with vector-search unless OpenAI use is acceptable for your data, or modify the skill to use an approved/local embedding provider.