How should DeepSeek Harness plugins disclose and manage permissions?

[cxeeo069]

DeepSeek Harness is built around a powerful idea: everything is a plugin.

That flexibility also means plugins can operate close to local files, environment variables, model routing, session data, tool registries, and shell execution.

The AgentGuard team recently conducted a sample-based security study of the DeepSeek Harness plugin ecosystem.

We selected 659 plugins from a marketplace snapshot containing 2,916 listings. The sample represented 90.0% of marketplace downloads over the previous 30 days.

Of the 659 targets:

• 590 were scanned successfully
• 15 produced incomplete coverage
• 54 could not be scanned

Among the 590 successful scans, 94.7% were rated High or Critical based on capability surface, permission exposure, and potential impact.

This figure needs context.

It does not mean that 94.7% of plugins are malicious or contain confirmed vulnerabilities. DeepSeek Harness plugins often need powerful capabilities to perform their intended functions.

What the result does show is how much trust users may place in plugin code before they can clearly see the permissions and runtime capabilities involved.

Some capability-level findings

Across plugins with successful or partial scan data:

• 91% could read files
• 81% could access environment variables
• 74% could access the network
• 63% could execute shell commands
• 48% could modify the tool registry

We also identified 32 plugins containing AUTO_UPDATE patterns that retrieve remote content and automatically install or execute it.

An AUTO_UPDATE pattern is not a vulnerability by itself and does not prove malicious intent. It can support legitimate functionality.

However, it introduces an additional supply-chain trust path because users are not only trusting the code reviewed at installation time, but potentially future content retrieved through that mechanism.

Full research

The complete methodology, findings, limitations, and interpretation are available in the X Article:

Read the full X Article

We have also published the research dataset and verification materials on GitHub:

View the research dataset

View the complete 659-target CSV

Verify the dataset checksum

Questions for the DeepSeek Harness community

We would like to hear how plugin permissions should work in DeepSeek Harness.

1. Should every plugin publish a declarative permission manifest?

2. Which capabilities should require an explicit warning or confirmation before installation?

3. Should permissions such as:

   • shell execution
   • environment-variable access
   • file write
   • network access
   • remote code loading

   be displayed directly on plugin listings?

4. How should marketplaces handle plugins that cannot be fully scanned or whose repository paths no longer resolve?

5. Should permission changes between plugin versions trigger a new review or user confirmation?

6. What would make security metadata useful without creating unnecessary friction for plugin developers?

If you maintain a DeepSeek Harness plugin, it would also be useful to understand:

• which permissions your plugin genuinely needs
• how you currently communicate those requirements to users
• whether a standard manifest or capability label would be practical to maintain

This study is intended to support ecosystem discussion, not to label individual plugins or developers.

The scan was sample-based, reflects a specific dataset and repository snapshot, and cannot guarantee whether any plugin is safe or unsafe.

We welcome corrections, alternative interpretations, and concrete proposals from plugin authors, users, marketplace maintainers, and the DeepSeek Harness team.

---

Research: AgentGuard Team
Dataset snapshot: September 2, 2026
Scanner: AgentGuard v1.1.29 with DeepSeek Harness support