Cómo definir permisos de un plugin de agente de terceros

El paquete llega sellado, con el conector expuesto. El manifiesto que contiene tiene diez campos y ninguno declara permisos portables.

La comparación útil es una instalación eléctrica: se compra el aparato, no el disyuntor. El límite se añade después, en la pared, por decisión de quien instala. Con un plugin de agente se repite la lógica y la decisión sigue siendo de quien instala, no del archivo recibido.

El 6 de agosto de 2026, la especificación Agent Plugins 1.0.0 estandarizó el paquete de skills y servidores MCP, con un manifiesto de diez campos y ningún permiso portable. Definir permisos de plugin de agente exige decidir antes de la instalación qué componentes aceptar, qué credencial usar y qué alcances aprobar.

Cuadro de decisión / Datos clave: Módulo sellado, conector expuesto: ninguno de los diez campos incluye permisos portables [3][4]. Solo $schema y name son obligatorios; version es opcional [4]. allowed-tools es opcional, experimental y tiene soporte variable [10]. Si el desafío contiene scope, este es autoritativo; sin él, la recomendación es solicitar todos los alcances de scopes_supported, si está definido [12].

Requisitos previos

Antes del primer paso, el equipo necesita acceso administrativo al cliente, una lista de plugins aprobados, una bóveda de credenciales fuera del paquete y un destino para el inventario. Sin acceso al cliente, no es posible comprobar qué se cargó. Sin inventario, no es posible demostrar la decisión.

Cada cliente de Agent Plugins controla la instalación y los permisos [2]. La lista de clientes compatibles incluía doce, frente a cinco en el anuncio [1][8]. Eso no mide la madurez. Antes de instalar un plugin de terceros, el equipo debe identificar el cliente utilizado y comprobar los componentes que realmente carga. El manifiesto no proporciona un permiso portable: la revisión abarca las skills, los servidores MCP y las credenciales que recibe cada servidor [3][4]. En una cabecera literal, el formato prohíbe los secretos, pero no impide incluirlos en el paquete [16]. La bóveda queda fuera de él. Para un servidor remoto, la aprobación también exige examinar el emisor y comparar el alcance solicitado con la política [12][13]. El registro posterior distingue la decisión de aceptación del resultado de la conexión, pues un fallo puede dejar solo una parte del paquete activa [5]. El descubrimiento y versionado de servidores a escala es otro trabajo.

Seis pasos, en el orden en que ocurre la decisión:

1. Comprobar plugin.json como identidad.
2. Separar las skills de los servidores MCP.
3. Decidir la aceptación por componente.
4. Decidir qué credencial recibe el servidor.
5. Leer el alcance en el desafío de autorización.
6. Instalar y registrar el inventario activo.

Paso 1: el manifiesto es identidad, no un contrato de permisos

En plugin.json se aceptan diez campos de nivel superior, de los cuales solo $schema y name son obligatorios. Ninguno define permisos portables. Un campo desconocido y un valor de extensions que no sea un objeto se notifican y se ignoran, y la carga continúa; las demás infracciones del esquema son fatales y el cliente rechaza el plugin sin descubrir ni ejecutar sus componentes [3][4].

Los demás campos del manifiesto plugin.json son version, description, author, homepage, repository, license, keywords y extensions; la ausencia de version no impide la instalación [4]. El nombre y la versión identifican el paquete, mientras que extensions puede contener datos específicos de un cliente. El manifiesto no define un permiso portable. "permissions": [...] en el nivel superior del manifiesto del plugin es una infracción del esquema: el cliente conforme notifica e ignora el campo sin atribuirle semántica [3][4]. La etiqueta no obliga a nadie. La diferencia está en el resultado: el paquete continúa con un campo desconocido, pero un name de tipo incorrecto provoca el rechazo antes del descubrimiento. La especificación recomienda que el cliente identifique el campo obligatorio inválido [4]. Si extensions no es un objeto, el campo se notifica y se ignora sin interrumpir la carga [3]. Dentro de un espacio de nombres implementado, la validación sigue las reglas del cliente; los espacios de nombres no implementados se ignoran [4].

El manifiesto identifica lo que se descargó. No responde a qué puede hacer el plugin.

Paso 2: separar los dos tipos de componente

