Plugin Security in 2026: What the Audits Mean for Everyday Users

By late 2026, DeepSeek Harness had enough users that third-party security writeups and long GitHub discussion threads stopped being niche. Two themes keep recurring in public materials such as discussion #454 and follow-ons like #5636: the agent behavior path (tools, approvals, sandboxing) is relatively articulated, while the plugin installation path looks a lot more like “you chose to load code into the host.”

This article restates those public themes in plain language for people who install plugins, not for people hunting vulnerabilities. It does not provide exploit steps, payloads, or bypass recipes. It is also not affiliated with DeepSeek AI; when official docs disagree with this note, trust the official docs.

Powerful plugin ecosystems are not app stores

Phone app stores promise review, signing, permission prompts, and a revoke button that mostly works. Cordis-style harness plugins promise something else: reversible composition for developers who accept that loaded code is powerful. Those are incompatible trust models if you pretend they are the same.

A marketplace or Discover index can be a convenience for discovery. It is not, by itself, a proof that a package is safe for your laptop, your customer data, or your cloud credentials. High capability surface area in a sample of popular plugins is a signal about the ecosystem’s power—not a verdict that any given package is malicious. Conversely, a quiet package with few stars is not automatically safer; obscurity is not a control.

Official Terms and safety notices already frame Harness as experimental. Read them as product truth, not boilerplate. Sandboxes and approval flows reduce certain classes of agent mistakes; they do not transmute arbitrary plugin code into a reviewed mobile app.

Two trust axes, in human words

Public audit-style discussions tend to split Harness into roughly two axes:

1. Agent behavior axis. The model proposes tool calls; policies, approvals, and sandboxes mediate what happens next. You can still misconfigure this axis, but the product vocabulary for it is rich: allow lists, prompts for confirmation, isolated execution where configured.
2. Plugin code axis. Installed plugin code participates in the host Cordis process. Lifecycle can be elegant and reversible, yet the trust decision happened when you added the source—not when the model later asked to run a tool.

That split explains a feeling many users report: “I carefully approved shell commands, then installed a plugin that could have done worse quietly.” Approvals on tool calls do not retroactively sandbox the plugin’s own apply(ctx). If a plugin registers tools, listeners, or network clients during load, those registrations are part of your host’s trusted computing base until you unload them and verify they are gone.

Treat plugin install as loading an extension into your agent host. Treat tool approval as a second, narrower gate for model-initiated actions.

Community sampling threads that highlight how many indexed plugins request broad capabilities are easy to misread. “Many plugins could do a lot” is an ecosystem description. It is not the same statement as “these plugins are exploiting users today.” The operational response is still the same: shrink what you install, and know what you installed.

A defensive checklist for everyday users

None of these replace reading source. Together they raise the cost of casual mistakes.

1. Isolate the Harness home

Use a dedicated DSH_HOME (or equivalent) for experiments. Prefer disposable machines or containers when trying unfamiliar authors. Do not point a playground profile at directories that contain tax PDFs, SSH keys, or production .env files “just for convenience.” Separate homes also make uninstall archaeology easier because you can delete the playground without mourning your main profile.

2. Pin versions and prefer readable sources

Install from an explicit ref or version. Re-read the tree when a plugin updates. Floating tags are fine for demos; they are rude for anything that can touch secrets. Prefer sources where you can browse the exact commit you are about to run.

3. Inventory capability surfaces before first run

Skim for filesystem access, shell execution, outbound network, credential reads, and any feature that re-downloads code after install. You are not performing a formal audit—you are deciding whether the blast radius matches the plugin’s promise. A calendar helper should not need a raw disk walker. A “theme” should not need your cloud metadata endpoint.

4. Keep secrets out of agent-visible environments

If the runtime can forward environment variables into tool contexts, assume plugins and prompts can collide with that data. Prefer short-lived tokens, scoped cloud roles, and secrets managers over long-lived keys in the process environment. Rotate anything that ever lived in a playground.

5. Be skeptical of remote re-fetch patterns

Features that silently pull fresh code, prompts, or binaries after install expand the supply chain beyond the commit you reviewed. Patterns marketed as “auto update” or “live skills” deserve the same suspicion you would give any software that rewrites itself after first install. Make that choice consciously, or disable it.

6. Verify removal

After plugin remove, dump config and spot-check behavior. Stale patch rows are a reliability problem and a security problem: you think a capability is gone while the host still loads it.

Minimum politeness for authors

If you publish plugins, the reciprocal obligations are boring and valuable:

• Declare what you touch: files, network, shell, credentials.
• Avoid quiet hot-updates of sensitive exporters.
• Keep Cordis effects reversible so unload means unload.
• Ship a changelog that mentions permission changes in plain language.
• Provide a way to run without telemetry, or say clearly that you cannot.

Community trust compounds slower than download counts. A short permissions section in the README is worth more than a clever demo GIF.

Where this site stands

These notes discuss public documentation, public discussion threads, and ordinary operating habits. They are not a vulnerability feed, not a pentest report, and not advice to bypass anyone’s controls. If you need authoritative safety language, start from DeepSeek’s published Harness safety materials and Terms of Use, then read the discussion threads above for community analysis.

Next note: how to assemble a small personal stack—tools, runtime, UI—without turning Discover into an unchecked shopping cart.