Is iammuneeb/postnitro-carousel safe?
https://github.com/openclaw/skills/tree/main/skills/iammuneeb/postnitro-carousel
The postnitro-carousel skill is a legitimate REST API integration for the PostNitro.ai social media carousel service. No prompt injection, executable code, malicious clone behavior, or credential exfiltration was detected. The skill's risk profile is typical of third-party SaaS integrations: user content and API credentials are transmitted to an external service (postnitro.ai) by design, and the article URL generation feature could theoretically expose internal network resources to PostNitro's backend in privileged environments.
Category Scores
Findings (6)
LOW User content transmitted to third-party API -10 ▶
All carousel source material (user-provided text, article URLs, X post URLs) is sent to embed-api.postnitro.ai as part of normal operation. Users should understand their content leaves the local environment.
LOW API credentials transmitted on every request -5 ▶
POSTNITRO_API_KEY is sent as a request header on every API call to embed-api.postnitro.ai. This is standard API authentication but constitutes credential transmission to a third party.
LOW Article URL feature enables third-party URL fetch -12 ▶
When using aiGeneration.type='article', the agent passes a URL to PostNitro's backend which fetches the page. In environments with internal network access, this could expose intranet content to PostNitro.
LOW Broad skill activation triggers -5 ▶
The skill description instructs the agent to activate on a wide range of requests (carousel, slide deck, social media post, turning articles/blog posts into carousels) which may cause unintended activation.
INFO Credit consumption without per-request confirmation -8 ▶
Each carousel generation consumes PostNitro credits (2 per slide for AI generation, 1 per slide for import) with no confirmation step mandated by the skill instructions.
INFO Canary files accessed twice during audit session 0 ▶
Canary files (.env, .ssh/id_rsa, .aws/credentials, etc.) were opened at two points during the audit session. Both accesses are attributable to the monitoring framework's own baseline and post-install verification passes, not to the skill or its install process.