chore(security): extend the plugin/portable-agent vetting docs — credentials in mcp.json are visible package data

[MCPVOT]

Summary

Small documentation/hardening ask. For agent frameworks that support portable Agent Plugin v1 packages (install-disabled by default, mcp.json can declare stdio MCP servers), the docs should state explicitly that env values declared in a portable package's mcp.json are visible package data, not a secret store — and recommend runtime-injected env refs instead.

This is a footgun: a plugin author or adopter may read the spec, see mcp.json accepts env, and put an API key there. Unlike .env (mode 0600, gitignored), mcp.json ships inside the package and can be committed/exfiltrated.

Suggested change

• In the plugin/portable-package docs, add a bolded line: "Never place credentials in mcp.json — values there are plaintext package data. Inject secrets via environment variables or a secret manager at runtime."
• Optionally: a CI lint that greps repo .json manifests for key-like patterns (sk-, api_key=, token=), mirroring the gitleaks approach already used in this repo (see the recent #131 test fixture allowlist work).

Why it matters here

This repo already takes secret hygiene seriously (0600 config stores, private-directory ACLs, gitleaks allowlists). One explicit line in the plugin docs closes the same gap for the plugin path, where the trust model is "same full-trust posture as any installed plugin."

[Zongwei9888]

Thank you for raising this. We agree with the security boundary: values embedded in a portable package’s mcp.json / .mcp.json are distributable plaintext configuration, not a secret store.

The current DeepCode 2.0 scope deliberately implements local Skills only; portable plugins, marketplaces, remote Skill distribution, and plugin mcp.json ingestion are not shipped yet (see docs/SKILLS_PRODUCT_ARCHITECTURE.md). Consequently, there is no current DeepCode package-import path that consumes such a manifest.

We will keep this issue open as a security requirement for the future plugin/package layer. The acceptance criteria should include:

1. an explicit documentation warning never to place credentials in the manifest;
2. runtime environment references or the user-private credential store for secret resolution; and
3. parser-aware manifest linting/secret scanning with redacted diagnostics and tested allowlisting, rather than a broad grep that produces false positives.

This is a useful guardrail to establish before the open plugin ecosystem is enabled. Thank you.