ES
Menú
Referencia del framework

Límites de ejecución de los agentes

Por qué las instrucciones para agentes deben acompañarse de permisos, aislamiento y límites de acceso aplicados técnicamente.

Las instrucciones orientan; los permisos limitan

A un agente se le puede indicar que no lea registros sensibles, instale una dependencia, acceda a Internet o modifique un repositorio protegido. Esa instrucción por sí sola no hace imposible la acción. Si las herramientas y credenciales del agente lo permiten, la empresa sigue expuesta a errores, malentendidos y usos indebidos.

Por eso, el marco SHAPE exige que los agentes de programación operen en entornos de ejecución aprobados por la empresa con permisos y límites aplicados técnicamente. La seguridad forma parte de la plataforma proporcionada al Product Engineer, no de una colección de frases aspiracionales en un archivo Markdown.

Qué abarcan los límites

Los controles pertinentes dependen de la aplicación y la organización, pero pueden incluir qué repositorios puede leer o escribir un agente, qué comandos y herramientas puede ejecutar, si puede acceder a redes o servicios externos, qué credenciales puede obtener, a qué entornos de datos puede acceder y si es posible cambiar recursos compartidos protegidos sin autorización adicional.

El acceso mínimo necesario

Proporcione únicamente las capacidades necesarias para la tarea de desarrollo autorizada. Un agente de programación que implementa una interfaz de usuario no debe recibir automáticamente un acceso amplio a los datos de producción. Una solicitud de integración nueva no debe conceder silenciosamente credenciales o permiso para alterar infraestructura compartida.

Separación de responsabilidades

El Product Engineer dirige el trabajo dentro del entorno aprobado. Los arquitectos y los responsables empresariales de plataformas y seguridad establecen o aprueban los límites adecuados a sus responsabilidades. Un agente no debe poder eludir la gobernanza requerida simplemente editando sus propios archivos de instrucciones.

La revisión sigue siendo necesaria

Un límite de ejecución seguro acota lo que puede hacer un agente; no establece que el código generado sea correcto. La revisión de código, los controles de seguridad de la aplicación, la verificación independiente y las UAT siguen siendo pertinentes. A la inversa, una revisión de código sólida no compensa un entorno de ejecución que expone innecesariamente datos sensibles.

Ajustar los controles al riesgo

El marco no prescribe un proveedor, un producto ni una configuración universal de entorno aislado. Las empresas implementan restricciones que se ajusten a sus aplicaciones, clasificaciones de riesgo y políticas de seguridad establecidas. Los entornos sensibles o regulados pueden requerir controles más estrictos.