Seus logs explicam o que aconteceu. O ImmutableLog prova.
Veja o que acontece nos seus eventos críticos, detecte o que importa, reconstrua quem fez o quê, e prove criptograficamente quando um auditor, um regulador ou um tribunal perguntar.
Observabilidade explica. Auditabilidade prova.
Observabilidade explica.
Auditabilidade prova.
ImmutableLog é a camada de infraestrutura que torna a adulteração de eventos do sistema detectável, e os eventos verificáveis de forma independente.
Três momentos em que a prova muda tudo
A Auditoria Surpresa
Um auditor externo pede prova de quem acessou dados de clientes nos últimos 12 meses. Os registros existem. Mas ninguém consegue provar que nunca foram alterados.
“Logs descrevem eventos. Eles não provam.”
O Incidente de Segurança
Uma invasão é descoberta. O atacante teve acesso admin por semanas. A investigação precisa saber o que aconteceu, e se os logs foram alterados.
“Sem evidência de adulteração, sua linha do tempo é apenas uma hipótese.”
A Disputa Jurídica
Um cliente afirma que seus dados foram acessados sem autorização. Seus logs dizem o contrário. Os advogados perguntam como verificar esses registros.
“Logs podem ser questionados. Prova criptográfica não.”
Três forças tornando operações prováveis não opcionais
Confiança costumava ser presumida. Hoje ela precisa ser demonstrada para reguladores, clientes, tribunais e, cada vez mais, para órgãos de supervisão de IA.
Governança de IA está virando lei
EU AI Act, NIST AI RMF, ISO 42001 e marcos nacionais emergentes compartilham uma mesma exigência: produzir registros verificáveis de decisões automatizadas e dos dados que as motivaram.
Compliance hoje exige prova, não afirmação
SOC 2, ISO 27001, LGPD e frameworks setoriais saíram de "documente seus controles" para "prove que foram aplicados." Logs auto-reportados deixaram de ser evidência suficiente.
Risco interno e fraude estão mais sofisticados
Usuários privilegiados com capacidade de alterar a própria trilha de auditoria continuam sendo a ameaça de maior impacto. Registros independentes, com adulteração detectável, são a única defesa que se sustenta em tribunal ou arbitragem.
Por que logs tradicionais falham quando a prova importa
Logs explicam. Eles não provam.
Logs tradicionais são gerados, armazenados e controlados pelos mesmos sistemas que operam o produto. Podem ser alterados, truncados ou perdidos. Quando prova é exigida, confiar na própria infraestrutura não basta.
- Alteração maliciosa: usuários privilegiados podem modificar ou remover registros.
- Imutabilidade por política: WORM, retention lock e regras de IAM são configuração, e quem tem admin desliga.
- Erro humano: políticas de retenção ou falhas podem apagar o histórico.
- Risco em auditoria: logs não verificáveis enfraquecem a evidência.
Padrões recorrentes em que logs tradicionais falharam sob pressão
Cada um destes é um padrão observado publicamente em incidentes corporativos. Nenhum exigiu um atacante sofisticado: apenas um sistema em que as mesmas pessoas que geram os logs também podem alterá-los.
O funcionário privilegiado com meses de acesso não monitorado
Um colaborador com credenciais de admin acessa milhões de registros ao longo de um período extenso. A atividade é tecnicamente logada, mas o mesmo papel consegue editar, rotacionar ou reconstruir esses logs. Quando os investigadores chegam, a trilha já está parcialmente perdida.
Com registros imutáveis independentes, o padrão de acesso é preservado além do alcance do usuário investigado.
O time de compliance com 48 horas e cinco sistemas desconexos
Um auditor solicita um ano de eventos de acesso a um ativo crítico. Logs foram rotacionados, parcialmente expurgados e divididos entre infraestruturas gerenciadas por times diferentes. A reconstrução leva semanas e produz respostas parciais, que reguladores interpretam de forma desfavorável.
Com uma cadeia de evidência contínua, respostas de auditoria viram operações de exportação, não projetos forenses.
A transferência de alto valor questionada anos depois
Um cliente contesta uma transação ou mudança de configuração executada há muito tempo. Os logs da aplicação estão intactos, mas vivem nos mesmos sistemas que o cliente está questionando. Não existe um registro que ele considere neutro.
Prova criptográfica de inclusão se sustenta como evidência verificável por terceiros em arbitragem, revisão regulatória ou tribunal.
Estes não são casos de borda. São os momentos em que a ausência de evidência criptográfica fica cara.
O que é o ImmutableLog
ImmutableLog é um ledger privado e permissionado para eventos críticos do sistema. Cada evento é hasheado, encadeado e armazenado em uma estrutura append-only que torna o histórico criptograficamente verificável.
Ledger privado: eventos permanecem no seu ambiente. Sem blockchain pública.
Imutabilidade append-only: eventos não podem ser editados nem apagados.
Prova criptográfica: cada evento pode ser verificado via hashing determinístico.
Verificação independente: qualquer parte recomputa a prova de inclusão, e o consenso PoA multi-validador impede que um operador sozinho reescreva o histórico.
O que o ImmutableLog não é
"O ImmutableLog não é uma blockchain pública. Não usa criptomoeda nem tokens. Não substitui sua stack de observabilidade: acrescenta a camada que ela nunca foi feita para entregar. É infraestrutura de prova: tornar o histórico de eventos verificável e auditável."
Use os dois. Eles resolvem problemas diferentes.
O ImmutableLog não substitui sua stack de observabilidade. Ele adiciona a camada que ela nunca foi feita para entregar: prova criptográfica.
Datadog · New Relic · Grafana · Splunk · CloudWatch
Feito para operar
- Monitoramento, traces e métricas em tempo real
- Agregação e busca full-text de logs
- Dashboards de performance e alertas
- Lido por SRE, DevOps e Engenharia
- Logs podem ser rotacionados, editados ou apagados
“O que está acontecendo agora?”
Feito para provar
- Ledger append-only, com adulteração detectável
- Prova criptográfica de inclusão por evento
- Verificável de forma independente por terceiros
- Lido por auditores, reguladores e jurídico
- Registros não podem ser editados nem apagados, nunca
“O que de fato aconteceu, e você consegue provar?”
Sua stack de observabilidade conta a história operacional. O ImmutableLog assina e sela as partes que precisam se sustentar em auditoria, disputa ou investigação.
Imutável por configuração não é imutável.
Retention lock, WORM e política de IAM são configuração, desligada por quem tem admin. A pergunta não é "está travado?", é "travado contra quem?".
Imutável por configuração
- WORM, retention lock, política de IAM
- Revertido por quem controla a config (admin ou fornecedor)
- Sem resposta para "isto foi alterado?"
- Confiança circular: a plataforma valida a si mesma
Imutável por criptografia
- Hash-chain + prova de inclusão Merkle por evento
- Qualquer alteração quebra a cadeia, matematicamente detectável
- Independe de política: não há nada a "desligar"
- Consenso PoA multi-validador entre partes independentes
As três perguntas que um lock de configuração não responde
Imutável pra quem?
Um lock que o admin reverte não protege contra o insider com credencial: o atacante que apaga o próprio rastro primeiro.
Prova depois do fato?
Se um registro foi alterado, você detecta qual e prova? Hash-chain prova. Configuração só tenta prevenir.
Quem é a âncora de confiança?
Não a própria plataforma. O consenso multi-validador distribui a confiança, de forma que nenhum nó sozinho reescreve a história.
O ImmutableLog não previne alteração por política. Ele a torna matematicamente detectável e verificável por terceiros.
Do Evento à Evidência Verificável
Cada evento crítico atravessa sete estágios antes de virar prova. Nenhum deles é opcional: é o que separa um log de uma trilha auditável.
POST: Recepção via API
Sua aplicação envia o evento crítico (ação de usuário, mudança de configuração, transação ou decisão automatizada) por um POST autenticado.
Validação
O evento é validado contra schema e assinatura. Payloads inválidos são rejeitados antes de tocar no ledger.
Distribuição
O evento é replicado entre os nós do cluster. Nenhum nó isolado pode decidir, sozinho, o que entra na cadeia.
Consenso
Os nós concordam sobre a ordem e o conteúdo do evento antes de aceitá-lo. Sem consenso, não há registro.
Encadeamento
Um hash determinístico liga o evento ao bloco anterior, formando uma cadeia em que alterar o passado quebra todo o futuro.
Persistência
O bloco é escrito em armazenamento append-only. Eventos não podem ser editados nem apagados, nem por administradores.
Verificação futura
Auditores, reguladores ou seus próprios sistemas podem provar criptograficamente que o evento ocorreu, meses ou anos depois.
# Step 1: Record critical event
curl -X POST https://api.immutablelog.com/v1/events \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"event_type": "admin_access",
"actor": "admin_01",
"action": "delete_database",
"timestamp": "2026-01-30T14:20:00Z"
}'
# Step 2: Receive proof of inclusion
# response:
# { "block_id": "48291", "hash": "0x4f2b...", "proof": "0x9a2e..." }Não é armazenar logs.
É garantir prova.
Você consegue provar por que a sua IA tomou aquela decisão?
Sistemas autônomos decidem quem é aprovado, sinalizado, atendido ou negado, a cada segundo, em produção. A maioria das empresas não consegue provar o que o modelo viu, o que decidiu, nem se o registro foi alterado depois.
Rastreie cada decisão automatizada
Capture entrada, versão do modelo, saída e contexto de política por trás de cada decisão, selados antes que qualquer outro sistema toque no registro.
Independente do time que construiu o modelo
A evidência fica fora do stack de data science. Engenheiros não podem reescrever a trilha. Revisores não podem perdê-la.
Defensável em revisão regulatória
EU AI Act, NIST AI RMF e ISO 42001 convergem para a mesma exigência: registros prováveis de decisões automatizadas.
Verificável para clientes e auditores
Quando um cliente contesta um resultado automatizado, apresente evidência criptográfica, não logs internos que ele não tem motivo para confiar.
Logs explicam o que sua IA fez. ImmutableLog prova.
Do Evento à Evidência Defensável
Inspecione registros selados, navegue pela cadeia de provas e exporte evidência criptográfica em uma única interface de auditoria.
Acompanhe o uso e filtre o registro de auditoria
Acompanhe sua cota mensal de eventos e filtre o registro de auditoria por data, tipo de evento, intervalo de tempo ou ID de transação para encontrar exatamente o que precisa.
- Progresso da cota mensal
- Filtro por tipo de evento
- Seletor de horário
- Busca por tx ID
Não prova só que o log não mudou. Agora ele enriquece e detecta.
Cada evento selado é normalizado para ECS, geolocalizado pelo IP real do usuário, cruzado com threat intelligence e avaliado por regras de detecção, sem nunca perder a prova de imutabilidade.
IP real do usuário final
meta.client_ip vira source.ip com precedência máxima, então geo, threat e detecção rodam sobre o usuário de verdade, não o proxy.
Geolocalização e threat intel
País, cidade e coordenadas de cada evento, cruzados com feeds de ameaça para destacar IPs de risco.
Alertas por regra
Brute-force, IP novo, hits de threat e mais: detecções por tenant, ligadas de volta ao evento exato.
source.ip é o usuário final, não o proxy
Entre o navegador e o core há proxies e balanceadores. Seu backend encaminha o IP real do navegador em meta.client_ip, e o SIEM grava em source.ip com proveniência client_asserted.
44.192.13.3
proxy AWS179.110.4.205
usuário realO core sela. O SIEM lê e enriquece.
O que já detectamos hoje
Varredura de credencial
Tentativas de login que falham em sequência, vindas do mesmo IP: a assinatura de uma varredura ou de força bruta.
Login seguido de exclusão
O mesmo usuário loga e apaga dados logo em seguida, padrão compatível com conta comprometida.
Novo ponto de acesso
Login vindo de um IP nunca visto antes para aquele cliente, sinalizado já na primeira vez.
Atividade de root e admin
Toda ação autenticada por um usuário root ou admin é acompanhada, porque deveria ser rara e sempre revisada.
IPs de reputação ruim
Tráfego envolvendo um IP sinalizado por feeds de reputação como Spamhaus, saídas Tor ou hosts comprometidos conhecidos.
Respostas não autorizadas
Respostas 401 repetidas vindas do mesmo IP, o padrão de uma varredura de credencial contra a API.
Tentativas de acesso negado
Respostas 403 repetidas para o mesmo usuário, uma conta tentando alcançar o que não pode.
Novo país de origem
Tráfego vindo de um país nunca visto antes para aquele cliente, mudança incomum na origem das requisições.
Picos de erro em produção
Aumento incomum de erros no ambiente de produção do cliente, no mesmo serviço, sinal de um incidente em curso.
O SDK registra o que a sua aplicação faz. O agente registra o que fazem no seu servidor.
Instrumentar o código cobre o que passa pela aplicação. Não cobre quem entrou por SSH às 3h da manhã, nem o comando que rodou como root. O agente roda no seu servidor, captura cada acesso e cada comando, e envia para a mesma chain imutável, sem tocar em uma linha do seu código.
curl -sSL https://get.immutablelog.com/agent \
| IMTBL_API_KEY=iml_live_… sudo --preserve-env=IMTBL_API_KEY shUm binário estático, sem runtime e sem dependência. O instalador verifica o SHA-256 antes de instalar, e a sua chave nunca passa pela linha de comando.
Zero código
Não é biblioteca: é um serviço que roda ao lado da sua aplicação. Funciona igual se o seu servidor é PHP, Java, Node, ou nada disso.
Cobre o ponto cego
Login e logout por SSH, tentativa com usuário inválido e, se você ligar, cada comando executado, com usuário, PID e linha de comando.
O rastro não se apaga
Cada evento é selado na chain no momento em que acontece. Nem quem tem root no host reescreve o que já foi registrado.
Silêncio também é prova
Se o agente for parado ou morto, a janela sem observação vira um evento próprio, selado como qualquer outro. Desligar o agente deixa marca.
Segredo redigido antes de sair
Senhas e tokens em linha de comando são removidos no host, antes do envio. Como o registro é imutável, não existe corrigir depois.
Nada se perde
Fila durável em disco: se a rede cair, os eventos ficam guardados e são entregues depois, sem duplicar, mesmo se o servidor reiniciar no meio.
O incidente raramente passa pela sua API.
Acesso indevido a servidor não gera requisição HTTP. Quando alguém, invasor ou funcionário com credencial válida, entra na máquina, a instrumentação da aplicação não vê nada. É exatamente aí que o agente registra.
- Requisições da aplicação
- Eventos de negócio
- Decisões automatizadas
- Login e logout no servidor
- Tentativa de acesso recusada
- Comando executado como root
- Períodos sem observação
O caminho de cada acesso
Os eventos do agente chegam ao SIEM já normalizados: um login vira categoria de autenticação e alimenta as regras de detecção (brute force, IP novo, threat intel) sem configuração extra.
Onde a Prova Substitui a Confiança
Toda organização tem momentos de exposição. São nesses momentos que evidência criptográfica muda o desfecho.
Prove Quem Alterou o Quê e Quando
Um administrador reconfigura um sistema crítico. Semanas depois, um cliente contesta a alteração. Seus logs dizem uma coisa; os registros dele dizem outra.
O ImmutableLog registra cada alteração com timestamp criptográfico e prova de inclusão inalterável. Apresente em qualquer auditoria, disputa ou revisão.
Proteja Transações de Alto Valor de Contestações
Uma transação contestada escala. Foi autorizada? Por quem? Em que momento exato? Seus logs de pagamento foram rotacionados três semanas atrás.
Cada transação entra no ledger imutável com um hash verificável. O registro se sustenta em arbitragem, revisão regulatória ou disputa contratual.
Esteja Pronto para Auditoria Sem Correria
O auditor chega com 48 horas de antecedência. Sua equipe passa dias reconstruindo cronologias em cinco sistemas. A correria revela lacunas que ninguém havia mapeado.
O ImmutableLog mantém uma cadeia contínua e verificável de eventos críticos. Quando o auditor perguntar, você exporta. Não reconstrói.
Investigue Incidentes Sem Depender de Logs Internos
Um incidente de acesso ocorre. Jurídico e RH precisam saber exatamente quem acessou o quê, mas os logs da aplicação são controlados pela mesma equipe sob investigação.
O ImmutableLog opera de forma independente da sua camada de aplicação. Seus registros não podem ser modificados pelas pessoas investigadas.
Responsabilize Quem Tem Acesso Privilegiado
DBAs, sysadmins e engenheiros de suporte têm acesso elevado, com a capacidade de apagar rastros. Como você prova o que eles realmente fizeram?
Cada ação privilegiada é registrada de forma imutável antes de atingir seus sistemas. Independente do administrador. Independente do banco de dados. Verificável por qualquer auditor.
Satisfaça Reguladores Sem Depender das Suas Próprias Afirmações
LGPD, SOC 2, ISO 27001 e reguladores setoriais exigem que você prove, não apenas afirme, que controles foram aplicados. Logs autorreportados não são suficientes.
O ImmutableLog produz registros independentemente verificáveis. Um regulador não precisa confiar em você. A prova criptográfica fala por si mesma.
Resolva Disputas Contratuais Sem Ir a Tribunal
Um cliente afirma que sua plataforma estava fora do ar em um dia específico. Seu dashboard diz o contrário. Sem evidência verificável por terceiros, você está em uma guerra de credibilidade.
A cadeia de eventos do ImmutableLog pode ser apresentada como evidência verificável do comportamento do sistema. Não sua palavra. Prova com timestamp criptográfico.
Rastreie Cada Decisão Automatizada no Seu Pipeline
Seus sistemas de CI/CD, pipelines de dados ou sistemas autônomos tomam decisões em escala. Quando algo falha ou é questionado, como você prova o que aconteceu?
O ImmutableLog captura cada decisão automatizada como um evento imutável. A cadeia de causalidade é preservada e verificável, mesmo meses depois.
A auditoria não avisa quando vai chegar. Sua camada de evidência precisa estar pronta.
Setores Que Exigem Prova
ImmutableLog foi criado para organizações onde evidência verificável é obrigatória.
Fintechs & Instituições Financeiras
Fintechs de pagamento, crédito, banco digital e operadoras reguladas pelo BACEN. A Resolução 4.893 exige registros imutáveis de operações críticas e logs de acesso.
Saúde Mental & Healthtech Digital
Plataformas de telepsicologia, telepsiquiatria e saúde digital que lidam com prontuários sensíveis. A CFM 1.821 exige documentação clínica imutável.
Cartórios & Serventias Extrajudiciais
Cartórios de notas, registros e serventias extrajudiciais regulados pelo CNJ. O Provimento 213/2025 determina trilhas de auditoria digital obrigatórias.
Legaltech & Escritórios de Direito Digital
Plataformas de gestão jurídica, câmaras de arbitragem e escritórios de direito digital. Integridade de processos e rastreabilidade de decisões são exigidas em disputas legais.
Setor Público & Governo
Órgãos federais, estaduais e municipais sujeitos à Lei de Acesso à Informação e auditorias do TCU. Registros imutáveis são essenciais para transparência e prestação de contas.
Seguradoras & Insurtech
Seguradoras, insurtechs e operadoras de planos de saúde reguladas pela SUSEP e ANS. Registros imutáveis de sinistros, alterações de apólice e investigações de fraude são essenciais para compliance regulatório e disputas jurídicas.
Seu setor exige histórico de auditoria comprovável?
Construído para Ambientes Onde Prova é Obrigatória
ImmutableLog foi projetado para ambientes onde reguladores, auditores e clientes corporativos exigem evidência verificável.
Mapeado a controles que auditores conhecem
Medidas de integridade: histórico que não pode ser alterado sem detecção.
Proteção da trilha de auditoria contra modificação não autorizada.
Proteção da informação de log contra adulteração e acesso indevido.
Proteção criptográfica da trilha de auditoria, entregue pelo hash-chain.
Do time ImmutableLog
Artigos sobre auditoria, compliance, criptografia e infraestrutura imutável.
Projetado para Sistemas Que Não Podem Falhar
O core do ImmutableLog é escrito em Rust porque um ledger de auditoria não pode tolerar falhas de memória, latência imprevisível ou corrupção de dados.
Segurança de Memória por Design
Rust elimina classes inteiras de vulnerabilidades de memória ainda em tempo de compilação.
Sem Garbage Collector
Latência previsível sem pausas de GC. Eventos críticos são gravados com consistência.
Correção em Tempo de Compilação
Se compila, a segurança de memória está garantida. A integridade começa na linguagem.
A próxima auditoria vai pedir prova.
Construa sua camada de evidência antes que ela seja exigida. Pilotos entram em produção em menos de 7 dias.
Transforme eventos do sistema em evidência defensável.