¿Los agentes de Agentforce eluden el uso compartido de Salesforce?

Toda conversación sobre seguridad en torno a Agentforce empieza con la misma pregunta: ¿los agentes eluden nuestras reglas de uso compartido? La respuesta breve es no, y entender por qué explica tanto que Agentforce sea seguro por diseño como dónde reside el verdadero riesgo.

Los agentes se ejecutan como un usuario y heredan su acceso

Un agente de Agentforce no dispone de una visión mágica propia de tus datos. Se ejecuta como un usuario de Salesforce, y cada recuperación de datos que realiza se comprueba contra los elementos siguientes de ese usuario:

• Permisos de objeto (perfil + conjuntos de permisos)
• Seguridad a nivel de campo
• Uso compartido a nivel de registro: valores predeterminados de toda la organización, jerarquía de funciones, reglas de uso compartido, comparticiones manuales e implícitas

Si el usuario de ejecución no puede ver un registro, el agente tampoco. Agentforce opera dentro del mismo modelo de seguridad empresarial (perfiles, conjuntos de permisos, uso compartido, acceso basado en funciones) que rige el resto de tu organización. Además, admite políticas basadas en atributos por encima de ese modelo, para reglas del tipo «solo los agentes de ventas de la UE pueden activar este flujo de trabajo».

Los agentes de Agentforce no eluden los permisos de Salesforce. Utilizan de forma agresiva cualquier acceso que ya exista.

Esa segunda frase resume toda la cuestión.

El verdadero riesgo: exposición amplificada, no elusión

Aquí viene la parte incómoda. La mayoría de las organizaciones tienen mucho más uso compartido abierto del que nadie recuerda haber configurado: años de reglas de uso compartido, conjuntos de permisos amplios, acumulaciones de la jerarquía de funciones y comparticiones manuales «temporales» que nunca se retiraron.

Una persona casi nunca tropieza con todo el alcance de aquello a lo que técnicamente puede acceder. Abre los registros con los que trabaja e ignora el resto. Un agente no. Hazle una pregunta y recuperará, combinará y resumirá todo lo que esté al alcance del usuario de ejecución, incluidos datos que ese usuario había olvidado que podía ver.

Así que el agente no concede acceso nuevo. Expone el acceso que ya tenías, de forma conversacional e instantánea. El uso compartido demasiado amplio que permaneció latente durante años queda ahora a una sola frase de distancia.

Por qué los agentes cambian las cuentas del riesgo

Dos cosas hacen que esto sea distinto de una persona con los mismos permisos:

1. Velocidad y escala. Un agente lee y combina registros mucho más rápido que cualquier humano, de modo que un permiso mal acotado se explota de inmediato y de forma repetida.
2. Sin punto de control de aprobación. Una vez desplegados, los agentes actúan según su configuración y contexto sin detenerse a esperar una revisión humana, eliminando un punto de control en el que el modelo de seguridad tradicional se apoyaba discretamente.

El modelo de permisos no se ha vuelto más débil. Lo que hace uso de él se ha vuelto mucho más exhaustivo.

Qué hacer antes de desplegar

La solución no es desconfiar de Agentforce, sino saber qué puede ver su usuario antes de activarlo:

1. Ejecuta una revisión de accesos para el usuario de ejecución del agente, a nivel de objeto y de registro. La pregunta relevante es la misma sobre la que trata todo este blog: quién puede ver qué, y por qué. Para una guía paso a paso, consulta cómo auditar el acceso a los registros antes de desplegar un agente de IA.
2. Refuerza la base de partida. Configura los valores predeterminados de toda la organización tan restrictivos como permita el negocio; el acceso solo se amplía a partir de ahí.
3. Depura las reglas de uso compartido y los conjuntos de permisos. Elimina las concesiones amplias y obsoletas que, de otro modo, el agente heredaría.
4. Da al agente su propia identidad de mínimo privilegio en lugar de un perfil humano amplio, junto con políticas basadas en atributos.
5. Vuelve a comprobarlo tras cada cambio de uso compartido: el acceso se desvía con el tiempo, y también lo que el agente puede alcanzar.

Saber qué puede ver el agente, en lenguaje claro

Los pasos 1 y 5 son los difíciles: reconstruir el acceso efectivo real de un usuario a través del CRUD, la seguridad a nivel de campo y seis mecanismos de uso compartido, y luego mantenerlo actualizado a medida que la organización cambia.

Eso es exactamente lo que hace AgentForceAccess. Pregunta, en lenguaje claro, qué puede ver realmente un usuario (o el usuario de ejecución de tu agente) y rastreará cada concesión, citando el mecanismo que la respalda. Es la revisión de accesos que convierte el «creemos que el agente está bien acotado» en «sabemos que lo está» antes de desplegarlo.

Preguntas frecuentes

¿Los agentes de Agentforce ignoran las reglas de uso compartido y se ejecutan como administrador?

No. Un agente se ejecuta como un usuario concreto de Salesforce y queda limitado por el perfil de ese usuario, sus conjuntos de permisos, la seguridad a nivel de campo y el modelo de uso compartido de registros. No puede ver registros que ese usuario no pudiera ver. Ahora bien, si el usuario de ejecución tiene privilegios excesivos, el agente hereda ese exceso de privilegios.

¿Entonces por qué se considera el acceso de la IA un riesgo de seguridad si respeta los permisos?

Porque la mayoría de las organizaciones han acumulado más uso compartido abierto del que nadie es consciente. Una persona rara vez se topa con todos los registros a los que técnicamente puede acceder; un agente, en cambio, los recuperará y resumirá encantado en cuanto se lo pidas. El agente no crea acceso nuevo: expone el acceso que ya tenías.

¿Cuál es la única cosa más importante que hacer antes de desplegar un agente?

Audita qué puede ver realmente el usuario de ejecución del agente, objeto por objeto y a nivel de registro. Restringe los valores predeterminados de toda la organización, las reglas de uso compartido y los conjuntos de permisos para que el usuario (y, por tanto, el agente) tenga solo el acceso que necesita, y luego despliega.

¿Puedo dar a un agente un acceso más restringido que el del usuario que lo ejecuta?

Sí. Aprovisiona un usuario dedicado de mínimo privilegio o una configuración específica de conjuntos de permisos para el agente, en lugar de reutilizar un perfil humano amplio, y añade encima políticas basadas en atributos. El agente debería tener el acceso mínimo necesario para su tarea.