O que o KIFF Cloud assina, guarda e assume.

Postura

O KIFF é a solução para o problema do protocolo e da governação, não para todo o problema de modelar um negócio. O negócio do cliente tem de ser expresso em artefactos governados, entidades, eventos, estados, ações, permissões, regras de aprovação, executores, recibos. O KIFF é o núcleo de coordenação que corre sobre essas declarações; o cliente declara o que governar, e o KIFF governa-o.

O KIFF Cloud assume a custódia dos registos de auditoria, dos contadores de utilização e dos dados dos tenants, por conta dos clientes que executam fluxos de trabalho governados de agentes de IA. Os registos de auditoria são apenas de acréscimo dentro da framework e evidenciam adulterações na camada da cloud: os recibos são assinados no momento da escrita com uma carteira que a cloud detém em custódia, e um hash de resumo, que evidencia adulterações, do lote de auditoria de cada tenant é inscrito numa transação de uma cadeia pública, para que esse compromisso possa ser verificado fora da própria base de dados da cloud.

A custódia de chaves de assinatura por tenant, em que cada tenant tem a sua própria chave dedicada, com a qual a cloud assina, e um caminho de migração opcional para entregar a chave ao próprio tenant, está no roteiro abaixo, não está implementada hoje. Até lá, a cloud é o terceiro identificado por trás de cada registo assinado.

A autenticação dos utilizadores é tratada pela Clerk (email, redes sociais, MFA). A associação opcional de uma carteira liga um endereço de carteira à identidade de ator de um utilizador, para efeitos de atribuição; não é um método de início de sessão.

O que o KIFF aplica

Em termos simples: o KIFF devolve uma decisão; a sua integração executa o efeito secundário. O KIFF é o ponto de controlo, não quem executa. É a mesma postura de qualquer motor de políticas, uma biblioteca de permissões, um servidor de políticas, uma API de fraude ou de moderação: devolvem um veredicto e o sistema que os chama respeita-o. A força é real, e esta secção diz exatamente onde ela está.

No ponto de controlo, o KIFF impede a ação. Quando a ação de um agente passa pelo guarda, qualquer resultado que não seja allowed trava a execução, essa travagem é o contrato de segurança em caso de falha do guarda. E cada ação com consequências é decidida face à política que declarou e ao estado da entidade, e registada num recibo que evidencia adulterações, antes de ser executada. O produto é essa decisão e esse registo comprovável, não a pretensão de intercetar fisicamente caminhos de código que não executamos.

A aplicação é uma definição que você controla, por espaço de trabalho, e é estrita por omissão. Um controlo corre em enforce (a predefinição, cada decisão é vinculativa, e aplica-se a travagem acima) ou em observe (apenas consultivo, o KIFF decide e regista exatamente da mesma forma, mas marca a decisão como consultiva, para que a sua integração continue a correr enquanto observa o que a aplicação teria parado). O modo observe é opcional e definido por nós a seu pedido, nunca pelo agente e nunca por omissão, um espaço de trabalho nunca fica só em observe por acidente. É a via de entrada: veja as decisões do ponto de controlo sobre tráfego real e depois ative o enforce.

O que o KIFF para e o que não para

Tornar o ponto de controlo mais difícil de contornar

A aplicação fica mais forte à medida que dá ao ponto de controlo um lugar mais apertado no caminho. Você escolhe o nível que o seu risco e o custo de integração justificam.

Observe, apenas consultivo, implementado

A via de entrada. O KIFF decide e regista cada ação, mas marca-a como consultiva, para que a sua integração corra sem alterações enquanto observa o que a aplicação teria permitido, impedido ou retido. Opcional e definido por nós a seu pedido; um espaço de trabalho nunca fica só em observe por omissão. Ative o enforce quando as decisões lhe parecerem certas.

Guarda no ponto de integração, implementado

As ações do seu agente passam pelo guarda, que pede ao KIFF que decida e trava tudo o que não for autorizado. A governação é o caminho por omissão, não um passo adicional. A superfície de contorno que resta é o seu próprio código não governado.

Proxy em linha, planeado

O KIFF fica à frente da API da ação e só encaminha a chamada depois de uma decisão que a autorize, pelo que decidir e executar passam a ser um único salto que um agente não pode separar. A superfície de contorno reduz-se a «chamar a API real sem o proxy», o que uma política de rede pode fechar.

Ponto de controlo na ferramenta, planeado

O único caminho do agente até à ação é uma ferramenta controlada pelo KIFF, pelo que o modelo não pode produzir o efeito secundário sem passar pelo ponto de controlo, o ponto de controlo é a superfície da ferramenta.

Nada aqui afirma que o KIFF impede fisicamente uma ação que não é ele próprio a executar. O que ele impede no ponto de controlo, o registo que deixa e a forma como esse ponto de controlo se aperta estão indicados acima, nada que uma pergunta difícil deva conseguir desmontar.

