Qué se ejecuta, dónde se ejecuta y a qué puede llegar

La versión corta: un conjunto pequeño de contenedores y un volumen. Se ejecuta en tu propio hardware, no necesita salida a internet, lee la estructura de tus sistemas y no su contenido, y cada acceso se acota a un tenant y a un rol antes de llegar a nada.

Contenedores y un volumen

EVIDENT es un contenedor de aplicación, uno web y un proveedor de identidad, con un único volumen con nombre que guarda la base de datos interna y las credenciales cifradas. No hay base de datos externa que aprovisionar, ni broker de mensajes, ni almacén de objetos, ni servicio gestionado por medio.

Funciona en un portátil, en una máquina virtual o en tu orquestador. Levantarlo es un solo comando, y es el mismo en todos los entornos, que es la propiedad que importa cuando alguien tiene que reproducir un incidente en una máquina que no es aquella en la que ocurrió.

Desplegado en tu hardware, no sale nada de ahí. La licencia es un código firmado que se verifica sin conexión contra una clave pública, así que una instalación en una red sin salida funciona exactamente igual que una que la tiene.

Estructura, no filas

El análisis principal lee esquemas, restricciones, claves ajenas, tipos y comentarios, y el código fuente que se corresponde con ellos. Por defecto no lee los registros de tus tablas, y ese valor por defecto es una propiedad de cómo está construido, no un ajuste que alguien se acordó de no tocar. El perfilado y el muestreo son los dos modos que sí leen datos, y el párrafo de abajo dice lo que cuestan.

El perfilado y el muestreo existen para los casos que los necesitan. Los dos están apagados, los dos se activan por proyecto, y los dos se declaran en el informe cuando se han usado. El modo por defecto es el más restrictivo.

Las conexiones se hacen con credenciales de solo lectura y mínimo privilegio, y allí donde el driver puede imponerla, la solo lectura se impone en lugar de confiarse. Las credenciales se cifran en reposo, quedan atadas a la conexión a la que pertenecen y nunca se escriben en un log.

El código se lee, no se lleva

EVIDENT no se queda con una copia de tu código. Lo lee para responder a tres preguntas que un esquema no puede contestar: qué entidad del código se corresponde con qué columna, qué se hace realmente con esos datos y qué acaba escribiéndose en los logs. Lo que guarda es la conclusión y la referencia —el fichero, el símbolo, la línea—, no el fichero.

Dónde se lee depende de dónde corre la plataforma, y las dos respuestas son distintas. En tu infraestructura, el código se lee dentro de ella y no sale: no tiene adónde ir. Alojado por nosotros, el repositorio tiene que llegar a la máquina donde corre el análisis, y lo que sobrevive a ese análisis es lo mismo en los dos casos: la conclusión y la referencia, no el fichero. Una página que te prometiera la primera frase sin decir de qué despliegue habla estaría prometiendo algo que no puede cumplir, así que esta lo dice dos veces.

En el despliegue alojado la copia se elimina al terminar el análisis, termine como termine, y nunca está en una copia de seguridad. Eso es una afirmación sobre un fallo tanto como sobre un éxito, así que está construida como tal: la copia tiene un lease, se renueva mientras el análisis la lee, y lo que deja atrás un proceso muerto o un reinicio se reclama, pero solo cuando la ejecución que la tomó ha parado de verdad, nunca porque el directorio se haya hecho viejo. Una limpieza que falla deja el lease abierto, así que se reintenta y se ve en lugar de darse por hecha. Nueve caminos, incluidos los dos que importan, están cubiertos por pruebas.

Y una valoración sin evidencia no se permite. A toda afirmación material se le puede preguntar por qué y dónde, y la respuesta distingue lo que se infirió de lo que se observó, lo que corroboró una segunda fuente de lo que se apoya en una sola, lo que confirmó una persona de lo que decidió la plataforma, y lo que alguien declaró sobre su propia organización de lo que no se pudo corroborar en absoluto.

Lo mismo vale a lo largo del tiempo. Cada afirmación lleva qué cambió entre una evaluación y la siguiente, así que a medida que tus sistemas evolucionan puedes distinguir lo que se corrigió de verdad de lo que sigue igual porque nada suyo ha cambiado, y ninguna de las dos cosas es una suposición que nadie tenga que creerse.

