We need a standard layer for authorization orchestration in agent plugins

[xfgong]

Thank you all guys for the new standard work. Packaging MCPs and Skills in one Plugin makes sense. It is also close to the direction tools like Codex are taking: load Skills when needed, use MCP to access systems and services. For people building Agent platforms, a common distribution and discovery format is good news.

But the problem I care about most is still unresolved: authentication for Skills and the command-line tools they invoke.
Many Skills ultimately execute a CLI, and that CLI may require a login, an API key, environment variables, a credential file, or a browser-based OAuth flow.

For developers, this may just mean running an auth command or editing an env file. For regular users of a web-based Agent platform, it is much harder to make this experience smooth:

1. Asking users to give API keys directly to an agent so it can configure itself violates security best practices.
2. Asking users to open a terminal, run a login command, or edit a config file is unrealistic for many non-technical users.

Different Skills, MCP servers, and CLIs often use different authentication systems, making it hard for a platform to offer one clear authorization UI.

What I would like to see is a standard layer for authorization orchestration. A Plugin could declare which external identities and permissions it needs. The platform would handle OAuth, secure credential storage, refresh, revocation, and user approval. MCP servers and CLIs invoked by Skills could then receive their own scoped, short-lived credentials.

This also raises a design question: should services from different platforms, each with its own authentication mechanism, be bundled into a single Plugin at all? A Plugin that combines GitHub, Linear, and AWS may be convenient, but it also makes the authorization model harder to explain, approve, and secure.

Today, Agent Plugins can declare multiple MCP servers, but the spec does not standardize OAuth configuration, secret references, or authentication management for scripts and dependencies used by Skills. It can describe which services a Plugin connects to, but not safely and portably describe how its components obtain credentials.

I understand why this is difficult to standardize. OAuth issuers, scopes, CLI authentication mechanisms, and enterprise credential policies all vary. But for Agent platforms serving non-technical users, this matters more than the Plugin directory structure.

I’m curious what others think:

Should a Plugin require all MCP servers to use a shared authorization model? It would reduce flexibility, but might make the security and UX model much cleaner.

Should the standard manage authorization requirements for scripts, CLIs, and dependencies used by Skills? This may belong more naturally in the Agent Skills spec, but Skills are already very open-ended. It may be easier to establish constraints in the newer Plugin standard.

Or should all of this remain platform-specific? If so, will cross-platform Plugin portability fragment again at the most important layer: authentication?