Platform API Connector
PassAudited by VirusTotal on May 11, 2026.
Overview
Type: OpenClaw Skill Name: platform-api-connector Version: 1.0.0 The skill is classified as suspicious due to its core functionality involving the acquisition and storage of highly sensitive API credentials (client secrets, access tokens, refresh tokens, API keys) for various social media platforms. The `SKILL.md` explicitly instructs the AI agent to store these critical credentials in a database, even providing a `CREATE TABLE` SQL schema for this purpose. While the stated intent is to manage API connections, the instruction to store such sensitive data without explicit mention of robust security measures (e.g., encryption at rest, secure key management) represents a significant security vulnerability. A compromise of the database or the agent could lead to a major data breach. Additionally, `references/oauth-flows.md` details running a local HTTP server for OAuth callbacks, further highlighting network activity and sensitive data handling.
Findings (0)
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.
Tokens created through this workflow may let an application post to or manage social media accounts.
The skill asks the user to create OAuth credentials with account-level posting/write authority. That is purpose-aligned for a social platform connector, but it grants delegated authority that could affect public accounts if reused improperly.
Access Token + Secret (user auth for posting) — generate with Read & Write permissions
Grant only the scopes needed, use separate developer apps for testing, and revoke or rotate tokens when the integration is no longer needed.
Saved API secrets and refresh tokens could be reused later by other code or agents that can access the database.
The skill intentionally creates persistent credential state for future reuse. This is coherent with the connector purpose, but the artifacts do not provide detailed controls for encryption, access limits, retention, or revocation.
Store credentials in Supabase (or any DB) for reuse.
Store tokens in a dedicated secrets store or encrypted database fields, restrict database access, enable row-level security where applicable, and document how to rotate and delete credentials.