Audit an agent skill like a pull request before it gets file access
Installing a skill or MCP server hands someone else's instructions your files, credentials, and shell. Treat it like merging unreviewed code, not adding docs. A credible DIY baseline covers most one-off installs if you
Installing a skill or MCP server hands someone else's instructions your files, credentials, and shell. Treat it like merging unreviewed code, not adding docs.
A credible DIY baseline covers most one-off installs if you install rarely. Clone or unpack it outside your worktree, read the manifest and tool definitions first, then grep for shell execution, file writes, reads of env files and SSH keys, and outbound network calls. Run the first trial in a throwaway container or separate user with no live secrets.
That leaves recurring gaps:
- static hits without context: a flag tells you
curlexists, not whether it exfiltrates data or fetches a schema - install-time vs runtime drift: what you read today is not what runs after an auto-update
- review fatigue: nobody re-reads every dependency on every update
A practical method that helps: a pre-run check bot for the boring second pass. Point it at the unpacked skill directory, open the code around each risky call, classify read-only versus write versus network behavior, and output a short verdict with file paths and line numbers. Keep that verdict next to the install so the next update gets a diff, not a fresh full review.
What workaround actually sticks for you: blocking installs by default, sandboxing every new skill, or re-auditing on each version bump?
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.