Quién llega a qué: primero el tenant, después el rol

Cada proyecto pertenece a un tenant, y cada petición se responde dentro de uno. Eso vale también en una instalación on-premise de un solo tenant: es el mismo camino de código, así que el aislamiento del que dependes en un despliegue alojado es el que has probado en el tuyo.

Dentro de un tenant, el acceso es por roles y se comprueba a todos los niveles: el proyecto, la acción, el registro. Una identidad confinada a un proyecto es rechazada en todo lo relativo a otro antes de mirar sus permisos, porque una identidad que no puede tocar un proyecto no puede tocarlo por muchos permisos que tenga.

Quién ve qué proyecto lo defines tú. La plataforma te obliga a asignar roles y permisos, pero no los decide por ti.

Identidad con Keycloak

La autenticación y el modelo de roles viven en Keycloak, el servidor de gestión de identidades y accesos de código abierto mantenido bajo la CNCF. Corre como uno de los contenedores, y es el mismo Keycloak que quizá ya usen tus otros sistemas: no es un fork ni una copia con parches nuestros.

Lo que ese componente te da, en la versión con la que se distribuye: OpenID Connect y SAML 2.0, organizaciones para realms multi-tenant, permisos administrativos de grano fino, passkeys y WebAuthn, autenticación escalonada, sesiones persistentes que sobreviven a un reinicio, tokens ligados con DPoP, intercambio de tokens, políticas de cliente y federación contra LDAP, Active Directory y proveedores de identidad sociales.

Lo que Keycloak puede hacer y lo que EVIDENT declara como integración soportada son dos listas distintas, y la diferencia importa más que lo que comparten. OIDC está Disponible porque es sobre lo que corre el producto: la plataforma desplegada autentica así cada petición. SAML y SCIM están Planificados: el proveedor de identidad de debajo habla SAML, EVIDENT nunca ha validado una integración SAML de extremo a extremo, y una casilla que contara lo primero como lo segundo sería justo el tipo de afirmación contra la que existe este producto.

Como la identidad es un componente y no algo que hayamos escrito nosotros, tu inicio de sesión único, tu política de contraseñas, tu segundo factor y tu proceso de altas y bajas se aplican a EVIDENT sin que nadie escriba una integración.

Agentes y máquinas: JWT, acotado y de vida corta

Un agente de IA que se conecta por MCP, o un sistema que llama a la API, se autentica con un JWT emitido por el mismo proveedor de identidad que todo el mundo. No hay una segunda puerta más débil.

Un administrador define qué puede hacer cada uno, individualmente: qué permisos, sobre qué proyectos y durante cuánto tiempo. Las sesiones tienen tiempo limitado y se refrescan en vez de ser eternas, así que un token que se filtra deja de funcionar solo.

Un agente aparece marcado como tal en todas partes —en la traza de auditoría, en el registro de quién cambió qué— y nunca se confunde con una persona.

Todo queda registrado, y nada sensible

Cada petición, cada acción, cada análisis, cada decisión de revisión y cada cambio administrativo queda registrado, correlacionado por un identificador de petición que sigue al trabajo entre componentes.

El registro sigue OpenTelemetry, así que va al colector, a los cuadros de mando y a las alertas que ya tienes, en lugar de a un formato propio que solo este producto sepa leer. Eso es lo que lo hace observable, auditable y monitorizable por el equipo que ya hace eso.

Los secretos y los valores sensibles no se escriben ahí. Una contraseña de conexión entregada a la plataforma se cifra y no aparece en ninguna línea de log, y el registro de auditoría describe qué se tocó, no qué había dentro.

Lo que recibe tu equipo de operaciones

Runbooks para desplegar, actualizar, respaldar y restaurar; endpoints de salud y disponibilidad; migraciones de base de datos de solo avance que se ejecutan al arrancar y dicen qué hicieron; un entorno documentado para cada ajuste, con los relevantes para la seguridad por defecto en la posición cerrada.

Un equipo que haya hecho esto antes debería poder levantarlo y configurarlo en una tarde. Preferimos que lo haga, y le acompañamos mientras lo hace.