La versión 1 estandariza las skills, instrucciones cargadas en el contexto, y los servidores MCP, procesos locales o conexiones remotas declaradas en el mcp.json del plugin. Ese archivo define el transporte y la configuración del servidor. Los comandos, hooks y agentes quedan a cargo de cada cliente, fuera del núcleo portable [1][3][9]. La aceptación empieza por la separación.

Una skill de plugin no es una llamada a una herramienta: es una instrucción cargada en el contexto cuando el descriptor coincide con la tarea [11], descubierta en un directorio fijo y validada individualmente [7]. El campo allowed-tools es opcional, experimental y tiene soporte variable [10]. No es un límite garantizado. Aceptar una skill de terceros significa aceptar contenido no confiable que puede influir en el modelo mediante las herramientas ya concedidas al agente. Su límite efectivo es el conjunto de herramientas expuesto por el host: revisar la skill exige examinar las instrucciones y el riesgo de inyección, no solo el esquema [7][10][11]. En el nivel superior de mcp.json solo se aceptan $schema y mcpServers. Stdio exige type y command, con args, env y cwd opcionales; el servidor remoto exige type y url, con cabeceras literales opcionales. sse está obsoleto, con soporte opcional [16]. El comando y los argumentos proceden del autor.

Los hooks pueden estar en el directorio de extensión del cliente [1][3]. Según VS Code, los hooks y los servidores MCP pueden ejecutar código en la máquina [14].

Paso 3: decidir los permisos de plugin de agente por componente

Los permisos de plugin de agente exigen una decisión por componente: una entrada de servidor inválida deshabilita solo esa entrada, una skill inválida no afecta a los demás tipos y un fallo de autenticación es un fallo de conexión [5][6]. Hay una excepción: un mcp.json inválido en el nivel superior deshabilita todo el MCP del plugin [16].

Un plugin de agente reúne superficies con límites diferentes. En la skill, allowed-tools depende del cliente y no garantiza la contención de las instrucciones [10]. En el servidor MCP stdio, command, args, env y cwd configuran el inicio del proceso, pero la contención de rutas gobierna los archivos del paquete: no aísla el subproceso ni restringe las rutas de ejecución [3][9]. En el servidor MCP remoto, el alcance del desafío orienta la autorización; si falta, se recurre a scopes_supported, cuando está definido, y la concesión puede diferir de la solicitud [12][13]. El autor declara componentes y configuraciones; su aplicación depende del cliente [2]. Una entrada de servidor inválida se ignora sin afectar a los demás componentes, mientras que un mcp.json inválido en el nivel superior deshabilita todo el MCP del plugin [5][6][16]. El rechazo selectivo de una entrada válida depende de las opciones del cliente, no es una garantía de la especificación. La tabla separa los límites:

La última columna decide. allowed-tools depende del cliente [10]. La contención de rutas gobierna los archivos del paquete, pero no aísla el subproceso ni restringe las rutas de ejecución [3][9]. En el servidor remoto, el alcance puede faltar y la concesión puede diferir de la solicitud [12][13]. El autor declara componentes y configuraciones; su aplicación depende del cliente [2].

Permiso mínimo de agente en producción: token efímero trata la tarea; aquí la unidad es el componente.

Paso 4: decidir qué credencial recibe el servidor

En stdio, la especificación recomienda obtener las credenciales del entorno y no seguir el flujo de autorización de MCP [12]. Una entrada cuyo env declara PLUGIN_ROOT o PLUGIN_DATA es inválida y se rechaza; en el entorno del proceso iniciado, el cliente define esas variables al final [5][16]. Conviene comparar las demás variables antes de la aceptación.

Quien configura el entorno base decide la identidad solo en las variables no declaradas por el paquete. Una colisión puede cambiar la credencial utilizada. Los nombres de env y del entorno base deben compararse antes de la aceptación. En un servidor MCP stdio válido, el cliente aplica el env del paquete sobre el entorno base y define al final PLUGIN_ROOT y PLUGIN_DATA en el entorno iniciado [5][16]. La regla no hace válida una entrada cuyo env declare esos nombres reservados: el cliente debe rechazar la entrada y continuar cargando los demás componentes [3][5]. Una cabecera configurada en mcp.json es un dato literal y visible del paquete, y no debe contener credenciales ni secretos [16]. La especificación lo prohíbe, pero no lo bloquea técnicamente. Un token pegado allí viaja con el paquete. La autorización de un servidor MCP remoto es opcional; cuando se utiliza, se aplica OAuth 2.1 con descubrimiento de metadatos y el cliente descubre el servidor de autorización mediante los metadatos del recurso protegido. La credencial se gestiona del lado del cliente [5][12].

