Pular para o conteúdo

O que protegemos, como, e o que ainda falta.

Colocar um gateway na frente do seu tráfego de IA é uma decisão de confiança real, tomada por alguém que recebeu um questionário e um prazo. Esta página foi escrita para essa pessoa. Cada controle abaixo cita o mecanismo que o aplica, cada data é um compromisso e não uma aspiração, e o que não temos está listado com a mesma clareza do que temos.

As contas do INFRO são self-service. O catálogo, a documentação e o contrato da API são públicos, o gateway está implantado, e tudo o que vai além da v1 está marcado para depois. Planos e teste

São compromissos sobre o nosso próprio calendário, não afirmações sobre a conclusão de um auditor. Nada aqui diz que o INFRO é certificado, porque não é — e onde uma data ainda não foi acordada com a firma de auditoria, esta página diz isso em vez de estimar uma.

Nenhuma data foi assumida ainda. Uma empresa de auditoria foi contratada para o SOC 2. A janela de observação não está agendada, então não há nada aqui para publicar — e preferimos dizer isso a citar um trimestre que não combinamos com a empresa. Quando for agendada, as datas aparecerão aqui, em vez de serem enviadas a avaliadores individuais, para que todos nos cobrem pelo mesmo compromisso. Se o seu cronograma depende disso, diga e contaremos em que pé o agendamento realmente está — sales@infro.io.

SOC 2 Type I

Auditor contratado

A opinião de um auditor de que os controles descritos nesta página são adequadamente projetados e estavam em vigor em uma data específica. Ela não diz nada sobre se funcionaram ao longo do tempo — isso é o Type II.

A observação começa
Ainda não publicado
Relatório previsto
Ainda não publicado

Na conclusão, esta página nomeia a firma de auditoria, a data do relatório e os critérios de serviços de confiança no escopo, e o próprio relatório é entregue sob NDA. Até o relatório existir, nem a firma nem o escopo são afirmados aqui.

SOC 2 Type II

Auditor contratado

A opinião de um auditor de que esses controles funcionaram de forma eficaz ao longo de uma janela de observação, que é o relatório que a maioria das revisões de segurança de fato quer.

A janela de observação começa
Ainda não publicado
A janela de observação termina
Ainda não publicado
Relatório previsto
Ainda não publicado

Uma janela do Type II não pode ser comprimida: o relatório só vale o período que observou. Se a janela mudar, a data aqui muda junto e a alteração é informada, e não corrigida em silêncio.

ISO 27001

Em avaliação

Certificação de um sistema de gestão de segurança da informação, e não de um conjunto de controles. Revisores de fora dos EUA a pedem com mais frequência do que o SOC 2.

Em avaliação. Nenhum auditor está contratado e nenhuma data está comprometida — por isso não há data nesta página, e não haverá até existir algo com que se comprometer. Se a ISO é um requisito rígido para você, diga isso no seu primeiro e-mail; é um sinal útil e pode mudar a ordem em que fazemos isso.

Não temos nenhuma certificação hoje, e nada acima diz o contrário. Quando houver um relatório, esta página informará a empresa de auditoria, a data do relatório e os critérios no escopo, e o relatório será enviado sob NDA. Até lá, o que podemos oferecer é o conjunto de controles abaixo, o conjunto de respostas e uma resposta direta sobre em que pé a auditoria realmente está — e se o seu processo exige um relatório em mãos antes da assinatura, a resposta certa é esperar, não negociar.

Cada um deles está implementado agora, e cada um cita o mecanismo, não a intenção — um trigger de banco de dados, um binding, um header implantado. Quando um controle é uma política e não um mecanismo, isso é dito.

Credenciais e chaves

