render@r7
CAUTIONPublisher claims: "Interact with your Render resources via LLMs." Observed in sandbox: no network, touches nothing outside the project, writes no memory.
Is render@r7 safe to install?
KillerSkills ran it in the KillerSkills honeypot sandbox (1 scenario) on 2026-11-05 and scored it 70/100 (Caution). It is not known to be malicious, but it has behaviour or code a security policy should decide on before install. Notable findings: Direct script execution from GitHub raw URL; Pipe-to-shell pattern. Summary: no network, touches nothing outside the project, writes no memory.
Behavior trace
Honeypot run · 0 s · 1 scenarios · 0 deviationsStatic findings
Cost to the agent
Tokens estimated at four characters each. Skills load their instruction text when triggered; the figure is what that costs.
Known vulnerabilities
Vulnerability advisories (OSV) cover npm and PyPI packages; this registry has no advisory database.
What would make this Verified
10 points to 80 · weights: behavior 45%, static 25%, prompt 15%, publisher 15%- Pipe-to-shell pattern≈ +9 on the totalBuild commands from fixed arguments, never from interpolated strings; prefer an API client over shelling out.
- Unclaimed publisher≈ +8 on the totalClaim render-oss: a verified publisher gets +50 on publisher trust. It is free and usually instant with GitHub sign-in.
- Direct script execution from GitHub raw URL≈ +4 on the totalPin versions and sources; vendor anything fetched at install time.
- New publisher≈ +3 on the totalTime clears this on its own after 14 and 30 days. Claiming the handle (+50) is the fastest way past it.
- File permission modification command≈ +2 on the totalRequest the narrowest permission that works; replace wildcards with the exact paths or hosts.
- MCP server using network transport (SSE/HTTP)≈ +2 on the totalNamespace tool names and keep tool descriptions literal; no instructions to the agent inside them.