Credenciales de agente en producción: el problema de la dispersión trata el inventario de credenciales.

Paso 5: leer el alcance en el desafío antes de aprobar

El servidor debería incluir scope en WWW-Authenticate, pero puede omitirlo: es una recomendación, no una garantía. Si está presente, el alcance del desafío es autoritativo para la operación. Sin él, se orienta al cliente a solicitar todos los alcances de scopes_supported, cuando está definido, en la selección inicial de alcances [12]. Antes del alcance, corresponde comprobar el emisor.

En la autorización de un servidor MCP remoto, el scope del desafío es autoritativo para la operación cuando está presente. No se presume ninguna relación entre los alcances del desafío y scopes_supported: el desafío puede contener alcances fuera de la lista [12]. Si ninguno de los dos está disponible, la orientación es omitir scope en la solicitud [12]. La concesión puede ser menor [13]. Quien aprueba debe comparar la solicitud y la concesión con la política, incluso en el caso alternativo. La URL resource_metadata del desafío y las URL authorization_servers de los metadatos pueden estar controladas por el servidor de terceros [13]. Validar el origen y el emisor esperado reduce el riesgo de dar consentimiento a un servidor de autorización ajeno; las URL también exigen protección contra SSRF. El cliente debe enviar resource, con la URI canónica del servidor MCP previsto, en las solicitudes de autorización y de token, aunque el servidor de autorización no lo admita [12]. El servidor MCP debe validar la audiencia y no aceptar un token emitido para otro destino.

El token passthrough está prohibido por las prácticas de seguridad de MCP [13]. El reenvío puede dificultar la auditoría; el cumplimiento de la prohibición depende del servidor aceptado.

Paso 6: instalar y registrar el inventario que quedó activo

Si un servidor falla al iniciar, conectar, autenticar o completar el handshake, el cliente continúa cargando los demás servidores y componentes [5], sin tratar el fallo como una configuración inválida. La instalación puede parecer completa con un servidor fuera. Registrar el resultado revela qué subconjunto quedó activo.

El inventario de un plugin de agente debe distinguir configuración, conexión y ejecución. Por componente, el registro guarda tipo, origen, credencial, resultado de la conexión, fecha y versión del cliente. Una entrada de servidor MCP inválida se ignora individualmente; un fallo de autenticación, por su parte, se trata como un fallo de conexión [5][6]. Son resultados distintos. Si la configuración del nivel superior de mcp.json es inválida, todo el MCP del plugin queda deshabilitado, aunque el cliente continúa cargando otros tipos de componente [16]. La especificación no define una alternativa tras el primer fallo de conexión [16]. Por eso, el transporte declarado y el resultado del intento deben aparecer en el inventario, en lugar de presumirse a partir de la aceptación inicial. La lista no aísla el subproceso [3][9]. Después de la carga, la comparación entre los componentes aceptados y los efectivamente activos indica qué quedó disponible para la política de tarea.

El límite de tasa por operación MCP es otra decisión, posterior a la carga de la herramienta.

Cómo verificar que el permiso en uso es el decidido

Tres comprobaciones cierran la verificación después de la instalación: listar los componentes cargados, comparar el alcance concedido con el decidido y registrar cada llamada con sujeto, herramienta y resultado. La primera muestra lo que quedó fuera; la segunda encuentra concesiones superiores a las previstas por la política.