Práticas operacionais atuais

Custódia da carteira de assinatura

A carteira que assina os recibos e submete os compromissos na cadeia pública é mantida na nossa infraestrutura, sob controlos de acesso separados dos engenheiros da aplicação. O caminho de código da aplicação assina através de uma interface de serviço; não pode extrair a chave. A custódia de chaves de assinatura por tenant (uma carteira por tenant, com um caminho de migração do lado do tenant) está no roteiro abaixo.

Ancoragem fora de banda

O processo que submete as transações de compromisso na cadeia pública corre fora de banda em relação ao caminho de proposta e decisão. Uma falha ou um comprometimento do plano da aplicação não bloqueia nem repete compromissos que já foram difundidos.

Isolamento de tenants

Os dados de cada tenant ficam num esquema Postgres dedicado (kiff_t_<id>), com o search_path do conjunto de ligações fixado por tenant. As consultas entre tenants são arquitetonicamente impossíveis a partir do caminho de execução.

Encriptação

TLS 1.2+ para o tráfego. Postgres encriptado em repouso com as chaves por omissão do fornecedor gerido; a encriptação por linha com chaves do cliente está no roteiro abaixo.

Localização dos dados

eu-west-1 (Irlanda): o KIFF Cloud, o serviço tafs e o planque, com as suas bases de dados, cópias de segurança, segredos e registos.

Subcontratantes ulteriores

Fornecedores que tratam dados dos tenants por nossa conta. A lista oficial, com os dados a que cada um acede, está em /pt/subprocessors. Atualizamo-la no prazo de 30 dias após qualquer alteração.

O trilho público verificável não é um subcontratante ulterior: recebe apenas hashes de resumo e nenhuns dados pessoais.

Resposta a incidentes

Comunique uma suspeita de problema de segurança para security@kiff.dev. Procuramos acusar a receção no prazo de um dia útil e dar seguimento com uma avaliação inicial no prazo de cinco.

Os incidentes que afetam dados dos tenants dão origem a uma notificação por escrito aos clientes afetados no prazo de 72 horas após a confirmação, com um relatório público pós-incidente quando a resposta imediata estiver encerrada. O procedimento operacional completo é interno; a política de resposta acima é o compromisso perante o cliente.

Atualizações de segurança

Fornecemos atualizações de segurança enquanto oferecermos o Serviço. O KIFF Cloud, o serviço tafs e o planque correm nos nossos servidores, pelo que uma correção chega a todas as contas quando a implementamos, sem que você tenha de instalar nada. As apps tafs recebem as suas através da App Store e do Google Play. Um problema corrigido que tenha afetado os seus dados é-lhe comunicado como indicado acima.

Dados que tratamos

O que o KIFF Cloud recebe, o que guarda, o que nunca guarda e o que é destruído quando um tenant sai. Esta é a fonte de verdade a que a nossa implementação tem de corresponder. Cada item abaixo indica se está disponível hoje ou planeado.

Identificadores que guardamos tal e qual

O ID do tenant, o ID do ator, o ID da entidade, o nome da ação, a etiqueta da decisão, as datas e horas do pedido e da resposta, os hashes dos recibos e os hashes das transações do trilho público que fixam esses recibos. Este é o conjunto mínimo de que a framework precisa para reproduzir o estado e de que a cloud precisa para atribuir os registos assinados.

Campos controlados pelo tenant que guardamos

Do objeto parameters de uma proposta, só são guardados os parâmetros numéricos (montantes, contagens), porque os limites os contam. O pedido completo é guardado como um hash, para que uma nova tentativa se distinga de um pedido diferente. Os outros parâmetros não são guardados. O texto livre reasoning_summary é guardado tal como foi escrito, sem limpeza automática. Está planeada para ele uma configuração de ocultação por domínio, declarativa, keep / hash / drop.

Identificadores que nunca guardamos

Os prompts e as respostas em bruto dos modelos. A cloud encaminha o tráfego de inferência para o fornecedor de modelos configurado e não guarda nenhuma cópia. Os tenants que queiram os prompts no recibo têm de optar por isso domínio a domínio; essa funcionalidade ainda não está construída.

O tafs é diferente, porque um taf é um agente que executamos por si: as suas execuções e os seus chats, com o resumo de cada chat, são guardados no armazenamento próprio do tafs durante 30 dias (o que as suas apps devolvem, só até a execução terminar; num chat, o que ele apenas leu é guardado para as mensagens seguintes, encriptado com a chave própria da conta, e usado até o chat estar uma hora inativo e, no máximo, quatro horas após a leitura, sendo depois eliminado automaticamente, no prazo de alguns dias), e as suas notas de memória até você remover o taf. Por cada chamada que um taf faz através do KIFF, o tafs guarda a referência do KIFF para a chamada e o identificador daquilo sobre que atuou (por exemplo, o ID de um pagamento, nunca os dados do cliente) durante 30 dias, para o mostrar no Registo do taf; o resto dos dados de entrada de uma chamada só é guardado até a execução terminar. O Anexo 4 do DPA enumera o que o tafs guarda e durante quanto tempo.

