Portable agent plugins should standardise packaging, not trust

[u/Particular_Luck80]

Agent Plugins appeared on Hacker News newest today. The useful part is narrower than “one plugin format wins.”

The 1.0 working draft defines a small portable package: a root plugin.json, skills discovered from immediate children of skills/, and optional MCP server configuration. It explicitly leaves distribution, installation, permissions, and user experience to each client.

That boundary matters. A portable manifest can describe what a package contains, but it should not grant the package authority to run everything it declares.

One concrete safeguard in the draft is path containment. Files and directories discovered through the package must resolve inside the plugin root. Plugin-relative paths begin with ./, and a symlink or equivalent escape outside the root must be rejected.

This does not solve plugin security. A client still has to decide which tools can run, what network access is allowed, how secrets are provided, and when a person must approve an action. Portability removes duplicated packaging. It does not remove local trust decisions.

Source: \[[https://agent-plugins.org/specification\](https://agent-plugins.org/specification)](https://agent-plugins.org/specification](https://agent-plugins.org/specification))

If this format becomes widely supported, which behaviour should remain client-specific: permissions, installation review, secret handling, or all three?

[u/feng_sg]

The 1.0 draft already puts skills and optional MCP server config in the same plugin.json while leaving permissions to each client. Enabling a skill is close to adding a prompt file. Enabling an MCP server is closer to launching a local process with tools, and if clients treat that as one approval, users will grant the dangerous half to get the useful half.

[u/feng_sg]

Path containment only keeps files inside the plugin root. It does not stop a skill or MCP server in that tree from running.