As credenciais de provedor são seladas e vinculadas a um único tenant
As chaves de provedor que você conecta são criptografadas com AES-256-GCM sob uma chave mantida como segredo do Worker, nunca no banco de dados. Os identificadores da organização e da conexão são vinculados como dados autenticados adicionais, de modo que uma credencial selada copiada para a linha de outro tenant — ou para outra linha do mesmo tenant — falha de forma fechada em vez de ser decifrada. As credenciais conectadas para a reconciliação de custos são seladas separadamente, sob o próprio vínculo.Vinculada como conn:<organization>:<connection> para credenciais de inferência e billing:<organization>:<provider kind> para credenciais de APIs de custo. Um vazamento do banco de dados, por si só, não abre nada.
Não há revelação, em lugar nenhum
Depois que uma credencial de provedor é salva, nenhuma interface a devolve — nem o console, nem a API, nem o console interno do operador. O que qualquer um dos lados consegue ver são os últimos quatro caracteres e os timestamps. Se você perder a chave, rotacione-a no provedor; não podemos mostrá-la a você.As consultas de conexões do console do operador não selecionam a coluna selada de forma alguma. Um botão de revelar é o recurso que transforma uma sessão comprometida nas chaves de fornecedor de todos os clientes.
As chaves de API do INFRO têm hash em repouso
Uma chave de gateway tem 32 bytes de uma fonte aleatória criptográfica. O que armazenamos é o digest SHA-256 dela, um prefixo de exibição e os últimos quatro caracteres, de modo que um vazamento do banco de dados não expõe uma credencial utilizável. A revogação grava um tombstone em vez de excluir a linha, para que não seja encoberta por uma entrada de cache obsoleta ainda se propagando entre localidades.SHA-256 em vez de um KDF de senhas é deliberado: não há dicionário para atacar 32 bytes aleatórios, e um KDF acrescentaria 50-200 ms de computação cobrada a cada requisição.
A chave de criptografia pode ser rotacionada sem o seu envolvimento
Rotacionar a chave que sela as credenciais dos clientes re-sela cada credencial armazenada no lugar. Não pede aos clientes que reinsiram nada, e o algoritmo armazenado carrega uma string de versão para que um esquema futuro possa coexistir com o atual, sem exigir um dia de virada.Dito com clareza: perder essa chave sem backup é irrecuperável, e todo cliente teria de reconectar todos os provedores. Backup e recuperação estão escritos como um procedimento operacional.

Seu conteúdo

Não treinamos com os seus dados e não os vendemos
O INFRO não usa os seus prompts, entradas ou saídas para treinar nada e não os vende. Os provedores que você conecta tratam os seus dados sob os seus próprios acordos e configurações de conta com eles — os controles de logging do INFRO não mudam essas configurações e não podem mudá-las.Este é o único controle desta página que é uma política e não um mecanismo. Ele está declarado nos termos e no DPA, que é onde pode ser exigido.
A captura de prompts e respostas vem desativada por padrão
Os metadados da requisição — modelo, provedor, rota, contagem de tokens, latência, custo estimado — são sempre registrados, porque medição, orçamentos e governança são o que o produto é. O conteúdo de prompts e respostas não é, a menos que uma organização ative a captura. A coluna do banco de dados vem desativada por padrão; não há plano em que venha ativada.org_settings.prompt_logging_enabled, DEFAULT false NOT NULL desde a primeira migração.
A janela de retenção é sua, e a varredura de exclusão é real
Quando a captura está ativada, você escolhe a janela — 24 horas, 14, 30, 60 ou 90 dias, ou um ano — e o que é armazenado é o menor entre a sua escolha e o teto do seu plano, de modo que uma superfície nunca possa oferecer uma janela que o plano ignoraria em silêncio. Um job agendado exclui os payloads capturados quando passam do prazo de expiração, em lotes limitados, para que um acúmulo não se transforme em uma transação longa contra uma tabela em que o caminho da requisição está escrevendo.Cada linha de payload tem o próprio expires_at; a limpeza roda no cron de um minuto da plataforma e o atraso dela é uma das condições que disparam um alerta de operador. A exclusão é um DELETE, não uma marcação.
A exportação de traces é uma lista de permissões, não uma cópia
Se você envia spans OpenTelemetry para o seu próprio collector, o conjunto de atributos é montado campo a campo, e não espalhando uma linha do banco, de modo que uma coluna interna adicionada depois não vaza por padrão para o seu backend de observabilidade. O endpoint do collector precisa ser HTTPS, imposto por uma constraint do banco de dados, e os headers que você configura são selados como qualquer outra credencial.Este é o único lugar em que o INFRO envia deliberadamente os seus dados a um host de terceiros que você escolheu, e o único lugar em que um vazamento seria duradouro. Um teste verifica que identificadores internos estão ausentes dos bytes codificados.

Acesso e responsabilização

