Registro de auditoría

Un registro de solo anexado y a prueba de manipulaciones de cada acción que cambia el estado en tu espacio, con comparaciones campo por campo del antes y el después, y las direcciones IP nunca expuestas.

El registro de auditoría responde a una sola pregunta sobre tu espacio: quién hizo qué, cuándo y sobre qué. Cada acción que cambia el estado, crear un agente, cambiar el rol de un miembro, conectar una integración, eliminar conocimiento, escribe una entrada inmutable. AnyBot reconoce 559 acciones auditadas en toda la plataforma, así que la cobertura es toda la superficie, no una selección de momentos destacados.

Anatomía de una entrada

Cada fila registra la misma estructura, así que cualquier acción se lee de la misma forma:

Campo	Qué captura
Actor	El miembro que la realizó, o el agente / sistema para los eventos automatizados y activados por callback
Marca de tiempo	Cuándo ocurrió
Alcance	El espacio, y el agente concreto cuando la acción tiene alcance de agente
Acción	Un `namespace.verb` canónico (p. ej. `space.member_updated`) más una etiqueta en lenguaje sencillo
Entidad	Lo que se modificó, un agente, un miembro, una integración, un lead, un archivo
Cambio	Una comparación antes / después a nivel de campo, solo los nombres de los campos y valores seguros
Sensibilidad	`high` · `med` · `low`, para que puedas filtrar por las acciones que importan
Resultado	`success` · `failed` · `denied` · `neutral`
Cliente	Un resumen aproximado de navegador / SO / dispositivo, visible solo para owner y admin

Qué cubre

Las acciones se agrupan en dominios por los que puedes filtrar: agentes, conocimiento, integraciones y canales, bandeja de entrada y conversaciones, CRM y leads, social, productos, reuniones, telefonía, calendario, landing pages y gobernanza (miembros, roles, espacios, facturación, seguridad, exportaciones). Si una operación cambia el estado, crear, actualizar, eliminar, conceder, revocar, conectar, publicar, iniciar sesión, cambiar una contraseña, está diseñada para dejar un rastro. Esa cobertura se impone en el código: una nueva acción que cambia el estado y se publica sin una escritura en el registro no pasa un control interno.

Cómo se relacionan las piezas

Cada acción pertenece a una entidad, y cada entidad a un dominio. La sensibilidad y el resultado se derivan de la acción misma, no se almacenan de forma suelta, así que el mismo clasificador impulsa las etiquetas, los niveles con colores y los filtros. Por eso, filtrar por «sensibilidad alta, resultado denegado, gobernanza» devuelve exactamente los eventos relevantes para la seguridad y nada más.

Evidencia de manipulación

El registro es más que de solo anexado. Cada nueva entrada se sella en una cadena de hash: su hash es sha256(entry-contents | previous entry's hash). Como cada entrada incorpora la anterior, modificar o eliminar cualquier fila histórica cambia su hash y rompe todos los hash posteriores, algo que un control de integridad detecta y localiza con precisión. El sellado es fail-open: nunca puede bloquear ni ralentizar la acción que se está registrando, y las entradas escritas antes del lanzamiento de la función de cadena se reportan honestamente como pre-cadena en lugar de darse por buenas en silencio.

Privacidad: qué se oculta

El registro de auditoría está construido para ser seguro de leer:

Las direcciones IP nunca se exponen a través de la API del registro, por diseño, ni siquiera a owner y admin. Se capturan para el registro, no se muestran.
Los user agents se reducen a una etiqueta aproximada de navegador / SO / dispositivo. Sin huella digital.
Los secretos y la PII nunca entran en una entrada. Un cambio de contraseña, un token, una credencial de API o un registro de consentimiento se registra por nombre de campo y una comparación segura, nunca el valor.

Ejemplo práctico

Un compañero de equipo promueve a otro miembro de member a admin. Se escribe una entrada:

Acción, space.member_updated · etiqueta «Cambió el rol/los permisos de un miembro»
Sensibilidad, high · Resultado, success
Actor, el miembro que promueve · Entidad, el miembro promovido
Cambio, role: member → admin
Marca de tiempo + cliente aproximado (vista de owner/admin)

Más tarde, un operador abre ese registro desde la consola de administración. Como es de alta sensibilidad, el propio acto de verlo se audita (audit_log.viewed), el registro audita a sus propios auditores. (Esta autoauditoría se dispara en el panel de operador/admin, no en la vista del registro dentro del espacio.)

Quién puede leerlo

La lectura del registro de auditoría está regulada por el permiso view_audit_log. Los owner y los admin siempre lo tienen; a los member y a los viewer se les puede conceder individualmente a través de la matriz de permisos, un patrón común para un revisor de cumplimiento que necesita la traza pero ningún otro poder de administración.

Preguntas frecuentes

¿Se puede editar o eliminar una entrada? No. El registro es de solo anexado, y la cadena de hash hace detectable cualquier cambio posterior.

¿Por qué no puedo ver quién hizo algo de antes de que nos uniéramos? Las entradas anteriores a la cadena actual se marcan como pre-cadena; la garantía a prueba de manipulaciones empieza en la primera entrada sellada después de que se desplegó la función.

¿El agente aparece como actor? Sí, los eventos automatizados y activados por callback se atribuyen al agente/sistema en lugar de a una persona, así que los cambios impulsados por el agente nunca se confunden con los de un humano.