Verificar los permisos de plugin de agente exige inventario, alcance y registro, en ese orden. El inventario registra tipo, origen, credencial, conexión, fecha y versión del cliente; la comparación con la aceptación revela los componentes que no se cargaron [5][16]. Para el servidor MCP remoto, el alcance del desafío es autoritativo para la operación cuando está presente, pero la concesión puede ser menor que la solicitud [12][13]. Comprobar ambos conjuntos evita tratar la solicitud como prueba del permiso efectivo. El registro de cada llamada asocia sujeto, herramienta y resultado con la actividad observada. Ninguna de estas comprobaciones convierte la contención de archivos en un sandbox: la especificación no aísla el subproceso ni restringe sus rutas de ejecución [3][9]. La matriz de mínimo privilegio y la trazabilidad están en Permisos y acceso de agentes de IA: define y rastrea. La política de tarea es una decisión separada de la aceptación del componente.

El paquete sigue siendo válido.

Errores que se repiten

Se repiten cuatro errores: confundir validación con sandbox, aprobar el paquete como decisión única, extender la confianza del marketplace al plugin y suponer que un fallo de autenticación desinstala el resto. Ninguno suele aparecer en el registro como error, y por eso persiste. Si solo se buscan fallos de ejecución, los cuatro pasan inadvertidos.

En el plugin de agente, el esquema y la contención describen el paquete, no imponen un sandbox [3]. La validación de rutas de archivos no restringe las rutas de ejecución de un subproceso después de que inicia [3][9]. La aceptación única también oculta el subconjunto activo [5][16]. Un fallo de conexión de un servidor MCP no revierte el paquete: el cliente continúa cargando otros servidores y componentes [5]. Una entrada inválida y un mcp.json inválido en el nivel superior también producen resultados diferentes, respectivamente el rechazo de la entrada y la deshabilitación del MCP del plugin [5][16]. La confianza en el marketplace no cubre automáticamente la del plugin: VS Code pide revisar el editor y confiar en el primer plugin de cada marketplace [14]. El manifiesto tampoco sustituye la decisión de permiso: ninguno de los diez campos de nivel superior define autorización portable [3][4]. Para el servidor remoto, la aprobación debe incluir el emisor y el alcance, incluso cuando el desafío no informa scope [12][13].

Los permisos de plugin de agente exigen decisiones más allá de la etiqueta. Control de modelos en agentes de IA en producción trata otra capa.

Preguntas frecuentes

El manifiesto de un plugin de agente no ofrece permisos portables. Los datos en extensions dependen del cliente; el rechazo de un servidor inválido no garantiza el rechazo selectivo de una entrada válida. En la autorización remota, el desafío orienta la solicitud. La validación del paquete y el aislamiento de la ejecución son decisiones diferentes [3][4][5][12].

En la especificación Agent Plugins 1.0.0, extensions puede transportar datos específicos de un espacio de nombres implementado por el cliente, pero no establece un permiso portable [4]. Una entrada de servidor MCP inválida se ignora mientras los demás componentes continúan cargándose; la opción de rechazar selectivamente una entrada válida depende del cliente [5][6]. En la autorización MCP remota, el scope presente en el desafío es autoritativo para la operación. Sin scope, la orientación es solicitar todos los alcances de scopes_supported, cuando está definido, u omitir el parámetro si ninguno de los dos está disponible [12]. La concesión puede ser menor [13]. Una cabecera literal de mcp.json no debe contener credenciales ni secretos, aunque el formato no impide incluirlos [16]. La validación de rutas protege la lectura de archivos del paquete, pero no ofrece un sandbox ni limita las rutas accesibles para el subproceso en ejecución [3][9].

¿Puede el campo extensions transportar un permiso?

Puede transportar semántica de permiso específica, pero no un permiso portable. En extensions, el propietario del espacio de nombres define el contenido y su validación; el cliente que implementa ese espacio de nombres puede aplicarlo [4]. La documentación del cliente instalado define esa semántica; los espacios de nombres que no implementa se ignoran.

¿Se pueden aceptar solo las skills y rechazar el servidor MCP?

Es posible si el cliente ofrece el rechazo selectivo de un servidor válido; la especificación no garantiza esa opción. En un caso diferente, una entrada inválida se ignora y el cliente continúa cargando los demás componentes, incluidas las skills compatibles [5][6]. Pero un mcp.json inválido en el nivel superior deshabilita el MCP del plugin completo [16].

¿Quién aprueba el alcance cuando el servidor MCP es de un tercero?