O log de auditoria não pode ser reescrito
Toda mudança de política, atualização de credencial, rotação de chave, concessão de plano e mudança de participação é uma nova linha com um autor e um timestamp. Essas linhas rejeitam UPDATE, DELETE e TRUNCATE no nível do banco de dados — não por convenção, nem por código de aplicação que um script de suporte poderia contornar. O histórico da sua organização é um registro, não um valor.Imposto por um trigger do banco de dados. Nem um engenheiro do INFRO em um prompt do psql nem uma aplicação comprometida pode alterá-lo discretamente.
A identidade de clientes e de operadores não compartilha nada
O console do cliente e o console interno do operador se autenticam em dois sistemas separados: tabelas separadas, nomes de cookie separados, segredos de assinatura separados, listas de origens permitidas separadas. Uma sessão de cliente apresentada a um endpoint de operador é anônima ali, e não apenas com poucos privilégios — ela traz um nome que aquele sistema não procura, assinado com uma chave que ele não possui, contra uma tabela que ele não lê.O Worker se recusa a iniciar se os dois segredos de assinatura forem iguais ou se as duas listas de origens se sobrepuserem. O cadastro de operadores está desativado permanentemente; as contas são provisionadas, e a linha de um operador suspenso é mantida justamente para que uma verificação de existência não o deixe voltar.
Dois fatores para operadores e um step-up em ações destrutivas
A autenticação em dois fatores TOTP está disponível para todo operador e vem desativada por padrão — uma decisão deliberada, declarada aqui em vez de insinuada. Com ela ativada, toda sessão de operador precisa apresentar um código e a senha nunca o substitui. Independentemente dessa configuração, ações que mudam dinheiro, credenciais ou o acesso de outro operador exigem um segundo fator apresentado nos últimos 15 minutos; onde os dois fatores estão desativados, esse step-up é a senha. Dez falhas consecutivas bloqueiam a conta por quinze minutos.A prova é uma linha de fator por sessão gravada apenas pelo hook de verificação, de modo que uma sessão criada em outro navegador não abre nada. Os códigos são de uso único; os códigos de backup são de uso único e armazenados criptografados.
Dois fatores, passkeys e sessões para os seus próprios usuários
Toda conta pode ativar autenticação em dois fatores com um app autenticador e dez códigos de recuperação de uso único, e registrar passkeys ou chaves de segurança físicas, que entram sozinhas ou servem de segundo passo depois da senha. Um proprietário ou administrador pode exigir dois fatores para toda a organização: um membro sem isso não alcança nada nessa organização até configurá-lo. O login único atende ao requisito, porque o seu provedor de identidade impõe o próprio MFA. Toda conta pode ver onde está conectada e encerrar qualquer sessão.Os códigos são de uso único e dez falhas bloqueiam a conta por quinze minutos; não existe lembrar este dispositivo. Remover um fator exige um segundo fator apresentado nos últimos dez minutos, não só a senha. Uma passkey entra sozinha apenas se o dispositivo verificou o usuário. Códigos por e-mail e SMS não são oferecidos.
Sua organização nunca é lida da requisição
Os endpoints do console e de operadores obtêm a organização da sessão autenticada e a passam como argumento explícito, de modo que um ponto de chamada não pode deixá-la sem definir e um parâmetro de corpo ou de consulta que nomeie uma organização não pode virar uma decisão de autorização tomada a partir de entrada controlada por um atacante.Um teste estrutural passa linhas reais pelas projeções de resposta reais com um valor sentinela, verificando que identificadores internos e corpos de erro upstream nunca chegam a uma resposta ao cliente.

A superfície da plataforma

