Permisos de agentes de IA: por qué el nuestro pregunta primero

Toda conversación sobre desplegar un agente de IA en una firma regulada llega tarde o temprano a la misma frase, normalmente dicha en voz baja: "Así que esta cosa tiene credenciales e iniciativa propia." Esa frase merece una respuesta mejor que un gesto tranquilizador. Un software que decide por sí mismo qué hacer a continuación es un actor genuinamente nuevo dentro de un entorno controlado, y los controles que funcionaban para el software determinista - cuentas de servicio, roles estáticos, revisiones de acceso trimestrales - presuponen un actor que hace lo mismo cada día. Un agente no. El sentido de un agente es precisamente que usted no enumeró sus acciones por adelantado.

Así que la pregunta de permisos no es "qué puede hacer el modelo" - los modelos emiten texto, nada más. Es: qué capacidades ha concedido su organización a esta sesión, quién las concedió, qué ocurre cuando el agente llega a su límite, y si puede demostrar las tres cosas después. Este artículo es nuestra respuesta a cada parte.

La capacidad es un permiso, no un valor por defecto

En DataQube, una sesión de agente empieza sin nada. Cada capacidad que posee - leer un almacén concreto, abrir un repositorio de documentos, ejecutar un flujo de trabajo, escribir un borrador en su propio espacio - existe porque un permiso específico lo dice. Los permisos se conceden por persona y por espacio de trabajo: la organización fija una base para el espacio, el espacio puede estrecharla, y la sesión de una persona sostiene la intersección entre lo que el espacio permite y aquello a lo que esa persona tiene derecho individualmente. Un agente que trabaja para una analista nunca puede más que esa analista; no hay una identidad de sistema con superpoderes detrás del telón.

Tres propiedades convierten esto en un sistema de control y no en una página de ajustes:

• La revocación surte efecto de inmediato. Retire un permiso y a la siguiente ejecución ya le falta esa capacidad. No hay acceso ambiental cacheado que tenga que caducar.
• Una denegación vence a cualquier permiso. Las barreras de información se expresan como denegaciones explícitas, y una denegación explícita prevalece sobre todo permiso que de otro modo aplicaría. No hay combinación de permisos que rodee una barrera argumentando.
• El trabajo delegado hereda el techo. Un flujo programado se ejecuta con el acceso de su propietario - programar algo nunca amplía lo que puede tocar. Si el propietario pierde un permiso el martes, la ejecución del miércoles es más estrecha, automáticamente.

El diseño rechazado es el que trae la mayoría de las herramientas: un regulador de "autonomía" - baja, media, total - que fija cuánto puede hacer el agente en todas partes, para todos. Creemos que esa abstracción no sobrevive al contacto con una empresa. La autonomía no es un temperamento; es una decisión por capacidad, por persona y por espacio de trabajo, y fingir lo contrario solo traslada las decisiones reales a un lugar que nadie puede auditar.

El agente se detiene y pregunta

Los permisos cubren las capacidades sobre las que usted decidió por adelantado. Los momentos interesantes son los otros.

Cuando un agente de DataQube llega a una acción que su política marca como sensible - enviar algo fuera del espacio de trabajo, escribir en una ubicación compartida, ejecutar una acción marcada como preguntar-primero -, no adivina y no falla en silencio. Se detiene, a mitad de ejecución, y pregunta a una persona. La pregunta es específica: esta acción, estos parámetros, este destino - no un vago "¿permitir que el agente continúe?". La persona puede aprobar una vez, aprobar para el espacio de trabajo o negarse, y la ejecución continúa o se redirige en consecuencia.

Dos detalles importan más que el titular. Primero, la pregunta encuentra a la persona correcta. Una aprobación que solo funciona si la analista solicitante está conectada es un control que falla a las 6 de la mañana - exactamente cuando corre el trabajo programado. Las preguntas se enrutan a quien tiene autoridad para responderlas, entre sesiones, y esperan. Segundo, la respuesta pasa a formar parte del registro: a quién se preguntó, qué vio exactamente, qué decidió y cuándo. Una aprobación no es un clic que se evapora; es un evento con el mismo rango que la consulta que desbloqueó.