Dados que nunca publicamos no trilho verificável

A cloud publica num trilho público verificável um hash de resumo, que evidencia adulterações, do lote de auditoria de cada tenant. O resumo compromete-se com os registos subjacentes sem os revelar; os registos em si nunca saem da base de dados da cloud. O «salting» criptográfico por tenant está ativo: cada folha da árvore de resumo está ligada a um segredo de 32 bytes exclusivo do tenant emissor, pelo que dois tenants com registos de bytes idênticos se comprometem com folhas diferentes, e o trilho público não pode ser usado como oráculo de confirmação para registos adivinhados mas não verificados. O «salt» é gerado no servidor quando o tenant é criado, nunca sai da base de dados da cloud e é destruído quando os dados de um tenant são eliminados.

Dados que eliminamos quando um tenant é eliminado

Um pedido de eliminação de um tenant apaga o esquema Postgres do tenant, os registos de auditoria, as chaves de API e as referências às chaves de assinatura. Os hashes já publicados no trilho público verificável permanecem, porque esse trilho é imutável; a destruição do «salt» do tenant torna esses hashes publicados permanentemente impossíveis de reconstruir. Um atacante fora da cadeia que tenha apenas os dados do trilho e um registo candidato deixa de poder verificar que o candidato pertence ao tenant eliminado, o «salt» que ligava o hash de resumo ao registo desapareceu, e a pré-imagem que produziu o hash já não pode ser reproduzida.

Hoje, a eliminação é feita por um operador: os tenants que queiram os seus dados apagados enviam um email para privacy@kiff.dev e nós seguimos o nosso procedimento interno documentado dentro do prazo de um mês do artigo 12.º, n.º 3, do RGPD. Uma CLI de eliminação e uma área do painel, ambas em regime self-service, são itens do roteiro abaixo.

Dados sobre as pessoas que iniciam sessão

Quando um utilizador inicia sessão, a cloud guarda o identificador de autenticação do fornecedor a montante e o endereço de email usado para iniciar sessão. O email está atualmente guardado em texto simples; guardar apenas um HMAC do email e uma forma de apresentação mascarada está planeado. Os fluxos de recuperação de conta que precisam do email original leem-no do fornecedor de identidade a montante, não da nossa base de dados.

Pseudonimizados, não anonimizados

O KIFF Cloud pseudonimiza os identificadores dos tenants: os identificadores diretos são substituídos por tokens opacos estáveis, mas os dados continuam a dizer respeito a uma pessoa e as regras de proteção de dados da UE continuam a aplicar-se. O produto não anonimiza os dados de auditoria, porque a reprodução determinística é a funcionalidade que vendemos. Se um tenant precisar de exportações anonimizadas para análise, essa é uma capacidade à parte que não construímos.

O que o KIFF guarda de uma chamada

Apenas o que é necessário para aplicar um Card e para o auditar:

• Guardado: quem pediu (agente e chave), a ação, a entidade, o resultado e os seus motivos, o Card em vigor e os parâmetros numéricos (montantes, contagens), que os limites contam. O registo da decisão e o seu recibo são construídos a partir destes.
• Em hash: os argumentos completos de uma chamada, para que uma nova tentativa se distinga de um pedido diferente. Através do gateway do KIFF, também o valor do argumento sobre o qual a chamada atua (como o ID de um pagamento), para que o registo do proprietário e o recibo possam mostrar qual é a quem o tenha.
• Descartado: os outros parâmetros nunca são guardados. Através do gateway do KIFF, os argumentos de uma chamada só são guardados até ela ser enviada ou recusada, e o resultado da ferramenta durante 24 horas, para que uma nova tentativa receba a mesma resposta.

O que não fazemos hoje

• Não há ocultação automática do texto livre reasoning_summary do agente: é guardado tal como foi escrito, para que o aprovador e a auditoria vejam o relato do próprio agente. Não ponha nele dados pessoais.
• Não há hashing automático dos emails na tabela de metadados de autenticação. Planeado.

Quaisquer conjuntos de dados derivados entre tenants que venham a existir serão regidos por um compromisso de minimização de dados separado. Na v0.1 não existe nenhum conjunto de dados derivado.

Esta secção descreve a postura da cloud no tratamento de dados; não é uma política de privacidade nem um Acordo de Tratamento de Dados. Os tenants de setores regulados devem contar com um DPA separado e assinado antes da utilização em produção.