Cada acción del agente con efecto sobre el mundo queda sellada en una cadena de auditoría dentro de tu propia instalación, que verificas cuando quieras. No te pedimos confianza: te damos el procedimiento para desmentirnos — cuatro pruebas que puedes ejecutar en tu equipo durante los 30 días de prueba.
Tres piezas, y no hay una cuarta. Una: el agente, en el equipo del usuario, con su base de datos local — ahí viven su historial de trabajo y su cadena de auditoría. Es el que abre tus ficheros, ejecuta comandos en tu shell y habla con tus conectores; todo eso ocurre dentro de tu máquina. Dos: un panel web que dirige — cuenta, suscripción, estado compartido del equipo — pero que no ejecuta nada ni recibe tus ficheros. Tres: tu clave de IA, cifrada en tu propio equipo, hablando directamente con el proveedor que tú elijas. Esa llamada al proveedor es la única salida a la red del trabajo del agente; con un modelo local, no hay ninguna.
Esa arquitectura es la misma en todas las páginas de este sitio, y es comprobable sin hablar con nosotros: corta la red, o pon un proxy delante y lee lo que sale. Los cuatro procedimientos →
El agente registra cada acción con efecto sobre el mundo — llamada a una
herramienta, aprobación concedida, escritura en disco — como un AuditEvent
con correlation_id
y su hash encadenado al de la anterior. Cualquier modificación retroactiva rompe la cadena y la verificación la señala.
El sellado usa HMAC-SHA256 con una clave que vive fuera de la base de datos, precisamente para que quien pueda escribir en ella no pueda recalcular la cadena para cuadrarla. Es tamper-evident: no impide que alguien reescriba el pasado, hace que se note. Puedes provocarlo tú y comprobarlo — prueba 04.
| seq | kind | correlation_id | prev_hash | hash |
|---|---|---|---|---|
| 0001 | agent.tool_call | corr_8f3a2c91 | 0000000000000000… | a4d8c7e2f1b9e6d3… |
| 0002 | approval.granted | corr_8f3a2c91 | a4d8c7e2f1b9e6d3… | b7e1f4a9c2d8e5b6… |
| 0003 | tool.exec.success | corr_8f3a2c91 | b7e1f4a9c2d8e5b6… | c9f2a8d1e4b7c3a5… |
| 0004 | memory.promoted | corr_8f3a2c91 | c9f2a8d1e4b7c3a5… | d1e5b8a3f6c9e2d7… |
WHERE que
alguien pueda olvidar.
GET /api/audit/verify
contra tu propio agente.
Descargar un fichero de internet es una sola acción. Según quién pregunte, la respuesta que hace falta es distinta — y las cuatro salen del mismo registro.
«Le pedí unas canciones para mi hija. Aparecieron. ¿De dónde salieron?»
Un agente que resuelve la tarea y no sabe explicarse deja al usuario respondiendo por algo que no eligió. Si la descarga vino de donde no tocaba, quien da la cara es él.
resource «¿Por dónde ha salido de mi red, y con qué permiso?»
La mayoría de los agentes registran lo que responden, no lo que hacen. Una descarga o un comando no dejan un rastro comparable al de una persona haciendo lo mismo.
governance_level «Dentro de seis meses, ¿puedo demostrar qué pasó ese día?»
Un registro que se puede editar después no sirve como prueba, y uno disperso en cinco sistemas obliga a reconstruir la historia a mano.
entry_hash «¿Qué ejecutó exactamente, en qué orden y cuánto tardó?»
Sin un identificador que hile los pasos, cada acción es un hecho suelto. Saber QUÉ se hizo no basta: hace falta saber a qué petición pertenecía.
correlation_id
El campo resource se rellena con lo primero que identifique
el recurso tocado: la dirección si hubo red, la ruta si hubo fichero, el
comando si hubo terminal. Y la política decide antes de ejecutar:
lo permitido deja acta, lo denegado también, con su motivo.
Una garantía sin sus límites no es una garantía. Estas tres ausencias son decisiones, no olvidos.
El contenido de lo descargado
Se registra la identidad del recurso, no el recurso. La regla está escrita en el propio código: identidad recortada, nunca contenido.
Los valores de los argumentos
Sólo sus nombres (arg_keys), para que una clave o un
token no acaben dentro de un registro que existe para durar.
Direcciones muy largas
La dirección se recorta a 200 caracteres: se conserva el origen y la ruta, no una consulta kilométrica.
iForja se diseña desde la arquitectura para sectores regulados. Lo que sigue no es una lista de certificaciones: iForja no está certificado en ninguno de estos marcos. Es la evidencia que el agente produce hoy y que tu equipo de cumplimiento puede llevar a una auditoría real. La certificación la emite un organismo acreditado sobre tu instalación; el software te da con qué sostenerla.
| Marco | Cumplimiento institucional | Evidencia |
|---|---|---|
| GDPR / RGPD Conforme · DPA opcional | El cliente es Data Controller. iForja proveedor de software on-prem · sin acceso a datos del cliente. DPA disponible para contratos con soporte. Derechos ARSCO ejercitables sobre la instalación del cliente. | en preparación |
| ISO 27001:2022 93 controles · autoevaluación | Catálogo embebido en el propio agente: los 93 controles del Anexo A con la evidencia que los sostiene, revalidados de forma periódica. Es una AUTOEVALUACIÓN, no una certificación: iForja no está certificado en ISO 27001 y no lo afirmamos en ninguna parte. | en preparación |
| EU AI Act (Reg. 2024/1689) Art. 18-19 cumplidos | Documentación técnica del sistema · sistema de gestión de calidad (QMS) · logs automáticos vía audit chain. Posicionamiento como GPAI provider con safeguards institucionales. | en preparación |
| NIS2 (Dir. 2022/2555) Aplicable · trazable | Entidades esenciales e importantes: instalar en tus propios equipos hace trazable la cadena de suministro, la gestión de incidentes se apoya en una cadena de auditoría sellada y el estado de fortificación es reportable al CSIRT nacional. | en preparación |
| DORA (Reg. 2022/2554) FinServ ready | ICT risk management · incident reporting · third-party oversight: audit chain SHA-256 satisface la trazabilidad regulatoria exigida a entidades financieras europeas. | en preparación |
| ENS (RD 311/2022 · España) Categoría ALTA viable | Esquema Nacional de Seguridad. Que el dato no salga de tu hardware, la cadena de auditoría sellada, el aislamiento por fichero entre tenants y las comprobaciones de fortificación cubren buena parte de los controles operacionales del Anexo II. La declaración de conformidad la emite un organismo de evaluación sobre tu despliegue. | en preparación |
Dicho de la forma más directa posible, porque es donde más se miente en este sector: los 93 controles del Anexo A de la ISO 27001:2022 están catalogados con evidencia trazable en autoevaluación. Eso no es una certificación y no vamos a llamarlo así. La certificación ISO 27001, o la conformidad ENS, las emite un organismo acreditado sobre tu despliegue concreto.
La gobernanza del producto es pública en lo que importa a quien lo compra: cada decisión arquitectónica está firmada, cada cierre de fase tiene métricas verificables, cada bug corregido deja causa raíz y test de regresión. Quien esté evaluando iForja puede pedir el detalle bajo acuerdo de confidencialidad — no hace falta ser cliente, y a fecha de hoy no hay ninguno en producción.
Si encuentras una vulnerabilidad en iForja, te pedimos que nos contactes en privado antes de publicarla. Trabajamos bajo una política de divulgación coordinada con ventana de 90 días desde el primer contacto hasta la publicación.
security@iforja.com
se publica junto al primer aviso de seguridad. Si necesitas la clave
antes, escríbenos.
La documentación técnica del producto vive en /docs ·
el detalle del audit chain, en /use-cases/audit.
Para contratos con DPA, demo guiada de seguridad o cuestionario de
proveedor, escríbenos directamente.