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?

[SandroG1977]

Strong +1. Packaging solves distribution, but portability breaks again at authorization.

I don’t think the Plugin spec should prescribe concrete OAuth flows or enterprise credential policies. Those vary too much. But it could standardize the authorization contract a Plugin declares: required external identities, requested scopes/permissions, logical boundaries/channels, credential references (never secrets), and whether components can accept short-lived delegated credentials at runtime.

That would let platforms render one coherent approval UI and keep the core plugin format portable, while allowing different implementations underneath.

On the questions:
I would not force all MCP servers into one shared auth model, but I would force them to expose one shared authorization descriptor.
Scripts/CLIs used by Skills should at least declare their auth requirements at the Plugin boundary, even if enforcement stays in the platform/runtime.

If this remains platform-specific, portability will fragment exactly at the layer users feel most: login, approval, revocation and trust.
I’ve been exploring a runtime governance pattern in this direction with IRC-A: semantic capability discovery, ephemeral delegated execution tokens, and isolated MCP execution.

Docs/whitepaper: https://irc-a.org/

Not proposing this as a replacement for the packaging spec — more as a possible authorization profile/extension that could complement it. Happy to help draft it if there’s interest.