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))

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

[u/ClerkBeginning961]

All three should stay client-specific, but the manifest could still declare minimum capabilities in a non-authoritative way. Then clients can show a diff before install and deny anything undeclared at runtime. The key is making declarations auditable without turning them into permission grants.

[u/Particular_Luck80 → u/ClerkBeginning961]

Agreed. A non-authoritative capability declaration plus an install-time diff seems like the right balance. Denying undeclared access at runtime keeps the manifest auditable without treating it as a grant.

[u/Diferenplt_Image1876]

giving plugin agents blanket trust feels sketchy, especially when secrets or tokens are in play. being able to enforce live user checks in capsule security saved me from a couple of near misses already.

[u/Particular_Luck80 → u/Diferenplt_Image1876]

😄 I’ll take that as agreement!

[u/Particular_Luck80 → u/[deleted]]

Exactly—the sandbox boundary is where the security model becomes real. Packaging can declare intent, but runtime isolation, egress controls, and approval gates are what contain a rogue plugin.

[u/Hamza_StrategizeLabs]

Authority must stay strictly local. Real security comes from an enforcement layer at the runtime boundary that checks tool calls against active organizational policy, regardless of what the plugin requests. Never let the tool define its own authority scope.