A DSH plugin is a package that runs inside your agent runtime with the same privileges as the runtime. That is the whole security model in one sentence. There is no marketplace gatekeeper, no review committee and no signature requirement, so the judgement is yours. This guide is a repeatable way to make that judgement quickly.
The four permission surfaces
Most plugin risk concentrates in four places. Decide how much of each a plugin genuinely needs before you install it.
| Surface | What it means | Reasonable request | Red flag |
|---|---|---|---|
| Filesystem | Reading and writing your workspace | Workspace-relative paths, declared roots | Path traversal, writes outside the workspace |
| Shell | Executing commands | A named, guarded command set | Unrestricted execution with no confirmation |
| Network | Reaching external services | A specific API host | Broad access plus credential handling |
| Credentials | Holding keys and tokens | Reading from local config, never injecting into prompts | Sending secrets to a third-party endpoint |
A vision plugin needs network access and nothing else. An SSH operations plugin legitimately needs shell and network access, which is exactly why its guard list deserves reading.
Step 1: confirm the source
Open the repository the install command claims to come from. What you want to see: commit history that is not a single squashed import, a README that explains what the plugin does and what it needs, and an issue tracker where someone has asked a question and received a reply.
A repository with one commit, no history and a package name close to a popular plugin is the pattern worth being careful about.
Step 2: read the install spec against the repository
Install specs are typed by hand and copied without thought. Check the spec on the listing against the package name in the repository’s own documentation. When they disagree, the listing is wrong or the plugin has been renamed, and both cases deserve a pause.
Step 3: look at what runs on load
Search the source for the code paths that execute during activation rather than when you call a tool. The parts worth reading are the ones that run without you asking: install scripts, postinstall hooks, anything that opens a socket during apply, and any code that reads environment variables.
Step 4: check how secrets are handled
A plugin that needs an API key should read it from local configuration and use it in its own requests. The pattern to avoid is a plugin that takes a key and injects it into the model context, because anything in context can be echoed into a transcript, a log or a shared session.
Step 5: match verification level to risk
Verification levels tell you how far a plugin was tested, not how trustworthy it is. Read them as increasing confidence about behaviour, and require more of a plugin as its permission surface grows.
| Level | Meaning | Enough for |
|---|---|---|
| L1 | Repository found and non-empty | Nothing by itself; start reading |
| L2 | Manifest valid, fields complete | Evaluating, not installing |
| L3 | Install command parsed, target declared | Read-only and purely local plugins |
| L4 | Installed in an isolated sandbox without dependency errors | Everyday tools, with a source review |
| L5 | Loads and runs; smoke test passed | Tools with filesystem or network access, still with a review |
The full rules live on the verification page.
Step 6: start narrow
Install a risky plugin with the smallest scope that is useful: read-only credentials, a single repository, a workspace subdirectory, one remote host. Widen access after the plugin has behaved for a while, not before.
If a plugin offers a public network exposure mode, such as remote access from a phone, treat enabling that mode as a deployment decision. Put authentication in front of it and turn it off when you are not using it.
Step 7: keep a removal path
Before installing, know how you will remove it and what data it will leave behind. Plugins that store state inside the profile directory are easy to clean up. Plugins that write to global caches leave residue that outlives your decision to uninstall.
FAQ
Are DSH plugins reviewed by DeepSeek?
No. The official team does not run a registry or review community plugins. Directories such as this one apply their own checks.
Is a high star count a safety signal?
It is a popularity signal. Popular projects receive more scrutiny, which helps, but it does not replace reading the permission surface.
What should I do if a plugin asks for a token with broad scopes?
Create a scoped token instead, if the provider supports it, and read the code path that uses it before granting anything.
Can a plugin read my other sessions?
Plugins run inside the runtime and can access what the runtime exposes. Assume a plugin with filesystem access can read anything your user account can read.
Next steps
Review the verification methodology, then browse verified plugins and check the security field on any listing before you install.