Headers de segurança nas três superfícies
infro.io, o console do cliente e o console do operador enviam, cada um, um Content-Security-Policy, HSTS, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, um Referrer-Policy, um Permissions-Policy e Cross-Origin-Opener-Policy. O console do operador acrescenta uma política de recursos e uma diretiva de no-index, e a página de login dele traz uma política de nonce por resposta que não permite nenhum script inline.Verificável de fora com curl -I em qualquer um dos três hostnames. Um script versionado percorre todas as rotas com a política aplicada e falha em qualquer violação, de modo que uma origem de terceiros adicionada não pode entrar em silêncio.
Os webhooks de saída são assinados e rotacionam sem lacuna
Todo webhook que enviamos traz uma assinatura HMAC-SHA256 sobre o timestamp e o corpo bruto exato, para que você verifique tanto a autenticidade quanto que o payload não foi alterado em trânsito. Durante uma rotação de segredo, a entrega é assinada com o segredo antigo e o novo, para que você adote o novo sem perder nenhuma entrega.Formato do header INFRO-Signature: t=<unix>,v1=<hex>, documentado com código de verificação. A assinatura e o timestamp são o motivo de um webhook ser tratado como uma notificação a confirmar, nunca como uma autoridade para agir.
Uma única superfície de erros documentada
Toda recusa que o gateway faz é de um conjunto publicado de tipos e códigos, inclusive as que são culpa nossa. As requisições têm limite de tamanho antes de qualquer análise, com um 413 documentado em vez de um timeout, e as superfícies de autenticação, login e leads têm limite de taxa pelo endereço de rede do chamador.Publicado por completo em /docs/api/errors antes de você escrever uma linha de código contra ele. Os headers de limite de taxa dizem quais são exatos e quais são um limite superior.
Uma lista nomeada de subprocessadores, com aviso prévio
Os fornecedores que o INFRO contrata são nomeados em /subprocessors, com o que cada um de fato consegue ver e onde roda, e com aviso de 30 dias antes de um novo começar a processar. Os provedores de IA que atendem as suas requisições são aqueles que você escolheu e com quem contrata diretamente — não são subprocessadores do INFRO, e a página explica por que essa distinção é real e não conveniente.Dois fornecedores de infraestrutura nomeados hoje. O banco de dados roda em Frankfurt e o gateway roda ao lado dele; as requisições entram na rede da Cloudflare onde quer que o chamador esteja, e a página diz isso em vez de insinuar uma região.

Esta lista existe porque o resto da página vale menos sem ela. Se um destes pontos bloqueia uma compra, é uma conversa que preferimos ter no seu primeiro e-mail e não na quarta semana de uma avaliação.

Sem SOC 2 ou ISO 27001 hoje
Nenhum dos dois é mantido. Uma auditoria precisa de um histórico de operação para examinar, e o nosso é curto. O roadmap acima é aquilo com que nos comprometemos em vez disso; se o seu processo não pode avançar sem um relatório em mãos, isso é um motivo para esperar e não um motivo para negociar.
Sem teste de intrusão independente
Nada nesta página foi revisado por alguém de fora da equipe que a escreveu. Mantemos uma revisão de segurança interna permanente organizada por ativo, e ela é uma autoavaliação — que é a diferença entre ter pensado em algo e ter tido alguém que tentasse atacá-lo.
Sem processamento exclusivo na UE ou regional
As requisições entram na rede da Cloudflare na localidade mais próxima do chamador, onde o TLS termina, e o próprio gateway roda em Frankfurt, ao lado do banco de dados. Essa colocação encurta as idas e vindas ao banco; não é um controle de residência de dados, e o processamento restrito a uma região exige direitos de infraestrutura que não compramos. Um hostname com aparência europeia que não restringe de fato o processamento é uma afirmação que você poderia refutar em uma única requisição, então não oferecemos um.
O serviço hospedado é multi-tenant
Em todos os planos self-service, as organizações compartilham o serviço hospedado e o isolamento entre elas é lógico, e não físico. Se o seu requisito é que o nosso software rode na sua própria infraestrutura, isso é uma implantação auto-hospedada ou híbrida mediante contrato enterprise, delimitada e acordada por contrato; nenhum plano self-service inclui uma.
Sem SLA de disponibilidade publicado nos planos self-service
Um serviço sem histórico de operação não pode publicar com honestidade um compromisso de disponibilidade, então não publicamos nenhum. Um contrato enterprise pode trazer um SLA contratual com remédios, acordado por contrato. A saúde do gateway pode ser verificada do seu próprio navegador em /status.
SSO e SCIM são novos
O login único SAML e OIDC e o provisionamento SCIM 2.0 estão implementados e incluídos a partir do plano Business, condicionados a um domínio verificado por DNS. Ainda não rodaram em produção com todos os provedores de identidade, então configuramos a primeira conexão com cada cliente em vez de chamá-la de self-service.
Os guardrails são por padrões; não há guardrails por classificador
Os guardrails para chat completions, incluídos a partir do plano Business, verificam prompts e respostas contra padrões fixos — endereços de e-mail, números de telefone, números de cartão, IBANs, números de Social Security dos EUA, endereços IP, chaves de API e termos que você lista — e bloqueiam, mascaram ou sinalizam o que casa. A correspondência por padrões não percebe nada fora desses formatos. Nada detecta injeção de prompt, jailbreaks, toxicidade ou requisições fora do tema, e imagens, áudio e endpoints além de chat completions não são inspecionados. Se a sua revisão exige um classificador de conteúdo no caminho da requisição, o INFRO não oferece um.
Sem teto de custo por requisição
Os orçamentos limitam o total que a sua organização, um projeto, um membro ou uma chave pode alcançar, e os limites de taxa restringem o volume de requisições. O que ainda não existe é um controle que recuse uma única requisição incomumente cara. Um prompt grande legítimo e um abusivo parecem iguais para o gateway, e um cliente esperaria razoavelmente esse controle.
Os limites de taxa são aplicados por localidade
Os limites são contados pelo serviço de rate limiting da Cloudflare na localidade em que o gateway roda, e não por um único contador global. O gateway é colocado em Frankfurt, então a maior parte do tráfego é contada lá, mas a colocação é uma preferência de roteamento e não uma garantia, e o tráfego tratado em outro lugar é contado separadamente — de modo que uma chave pode exceder brevemente o limite nominal. É uma troca deliberada — a alternativa do contador global limita o maior cliente pela nossa arquitetura e não pelo limite dele — e a documentação da API diz quais headers de limite de taxa são exatos e quais são um limite superior.

