O Intramedial está em beta restrito. Ao se cadastrar ou entrar, você precisa informar a senha de beta tester que recebeu ou solicitar uma em preview@intramedial.com. Obrigado.
Carregando…
Trust Center
Verificável
Confiança que você confere, não só lê.
A Intramedial decide o que os agentes podem fazer e mantém o registro. Esta página expõe como isso funciona, o que é fixado e onde, e o que ainda não publicamos. Ela não alega nenhuma certificação. Cada afirmação tem link para o documento ou a fonte por trás dela.
Os agentes agem quando o plano diz sim, e o registo diz porquê.
Passe ações de agentes, hashes de conteúdo, checagens de API, DNS, webhooks, chamadas de LLM e commits git pela Intramedial. Receba um recibo assinado que todos verificam – sem confiar em nós.
Toda chamada segue o mesmo caminho. As credenciais são checadas na porta de entrada, o trabalho é feito e guardado na região do próprio workspace, e a assinatura vem de um HSM que nunca libera sua chave.
Autenticar
A porta de entrada liga a credencial a um só workspace antes de rodar código de tool. Segredos são guardados e comparados como hashes SHA-256, em tempo constante.
Repassar
O workspace e as permissões seguem ao serviço regional em headers assinados pelos nossos próprios serviços. Sem assinatura válida, o serviço recusa a requisição.
Observar, registrar
Nas tools de relay e monitor, o serviço regional faz a requisição pelo filtro de saída; nas demais, registra os fatos que você reporta. Corpos viram hash, não são guardados.
Assinar
O envelope é canonicalizado com RFC 8785 e assinado no AWS KMS com a chave Ed25519 da região. Sem chave, o serviço recusa em vez de assinar com outra.
Verificar onde for
O recibo traz o id da chave dentro dos bytes assinados. Quem tem o recibo e a chave pública o confere sem nós, enquanto a chave seguir publicada.
02
O que prova
O que um recibo prova, e o que não prova.
Um recibo é uma afirmação precisa e estreita. Leia as duas colunas antes de confiar em um, e antes de pedir que outro confie.
Uma assinatura válida prova
Origem: o titular de uma chave de assinatura de bundle assinou exatamente estes bytes.
Integridade: nada no envelope mudou desde então, nem um só dígito.
Um intervalo selado: a raiz Merkle se compromete com os registros nele contidos.
O que não prova
Que um fato que você reportou é verdadeiro. Algumas tools assinam fatos do chamador, outras o que observamos; a página de cada tool diz qual.
Quem criou ou aprovou o conteúdo. O recibo registra um workspace, não uma pessoa.
O horário real de um evento. Não há autoridade terceira de carimbo do tempo.
Que nada aconteceu onde não há nenhum recibo.
Que somos neutros além da nossa palavra. Um log público testemunha as raízes dos lotes horários de hashes de recibos, mas nenhum terceiro confere o que um recibo diz. Esse registro público vem ativado por padrão; o proprietário ou um administrador do workspace pode desativá-lo para os recibos que ainda não estão em um lote.
No que ainda confia em nós
A verificação é independente. A confiança cabe numa lista curta e nomeada.
Você confia
Motivo
Se falhar
A chave pública usada na verificação é nossa
Uma assinatura prova quem detém uma chave, não de quem ela é.
Uma chave trocada faz fraudes parecerem válidas. Fixe o key id por outro canal.
Nossas chaves só são usadas pelo serviço de recibos
O serviço assina o que seu código decide assinar.
Mal usada, a chave poderia assinar eventos inexistentes.
Observamos honestamente nas tools observadas
As linhas do livro-razão dizem que o plano viu isto.
Um plano comprometido poderia gravar uma linha falsa no livro-razão.
Sete chaves Ed25519, uma por jurisdição de assinatura, são compartilhadas por todos os workspaces. As metades públicas são publicadas abertamente; as privadas são criadas e guardadas no AWS Key Management Service.
Custódia
As chaves são geradas em módulos de segurança de hardware do AWS KMS, validados FIPS 140-3 Nível 3, segundo a AWS.
O serviço de recibos envia bytes canônicos ao KMS e recebe uma assinatura. Tem uma credencial só de assinatura, que não pode exportar chaves.
Nenhuma rota da API devolve material de chave privada. As públicas só dão campos públicos.
Sem chave para uma região, o serviço responde 503 signing_unprovisioned; com o KMS inacessível, 503 signer_unavailable. Nunca recorre a outra chave nem emite recibo sem assinatura.
A rotação é uma cerimônia manual, não agendada. Uma chave aposentada segue publicada e recibos antigos seguem válidos.
Hoje não há lista de revogação nem log de transparência de chaves. Um comprometimento seria anunciado por aviso e por mudança no conjunto de chaves publicado.
A custódia em HSM impede que uma chave seja copiada. Não impede que quem pode fazer deploy do serviço o faça assinar; por isso fatos observados e reportados ficam separados.
O conjunto JWK direto, cache de uma hora, aberto a qualquer origem
/api/v1/ledger-bundles/anchors
Cada chave publicada com uma flag active
/api/v1/ledger-bundles/snapshot
Uma chave pública por key id
Obtenha o conjunto e recalcule um key id
curl -sSL https://ledger-bundles.api.intramedial.com/.well-known/ledger-bundles-keys.json -o keys.json
jq -r '.keys[] | [.kid, .jurisdiction] | @tsv' keys.json
// kid = 16 primeiros bytes do SHA-256 da chave crua, base64url
Para a posição mais forte, obtenha a chave uma vez, guarde seus valores kid e x no seu próprio repositório e verifique contra essa cópia. /docs/ledger-bundles-snapshot
04
Isolamento
Controle de acesso e isolamento
Toda requisição traz uma credencial que o gateway liga a um único workspace antes de rodar qualquer tool. Veja como credenciais, tenancy e requisições de saída são tratadas hoje.
01
Credenciais em hash
Chaves de API, tokens de acesso pessoal e tokens de sessão são guardados como hashes SHA-256, exibidos uma vez e comparados em tempo constante. As chaves expiram após 30 dias, 90 dias, um ano ou nunca, e giram com carência de 0 a 60 minutos.
02
Entrada e sessões
O login passa pelo Avonao ID. A duração da sessão, o tempo limite de inatividade e as configurações de cookies ainda não estão publicados aqui, então não são declarados. Não conte com nada além do que a página de login mostra.
03
Escopos e papéis
Escopos de leitura, escrita e gestão, restritos a tools nomeadas se quiser. Emitir recibo exige a permissão tools.attest, e o papel de auditor não pode criar recibos. As checagens falham fechadas.
04
Tenancy
Quem decide o workspace é o gateway, não quem chama. Toda leitura e escrita leva o id do workspace, e um corpo que cita outro workspace é recusado. A separação é lógica, num banco regional.
05
Requisições de saída
Destinos em localhost, nomes internos e faixas privadas ou reservadas são recusados, no envio e antes de cada checagem agendada. Redirects nunca são seguidos; tempo e tamanho têm limite.
06
Rate limits e abuso
600 requisições por minuto por IP e 1.200 por conta no gateway. A detecção no agent.call sinaliza padrões de varredura ou credential stuffing para revisão humana; nunca suspende sozinha.
Limites declarados: o filtro de saída lê a URL como texto e não resolve hostnames; a segunda camada é que o serviço roda na rede da Cloudflare, que não tem rota para espaço de endereços privado. Listas de IPs permitidos falham abertas se não puderem ser lidas, para que uma falha do banco não tranque clientes fora.
05
Dados mínimos
Proteção de dados
O serviço foi feito para guardar o mínimo possível. Na atestação recebe um hash, nunca o documento; nas chamadas via relay gera hash dos corpos e não os guarda.
Hash primeiro
Você calcula um SHA-256 e o envia. Nunca recebemos o texto do documento, do prompt ou da resposta.
Relay sem armazenamento
Corpos e headers repassados passam e viram hash. Corpos de resposta só são guardados se você ativar a retenção.
Recibos só-acréscimo
Triggers do banco recusam edições, e um hash de cada recibo também é arquivado em armazenamento de gravação única (S3 Object Lock) durante a janela do plano. Só rotas auditadas podem ocultar ou apagar; cada uma grava evento de auditoria.
Campos legíveis são legíveis
URLs, rótulos e autores de commit ficam em texto claro no recibo. Não ponha ali nada que não mostraria a quem o lê.
Locais de dados
Recibos, watches, contadores de cota, processamento de requisições via relay e assinatura rodam na região escolhida na criação do workspace. O painel, o site, o login, a cobrança e os dados de conta são servidos a partir dos EUA (US West) em todos os casos.
Região
Código
Chave de assinatura KMS
Storage
EUA Oeste
wnam
us-west.
Dica de local
Europa Central
weur
eu.
Jurisdição UE (aplicada)
Asia-Pacific
apac
asia.
Dica de local
Oceania
oc
oc.
Dica de local
Uma região diz onde os dados são guardados e processados. Um workspace nunca muda de região, e uma região inacessível falha a chamada em vez de recorrer a outra.
Criptografia
Os dados trafegam por TLS entre você e o serviço e são guardados no nosso provedor de infraestrutura, a Cloudflare, sob os termos de segurança dela. Os recibos são assinados, então qualquer mudança na evidência guardada é detectável por quem a verifica.
Exclusão e apagamento
A exclusão da conta vale após 30 dias de carência, em que você pode exportar e restaurar. O job de exclusão não remove recibos; eles expiram pela janela do plano, ou você os apaga, ou nos pede. Um recibo que você já entregou a alguém segue verificável por essa pessoa, faça o que fizermos.
Retenção
Recibos
A janela do plano: Free 7 dias, Starter 30, Pro 90, Pro+ 180, Team 365, Scale 730, Enterprise sob medida.
Dados de conta e login
Até a conta ser excluída, e então apagados após 30 dias de carência.
Logs operacionais e contadores de rate limit
No máximo 30 dias.
Log de auditoria
Pela vida do workspace e depois, com o titular substituído onde a exclusão é exigida.
Dados de cobrança
O que a lei tributária exigir, até 7 anos.
Cache de idempotência
24 horas, com o status e o id do recibo, nunca o corpo.
O status é medido, não escrito à mão. Níveis de serviço são cláusula contratual para clientes Enterprise, e a verificação nunca depende de estarmos no ar.
Status para todos
Sondados a cada minuto: o API gateway em cada uma das sete regiões de dados, o servidor MCP, a descoberta OAuth, as chaves de assinatura publicadas, o documento did:web do signatário e a verificação de recibos. A emissão de recibos (um recibo de teste assinado com a chave de produção e armazenado) entra assim que o workspace de sondagem dedicado for configurado; até lá, não é medida.
Uma checagem que falha ou leva mais de 8 segundos conta como fora; acima de 3 segundos, degradada. Um monitor parado mostra sem dados recentes, nunca verde.
Incidentes saem com atualizações, por inscrição de e-mail, feed Atom e JSON.
A página de status não é assinada e não é um acordo de nível de serviço.
Para planos Enterprise com formulário de pedido assinado, o SLA Enterprise define os termos. O suporte funciona em horário comercial e confirma o recebimento das solicitações Enterprise em 1 hora útil, 4 horas úteis ou 1 dia útil conforme a gravidade. Os planos de autosserviço não têm compromisso de disponibilidade nem créditos de serviço; suas metas de resposta do suporte estão na página de preços.
Serviço coberto indisponível, ou recibos não podem ser emitidos, para uso em produção.
1 hora útil
Severidade 2
Recurso importante prejudicado ou degradado, com contorno.
4 horas úteis
Severidade 3
Problema menor, dúvida ou pedido.
1 dia útil
Se o uptime ficar abaixo de 99,0% em três meses seguidos, ou em quaisquer quatro de doze, o cliente pode rescindir o pedido afetado com reembolso proporcional.
Verificar um recibo exige só o recibo e uma chave pública. Segue funcionando quando nosso serviço não funciona.
07
Divulgação
Resposta a incidentes e divulgação de falhas
O que assumimos quando algo dá errado, e como nos avisar de uma fraqueza antes que outra pessoa a encontre.
72h
Violação de dado pessoal
Avisamos o titular da conta por e-mail sem demora indevida e, em qualquer caso, em até 72 horas após tomarmos ciência de uma violação que afete dados pessoais de clientes, com o que se sabe: sua natureza, as pessoas e registros afetados, as consequências prováveis e as medidas tomadas. O aviso é complementado conforme soubermos mais.
Incidentes são publicados na página de status com uma linha do tempo de Investigating a Resolved. Num incidente de Severidade 1, clientes Enterprise recebem um aviso inicial e atualizações conforme a situação muda.
Reporte pelo formulário, com seus dados de contato ou de forma anônima, ou por e-mail. Pesquisa de boa-fé conforme a política é autorizada, e não tomaremos medidas contra você por ela.
Etapa
Meta
Confirmar seu relato
Em até 3 dias úteis
Avaliação inicial e severidade
Em até 10 dias úteis
Atualizações com a falha em aberto
Ao menos a cada 14 dias
Corrigir severidade crítica e alta
Miramos 30 dias
Corrigir severidade menor
Miramos 90 dias
Metas, não garantias. Pedimos 90 dias antes da divulgação pública. Não há bug bounty em dinheiro; creditamos pesquisadores pelo nome, a pedido.
Sem prêmio em dinheiro; creditamos pesquisadores a pedido.
09
Políticas
Documentos legais
Cada documento que rege o serviço, com a data da versão atual. Mudanças relevantes nos Termos, na Política de Privacidade, no DPA e na Política de Uso Aceitável são anunciadas aos titulares de conta com ao menos 30 dias de antecedência.
Está fazendo uma avaliação de fornecedor? Conte-nos o que você precisa. Respondemos questionários por escrito e dizemos com clareza quando algo ainda não foi publicado.