Decide quién puede usar el agente, quién puede ver su contexto y sus resultados y quién puede configurarlo o revisarlo. Comprueba por separado el acceso a la experiencia pública, al espacio de trabajo y a la administración, además de los permisos del agente para usar herramientas o cambiar registros.
Sigue una consulta de soporte por tres contextos
Supongamos que un equipo de soporte ofrece un agente público para consultas básicas. La política pública aprobada para devoluciones indica que se debe solicitar una etiqueta mediante el formulario de soporte antes de enviar el artículo. Una nota privada de soporte dice que la cuenta de esta persona tiene una excepción de devolución sin resolver. Una persona especialista puede consultar esa nota en el espacio de trabajo del equipo; no debe aparecer en una respuesta pública. Una persona administradora gestiona los ajustes y el acceso de ambas experiencias.
La respuesta para la página pública podría ser:
«Para solicitar una etiqueta de devolución, envía el formulario de soporte antes de enviar el artículo. Para recibir ayuda con tu cuenta, comunícate con una persona especialista de soporte».
Por separado, quien realiza la revisión interna registra que la respuesta usa solo la política pública aprobada. La excepción privada queda disponible únicamente para una persona especialista autorizada en el espacio del equipo. La respuesta al visitante no incluye la nota ni revela que existe la excepción.
Estas son expectativas de diseño para el ejemplo. Confirma cómo la aplicación real reconoce a cada persona, a qué información puede acceder cada superficie y qué registros puede revisar una persona administradora.
Comprueba el acceso por separado en la experiencia pública, el espacio del equipo y la administración.
Revisa los tres límites operativos
Desplázate horizontalmente para ver todas las columnas.
| Contexto | Preguntas que conviene responder | Evidencia que se debe examinar |
|---|---|---|
| Audiencia y superficie | ¿Quién puede iniciar una conversación o enviar trabajo? ¿La experiencia es pública, está integrada en otra aplicación o solo admite personas autenticadas? | Comprobaciones de sesión y origen, ajustes de audiencia, entradas que puede enviar el público e información que la superficie puede devolver. |
| Espacio de trabajo | ¿Qué miembros del equipo pueden ver o cambiar el contexto, las conversaciones, los resultados y los materiales de trabajo del agente? ¿Están separados de la experiencia pública? | Integrantes del espacio, responsables de las fuentes, visibilidad de resultados y actividad, y reglas para compartir o exportar. |
| Administración | ¿Quién puede configurar instrucciones, fuentes, herramientas, despliegue y acceso? ¿Quién puede consultar registros operativos o cambiar la audiencia? | Roles administrativos, historial de configuración, acceso a sistemas conectados, registros de revisión y proceso para retirar el acceso. |
Para cada límite, define quién es responsable y qué debe ocurrir si una persona o solicitud queda fuera de su alcance. Verifica esas expectativas en la interfaz y los sistemas conectados. Que una página parezca privada no demuestra por sí solo que estén restringidas las llamadas a datos o herramientas subyacentes.
Una matriz de permisos puede comparar los recursos con las acciones —leer, redactar, actualizar, enviar y aprobar— dentro de cada contexto. Sirve para comprobar qué puede hacer el agente; no representa el acceso a la audiencia, al espacio de trabajo ni a la administración.
Separa los límites de audiencia de los permisos de acción
Un límite de audiencia pregunta quién puede entrar a una experiencia o ver su información. Una revisión de permisos de acción pregunta qué pueden leer, crear, actualizar, enviar o aprobar las herramientas del agente. Ambas cosas se relacionan, pero pueden fallar por separado: una interfaz pública bien delimitada aún podría llamar a una herramienta demasiado potente, mientras que una herramienta de solo lectura podría devolver información a la audiencia equivocada.
En el ejemplo de soporte, la persona visitante recibe la respuesta de la política pública, mientras que una persona especialista puede consultar una nota interna en un contexto de trabajo separado. La persona administradora puede gestionar la configuración, pero la visitante no puede cambiarla. Antes de confiar en esa separación, el equipo debe verificar que así funcione la ruta desplegada.
Vuelve a trazar los límites si cambian la audiencia, las personas del espacio de trabajo, las fuentes de contexto, la superficie de despliegue o el grupo de administración. Para revisar herramienta por herramienta, continúa con cómo revisar las herramientas y el acceso a datos de un agente. Consulta permisos y límites y la lista de control de seguridad para una revisión de acceso más amplia. La descripción pública actual de AgentShelf está en la página de Confianza y límites; confirma el comportamiento del producto según la ruta configurada.