Listamos o que não está implementado com a mesma clareza do que está. Se uma linha aqui impede uma compra, preferimos ter essa conversa agora do que depois de um contrato.

Sem treinamento com os seus dadosAssumido
O INFRO não treina com nem vende os seus prompts, entradas ou saídas. O uso de dados pelos provedores de IA que você conecta segue os seus acordos e configurações com eles.
Log de conteúdo desativado por padrãoAssumido
Os metadados de uso servem para a medição da plataforma, as estimativas de custo e a governança. Os logs opcionais de prompts e respostas vêm desativados por padrão, são armazenados à parte e limitados pela retenção do seu plano.
Chaves com hash em repousoAssumido
As chaves de API são armazenadas como digests SHA-256 de 32 bytes de um CSPRNG. Um vazamento do banco de dados não expõe uma credencial utilizável, e a revogação grava um tombstone para que uma entrada de cache obsoleta não a encubra.
Log de auditoria somente de acréscimoAssumido
As linhas de auditoria não podem ser atualizadas nem excluídas — o próprio banco de dados recusa. Toda mudança de política, atualização de credencial, rotação de chave e mudança de participação é uma nova linha com um autor, de modo que o histórico da sua organização não pode ser reescrito em silêncio.
Lista de subprocessadores publicadaAssumido
Os fornecedores de infraestrutura são nomeados em /subprocessors, com aviso de 30 dias antes de um novo começar a processar, sujeito à exceção de emergência descrita ali. Você escolhe e contrata diretamente os provedores de IA que conecta.
SOC 2 / ISO 27001Ainda não
Não temos, e não alegamos. Uma certificação exige um histórico de operação para auditar, e o do gateway é curto. O que é publicado no lugar é o roadmap em /trust: uma firma de auditoria está contratada para o SOC 2, ainda sem janela de observação agendada; a ISO 27001 está em avaliação, sem auditor e sem data; e nenhuma das duas é descrita como mais do que isso. As datas aparecem ali quando a firma as acordar, não antes.
DPA com Cláusulas Contratuais PadrãoAssumido
Publicado na íntegra em /dpa, incorporando as SCCs com o UK Addendum. A assinatura é feita por e-mail, não pelo console — não há fluxo de contra-assinatura, e a página diz isso em vez de sugerir um botão.
Residência de dados na UEAinda não
Exige direitos de infraestrutura que não contratamos. Um hostname que apenas parece europeu é uma afirmação que um cliente pode desmentir com uma única requisição, por isso não vamos oferecer um até que o processamento esteja de fato restrito.