Así se ve en la práctica. Una analista pide al agente enviar un paquete de exposición terminado a una dirección externa. Enviar fuera del espacio de trabajo es preguntar-primero en su organización, así que la ejecución se pausa y la pregunta se enruta al propietario del espacio: el archivo, el destino, el permiso que exige aprobación. El propietario aprueba solo este envío; la ejecución continúa; el registro contiene ahora el paquete, la aprobación y la identidad de todos los implicados. Fricción añadida total: una decisión, tomada por la persona correcta, una vez.

Esta es la resolución práctica del debate del humano en el bucle. Un humano en cada acción produce fatiga de clics y, en una semana, un sello de goma - un control que solo existe en capturas de pantalla. Un humano en ninguna acción es la frase con la que abre este artículo. Un humano exactamente en los bordes definidos por la política, con la pregunta enrutada a la autoridad correcta y registrada - eso se sostiene, en la operación y ante un auditor.

Las denegaciones son registros, no callejones sin salida

La mayoría de los sistemas trata una acción rechazada como un error que suprimir. Nosotros la tratamos como algunos de los datos más valiosos que produce la plataforma.

Cuando una sesión intenta algo fuera de sus permisos - una fuente al otro lado de una barrera de información, una escritura que nunca se le dio, un flujo que no puede ejecutar -, el rechazo aterriza en el registro de auditoría con la regla que se activó, junto a cada acceso exitoso. Eso es lo que su equipo de seguridad revisa de verdad: no el camino feliz, sino el espacio negativo a su alrededor. Quién chocó con qué límite, con qué frecuencia, y si el límite aguantó. Un trimestre de denegaciones es la evidencia de que sus barreras funcionan - o el aviso temprano de que alguien insiste en tantear una.

También cambia la conversación con la persona rechazada. Una denegación con su regla ("bloqueado por la barrera research/trading, fijada a nivel de organización") es algo que puede llevar a un administrador y discutir. Un fallo genérico enseña a la gente a rodear el sistema; uno legible le enseña cómo funciona.

Qué ven realmente los administradores

Los controles que no se pueden inspeccionar hay que creerlos por fe, así que la vista administrativa es deliberadamente aburrida: un inventario. Qué herramientas existen a nivel de organización; qué espacios llevan qué subconjunto; qué personas sostienen qué permisos encima; qué acciones son preguntar-primero; y el flujo de preguntas, aprobaciones y denegaciones que el sistema en marcha ha producido. Cuando llegue su revisión de accesos, la respuesta a "como quién puede actuar el agente, y qué puede hacer por ellos" es una página que se lee, no una investigación que se encarga.

El mismo inventario responde la pregunta de diligencia que más oímos de los equipos de seguridad que evalúan nuestra arquitectura: "¿cuál es el radio de impacto si una sesión se ve comprometida o simplemente se equivoca?" La respuesta honesta: los permisos de una persona, en un espacio de trabajo, menos cada denegación, con los bordes sensibles protegidos por preguntas que se enrutan a otra persona. Ese es un perímetro sobre el que se puede razonar - y, sobre todo, uno que dibujó usted, no nosotros.

La prueba para cualquier evaluación

Si está evaluando plataformas de agentes, el modelo de permisos es donde el marketing y la arquitectura divergen más rápido, y hay una lista corta de preguntas que expone la diferencia. Pida ver la revocación surtiendo efecto - no en un documento de política, en una sesión en marcha. Pregunte qué puede hacer un trabajo programado después de que se reduzca el acceso de su propietario. Pida al proveedor que le muestre una denegación en su registro de auditoría, con la regla que la produjo. Y pregunte qué ocurre, en concreto, cuando el agente quiere hacer algo sensato que nadie preautorizó - si adivina, falla o pregunta a alguien con autoridad para responder.

Nuestras respuestas están en la página de seguridad, formuladas como garantías que puede probar durante un piloto. Si prefiere ver el comportamiento de preguntar en vivo - el agente deteniéndose, la pregunta enrutándose, el registro formándose -, reserve una demo y activaremos el límite a propósito.