Consideraciones sobre acceso a datos y permisos
El modelo de seguridad de Salesforce en REDA AI
Todo el acceso a datos a través de los agentes de REDA AI se rige por el completo modelo de seguridad de Salesforce:
- Seguridad a nivel de campo (FLS) — Los agentes no pueden leer ni escribir campos a los que el usuario no tiene acceso
- Permisos a nivel de objeto — Los agentes no pueden consultar ni crear registros en objetos a los que el usuario no puede acceder
- Colaboración de registros — Los agentes solo pueden acceder a los registros compartidos explícitamente con el usuario
- Jerarquía de roles — Los gerentes pueden ver los registros de sus subordinados según las reglas de la jerarquía de roles
- Grupos públicos y equipos — Se respeta la colaboración mediante grupos y equipos
REDA AI no elude la colaboración de registros. En todos los canales, un agente solo alcanza registros que el usuario en ejecución ya podía alcanzar.
Existe una excepción deliberada, y afecta únicamente a los permisos de objeto y de campo: un agente cuyo Contexto de ejecución sea Sistema y cuyo Canal sea API lee campos que el usuario en ejecución no puede ver. Se exigen ambas condiciones, la combinación ni siquiera puede guardarse en otros canales y la colaboración nunca se amplía: un agente elevado ve más columnas de registros que ya podía alcanzar, nunca un registro nuevo. En todo lo demás, el agente opera exactamente como el usuario que inició sesión. Consulta Seguridad de los datos.
Conjuntos de permisos para REDA AI
REDA AI incluye varios conjuntos de permisos para controlar quién puede acceder a los agentes:
| Conjunto de permisos | Caso de uso | Nivel de acceso |
|---|---|---|
| REDAAI_Admin | Administradores que configuran y gestionan agentes | Pueden crear, editar y eliminar agentes; configurar todas las opciones |
| REDAAI_User | Usuarios estándar que utilizan agentes (canal interno) | Pueden chatear con los agentes; se respetan sus permisos de Salesforce |
| REDAAI_Community_User | Usuarios de portal que acceden a los agentes mediante el canal de Comunidad | Pueden chatear con los agentes; se respetan los permisos del usuario del portal |
| REDAAI_External_Guest_User | Visitantes del sitio web que utilizan el canal del widget externo | Pueden chatear con los agentes; se respetan los permisos del perfil de usuario invitado |
Asigna el conjunto de permisos adecuado a los usuarios según su rol. Los usuarios sin un conjunto de permisos no pueden interactuar con los agentes.
Cómo funciona la seguridad por canal
Canal interno
Los usuarios se autentican mediante el inicio de sesión de Salesforce. El agente opera como el usuario que inició sesión:
- Se aplica el FLS del usuario — El agente solo puede acceder a los campos que el usuario puede leer o escribir
- Se aplican los permisos de objeto del usuario — El agente solo puede trabajar con los objetos a los que el usuario puede acceder
- Se aplican las reglas de colaboración del usuario — El agente solo puede ver o modificar los registros compartidos con el usuario
- Ejemplo: un agente de soporte que utiliza un representante de atención al cliente solo puede acceder a los registros de Caso y Contacto compartidos con ese representante
Canal de Comunidad
Los usuarios de portal acceden a los agentes a través de una experiencia de portal. La seguridad se basa en el perfil del usuario del portal:
- Se aplica el FLS del usuario del portal
- Se aplican los permisos de objeto del usuario del portal
- Los usuarios de portal normalmente solo ven sus propios registros (cuenta, casos, contactos)
- Los valores predeterminados de toda la organización y el perfil del usuario del portal restringen la visibilidad de los datos
Canal del widget externo
Los visitantes del sitio web utilizan los agentes sin autenticación de Salesforce. La seguridad se basa en el perfil de Usuario invitado configurado en el sitio:
- Se aplica el FLS del perfil de Usuario invitado — Muy restringido para usuarios externos
- Se aplican los permisos de objeto del perfil de Usuario invitado — Normalmente muy limitados
- Los usuarios invitados normalmente solo pueden acceder a los datos publicados y a los registros compartidos públicamente
- Sé conservador: asigna únicamente las herramientas que tengan sentido para invitados no autenticados
Canal API
Un agente del canal API lo activa otro sistema, no una persona, así que se ejecuta de forma desatendida como un usuario de integración o automatización, y no como quien inició el proceso. Todo lo anterior sigue aplicándose: el uso compartido de registros, los permisos de objeto y la seguridad a nivel de campo de ese usuario rigen lo que el agente puede hacer, salvo que pongas el Contexto de ejecución en Sistema en el agente, algo posible solo en este canal, que eleva el acceso a objetos y campos (nunca a la colaboración). Si lo haces, los permisos de campo del usuario de integración dejan de ser el límite, así que decídelo de forma deliberada.
Esto crea un problema práctico que los demás canales no tienen. Como un agente de REDA AI decide qué consultar según el contexto, no siempre puedes enumerar de antemano todos los objetos y campos que podría tocar, así que acertar con los permisos del usuario de integración es difícil: el agente funciona en pruebas y luego falla con un registro que nadie previó.
Contexto de ejecución
Contexto de ejecución, en el registro Definición de agente, resuelve esto. Tiene dos valores:
- Usuario (el predeterminado): las herramientas del agente aplican los permisos de objeto y de campo del usuario que ejecuta, igual que en los demás canales.
- Sistema: las herramientas del agente dejan de aplicar los permisos de objeto y de campo. Esto solo tiene efecto en el canal API; si lo configuras en un agente de cualquier otro canal, se ignora.
Lo acotan tres controles:
| Control | Qué significa |
|---|---|
| Solo el canal API | Se ignora en los demás canales. Los agentes internos se ejecutan como la persona conectada, donde sus propios permisos son el límite correcto; los agentes de comunidad y del widget externo se ejecutan como invitado, donde omitir permisos no sería seguro. |
| Solo administradores | Es un campo del registro Definición de agente, editable mediante el conjunto de permisos REDAAI Admin. El agente no puede activarlo por sí mismo y ninguna instrucción escrita en un prompt puede cambiarlo. |
| Cada llamada elevada queda registrada | Cada vez que una herramienta se ejecuta omitiendo permisos, se escribe una entrada en el registro de incidencias con la herramienta, el objeto de destino y el usuario con el que se ejecutó, de modo que «¿qué hizo este agente con acceso elevado?» siempre tiene respuesta. |
Deja Contexto de ejecución en Usuario salvo que tengas un agente de API desatendido que esté fallando por permisos. No es una opción de rendimiento y no aporta nada activarla por si acaso. Cuando la uses, el patrón más seguro sigue siendo conceder al usuario de integración el acceso que necesita y mantener Contexto de ejecución en Usuario; recurre a Sistema cuando esa lista realmente no pueda definirse de antemano.
El FLS en acción
Ejemplo de seguridad a nivel de campo:
Tu agente está configurado con Account.AnnualRevenue como campo de contexto. Un representante de Recursos Humanos tiene acceso de lectura al campo por FLS. Un representante de ventas NO tiene acceso al campo por FLS (política de la empresa: ventas no debería ver los ingresos).
Cuando el representante de RR. HH. abre una cuenta, el agente ve AnnualRevenue en el contexto. Cuando el representante de ventas abre la misma cuenta, el agente NO ve AnnualRevenue (el FLS lo impide). Cada usuario ve datos distintos según sus permisos de FLS.
Ejemplo de colaboración de registros
Ejemplo de reglas de colaboración:
Se implementa un agente de soporte para que lo utilicen los representantes de soporte. Al representante A se le han asignado los Casos 001, 002 y 003. El representante A abre el Caso 001 y chatea con el agente. El agente puede consultar y modificar el Caso 001 porque el representante A tiene acceso.
El representante A intenta preguntarle al agente sobre el Caso 099 (asignado al representante B). El agente no puede acceder al Caso 099 porque el representante A no tiene acceso de colaboración a él. Si el representante A intenta usar herramientas para consultarlo, obtiene un error de permisos.
Widget externo: seguridad del perfil de Usuario invitado
A los agentes del widget externo acceden visitantes del sitio web no autenticados. Aquí la seguridad es fundamental:
- Configura un perfil de Usuario invitado restrictivo — El perfil debe tener los permisos mínimos
- Revisa el FLS con cuidado — Expón únicamente los campos que sean seguros para su visualización pública (sin datos confidenciales)
- Limita las asignaciones de herramientas — Los agentes del widget externo normalmente no deben tener herramientas de escritura (nada de create_record ni update_record)
- Prueba a fondo — Usa un navegador de incógnito para simular el acceso de invitado y verificar que los datos estén debidamente restringidos
Ejemplo: un visitante del sitio web que chatea con un agente de soporte de widget externo debería poder:
- Buscar artículos de la base de conocimiento (solo lectura)
- Enviar un caso de soporte (create_record restringido a su propio caso)
- Consultar el estado de un caso (soql_query limitado a sus propios casos)
NO debería poder:
- Ver los casos de soporte de otros clientes
- Acceder a datos de empleados
- Modificar datos de precios o de configuración
Prácticas recomendadas para una implementación segura de agentes
Asigna los permisos y las herramientas mínimos necesarios. Los agentes del widget externo deben ser los más restrictivos, los agentes internos algo más permisivos y los agentes de administración los más abiertos.
Revisa el FLS antes de implementar — Antes de agregar un campo como campo de contexto, verifica que todos los usuarios que utilizarán el agente deban tener acceso a ese campo. No expongas datos confidenciales por accidente.
Asigna las herramientas de escritura con cuidado — Las herramientas como create_record, update_record, delete_record y send_email deben restringirse a los agentes en los que estas acciones sean apropiadas. Los widgets externos rara vez necesitan herramientas de escritura.
Prueba como distintos usuarios — Prueba tus agentes con la sesión iniciada como:
- Un usuario estándar con permisos básicos
- Un usuario con permisos restringidos (sin acceso a ciertos objetos)
- Un usuario invitado (para widgets externos)
Verifica que cada usuario vea únicamente los datos que está autorizado a ver.
Supervisa la ejecución de herramientas — Revisa los registros para ver qué herramientas invocan los agentes y qué usuarios las utilizan. Identifica y aborda cualquier patrón sospechoso.
Inquietudes de seguridad comunes y soluciones
| Inquietud | Solución |
|---|---|
| El agente podría exponer campos confidenciales | Usa el FLS para impedir el acceso. Verifica el FLS en los campos sensibles (salario, número de seguro social, etc.) |
| Usuarios externos podrían acceder a datos internos | Usa un perfil de Usuario invitado restrictivo para los agentes del widget externo. Prueba a fondo. |
| Los usuarios podrían crear o actualizar registros equivocados por accidente | Las herramientas de acción muestran tarjetas de confirmación. Usa prompts con medidas de protección para evitar el uso indebido. |
| Los agentes podrían eludir las reglas de colaboración | Imposible: REDA AI opera dentro de las reglas de colaboración. Los agentes no pueden acceder a los registros que el usuario no puede ver. |
| Los agentes podrían consultar datos sensibles | Usa prompts y medidas de protección para restringir el comportamiento del agente. Prueba los resultados de las consultas. |
Conectar agentes mediante MCP
MCP conecta un asistente aprobado con agentes activos seleccionados del canal Interno. Cada persona inicia sesión con su identidad Salesforce. El cliente recibe puntos de entrada de agentes, no herramientas y prompts individuales publicados como herramientas MCP. Configure un Sitio, una aplicación cliente externa, las asignaciones REDA AI User y REDA AI MCP User, y la activación del agente. Consulte la guía de administración y la guía de uso. Los datos pueden llegar al asistente y a los proveedores de IA configurados además de Salesforce. Revise datos y acuerdos; no se garantiza que la información nunca salga de Salesforce.
Preguntas frecuentes
No. REDA AI opera como el usuario que inició sesión. Si el usuario no puede ver un registro, el agente tampoco puede. Esto se aplica en la capa de datos.
El campo no se devuelve. Si está configurado como campo de contexto, se omite del contexto. Si el agente lo consulta mediante una herramienta, se excluye de los resultados. No se muestra ningún error al usuario: el agente simplemente no ve el campo.
Solo si asignas explícitamente la herramienta create_record y el perfil de Usuario invitado tiene permisos de creación sobre ese objeto. Esto rara vez se recomienda. Para la mayoría de los widgets externos, usa herramientas de solo lectura o permisos de creación muy restringidos.
No asignes la herramienta delete_record al agente. Si la herramienta no está asignada, el agente no puede invocarla. Como alternativa, usa el perfil de Usuario invitado o el FLS para impedir las operaciones de eliminación en la capa de datos.
Próximos pasos
Revisa la configuración del canal interno para implementar agentes para tu equipo, o explora la implementación del widget externo para agentes de cara al cliente.