Nossas respostas às perguntas que uma revisão de segurança realmente faz — tratamento de dados, criptografia, gerenciamento de chaves, controle de acesso, monitoramento, conformidade — publicadas como um documento de texto simples que você pode ler, comparar e colar nas suas próprias ferramentas.

Baixe o conjunto de respostasLeia no navegador

É Markdown, e não uma planilha CAIQ, de propósito. O valor do CAIQ está na numeração das perguntas, e um CAIQ preenchido em parte sugere participação em um registro do qual não fazemos parte — então este documento cobre o mesmo terreno na ordem em que um avaliador lê, em um formato que tanto suas ferramentas quanto as nossas conseguem comparar. Ele é gerado a partir dos mesmos dados desta página, então os dois não podem divergir.

Envie também o seu próprio questionário, no formato que for. Respondemos a todas as perguntas, inclusive aquelas cuja resposta é não, e dizemos quais delas têm data. Escreva para sales@infro.io.

Leia-os antes de nos perguntar sobre eles. Nenhum exige uma ligação, um NDA ou uma conversa com vendas para ser visto.

Contrato de processamento de dados
O texto completo, incorporando as Cláusulas Contratuais Padrão com o Adendo do Reino Unido, incluindo a obrigação de notificação de violações e o cronograma de retenção. A assinatura é feita por e-mail — não há fluxo de contra-assinatura no console, e a página diz isso em vez de sugerir um botão.
Subprocessadores
Cada fornecedor que o INFRO contrata, o que cada um realmente pode ver, onde roda, e aviso de 30 dias antes de um novo começar a processar dados. Também explica por que os provedores de IA que você conecta não são suboperadores do INFRO.
Política de privacidade
O que é coletado, as bases legais, por quanto tempo cada categoria é mantida e os direitos disponíveis a um titular de dados. Alinhado às janelas de retenção desta página, sem contradizê-las.
Política de uso aceitável
O que não pode ser construído na plataforma, incluindo as categorias sem caminho de aprovação, e o que acontece quando descobrimos. Escrito no vocabulário das bandeiras de cartão, porque são elas que perguntam.
Política de divulgação de vulnerabilidades
O que está no escopo, como testar sem prejudicar outro cliente, o que nos comprometemos a fazer quando você reporta e o porto seguro para pesquisa de boa-fé. Também publicado como /.well-known/security.txt.
Termos de serviço
O contrato comercial, a entidade operadora e sua jurisdição, e o que acontece com uma conta ao fim dele.
A taxonomia de erros
Cada recusa que o gateway pode fazer, publicada antes de você escrever uma linha de código contra ele — inclusive as que são culpa nossa, não sua.
Tratamento de dados, na referência da API
Campo por campo: o que é registrado em cada requisição, o que a captura acrescenta quando uma organização a ativa e como a janela de retenção é aplicada. A versão para engenheiros do controle de retenção descrito acima.
Chaves e autenticação
Como as chaves do gateway são emitidas, restritas a um projeto e um ambiente, limitadas por função e revogadas — escrito para quem precisa decidir quem na sua organização recebe uma.
Segurança de chaves de API de IA
Onde ficam as chaves de provedor com e sem um gateway, as quatro verificações pelas quais toda chave do gateway passa antes de um provedor ser chamado e o que fazer na primeira hora depois que uma chave vaza.

Encontrou algo?

Envie para security@infro.io. Essa caixa de e-mail é lida pelas pessoas que podem corrigir o problema, e é para relatos de vulnerabilidades, não para suporte.

Escopo, regras de teste e o porto seguro completo: a política de divulgação de vulnerabilidades.

  • Confirmamos o recebimento em até um dia útil e mantemos você atualizado enquanto investigamos, inclusive quando a resposta é que já sabíamos.
  • Pesquisa de boa-fé é segura aqui. Não tomaremos medidas legais por testes que evitem violações de privacidade, degradação do serviço e destruição ou exfiltração de dados que não são seus.
  • Não há programa de bug bounty nem pagamento. Dito logo de início, porque descobrir isso depois do trabalho é pior do que saber antes.
  • Perguntas comerciais e de compras vão para outro lugar — sales@infro.io para uma revisão de segurança ou um questionário, support@infro.io para uma conta que você já tem.