Quien instala, conforme a la política de la organización. Si el desafío contiene scope, es autoritativo para la operación, sin relación presumida con scopes_supported [12]. Si no lo contiene, se orienta al cliente a solicitar todos los alcances anunciados cuando estén disponibles. La solicitud y el emisor deben revisarse antes de la aprobación.

¿Puede mcp.json transportar una credencial en una cabecera?

No debe hacerlo. Una cabecera configurada en mcp.json es visible para quien instala y no puede contener credenciales ni secretos [16]. La prohibición es normativa, no técnica: nada en el formato impide que un autor pegue un token allí, y el token viaja con el paquete.

¿La validación del paquete aísla lo que ejecuta el plugin?

No. La validación ofrece una descripción del paquete, no una frontera para el proceso [3], y el sandbox de ejecución es una elección del cliente que el formato no impone: una vez que el servidor inicia, lo que puede alcanzar no depende del esquema.

Referencias y lecturas complementarias

Las fuentes primarias separan el formato del plugin, el comportamiento del cliente y la autorización MCP. La especificación Agent Plugins 1.0.0 define el manifiesto y la carga; la especificación MCP define la selección de alcances para la autorización remota. La documentación del cliente registra comportamientos específicos que no son portables [3][4][12][14].

La especificación Agent Plugins 1.0.0 describe el manifiesto cerrado, los dos tipos de componente y los límites de los fallos durante la carga [3]. La referencia del manifiesto detalla extensions y los campos aceptados [4]; la documentación de servidores MCP cubre mcp.json, transportes y configuración [16]. La especificación Agent Skills describe allowed-tools, mientras que la página de skills del plugin trata el descubrimiento [7][10]. La autorización MCP establece la prioridad entre el scope del desafío y scopes_supported [12]. Las prácticas de seguridad de MCP abordan la audiencia, el emisor y el token passthrough [13]. La documentación de VS Code describe la revisión del editor y la confianza en el primer plugin de cada marketplace, una regla de ese cliente [14]. La lista de clientes compatibles y el anuncio ofrecen las dos cifras citadas, sin medir madurez [1][8]. El material también distingue los fallos de conexión de las configuraciones inválidas [5][6].

Fuentes consultadas el 13 de noviembre de 2026.

1. Vercel, Introducing Agent Plugins, publicado el 6 de agosto de 2026.
2. Agent Plugins, página principal de la especificación.
3. Agent Plugins, Specification 1.0.0.
4. Agent Plugins, Plugin manifest.
5. Agent Plugins, MCP runtime.
6. Agent Plugins, Client conformance checklist.
7. Agent Plugins, Skills.
8. Agent Plugins, Compatible Clients.
9. Repositorio de la especificación, agent-plugins-spec.
10. Agent Skills, Specification.
11. Agent Skills, página principal.
12. Model Context Protocol, Specification 2026-07-28, Authorization.
13. Model Context Protocol, Security Best Practices.
14. Visual Studio Code Docs, Agent plugins in VS Code.
15. GitHub Docs, Plugins for GitHub Copilot.
16. Agent Plugins, MCP servers.

Qué hacer con el primer paquete aceptado

Con el inventario en la mano, cada herramienta aceptada necesita una política de tarea. Componente, credencial y alcance deciden qué entra; la política decide qué puede hacer después la herramienta. Son decisiones separadas, con registros para compararlas más adelante.

Nexforce Agents incluye Nexforce Work para equipos no técnicos, con aprobaciones, sandbox, gestor de skills y conectores MCP, y Nexforce Code para terminal, IDE y CI. En ambos, Nexforce Router es la capa de inferencia. Ningún material público consultado documenta el alcance por plugin ni la emisión de credenciales por componente en estos productos. La especificación Agent Plugins 1.0.0 tampoco define permisos portables en el manifiesto [3][4]. El equipo debe comprobar en el cliente instalado qué componentes se cargaron y comparar el resultado con el inventario de aceptación. Para el servidor MCP remoto, el alcance solicitado y el efectivamente concedido deben compararse con la política, pues la concesión puede ser menor [12][13]. La lista de componentes no sustituye el aislamiento de procesos: las reglas de contención del paquete no son un sandbox [3][9]. Después de la aceptación, la política de tarea y el registro de sujeto, herramienta y resultado tratan el uso de las herramientas.

El paquete llega con identidad. El permiso sigue siendo tuyo.