Turnkey lança Managed Secrets para acesso de agentes de IA a credenciais

Turnkey lançou o Managed Secrets, ampliando sua infraestrutura de carteiras digitais baseada em enclaves para incluir chaves de API, senhas, dados de pagamento e informações de recuperação de que aplicativos e agentes de IA precisam para operar. O anúncio de 29 de outubro leva a empresa além do gerenciamento de chaves privadas e aborda um problema mais amplo: dar aos softwares autoridade para agir sem espalhar credenciais reutilizáveis por toda a infraestrutura.

O produto permite que as equipes decidam quais serviços podem obter uma credencial e se a solicitação exige aprovação humana ou de várias partes. Em aplicativos financeiros, isso pode significar liberar uma chave de API de uma corretora para um sistema autorizado de execução de operações, mantendo-a fora da conversa e do ambiente de execução de um assistente de IA.

Deslocamento do acesso a credenciais para dentro dos limites de um enclave

Credenciais armazenadas em variáveis de ambiente ou arquivos de configuração são convenientes para uso por softwares, mas uma invasão do processo que as lê pode expor seu conteúdo. Um cofre pode centralizar o armazenamento e os controles de acesso; a questão que resta é onde uma credencial se torna legível e em quais sistemas é preciso confiar nesse momento.

O Managed Secrets realiza as verificações de autorização dentro dos enclaves seguros da Turnkey. Antes de importar um segredo, o cliente o criptografa, e o enclave volta a criptografá-lo para armazenamento. Quando chega uma solicitação, o enclave avalia as políticas e aprovações pertinentes antes de criptografar o resultado para a chave do destinatário pretendido. O solicitante e o destinatário podem ser serviços diferentes.

Essa separação é importante. Um aplicativo pode iniciar uma tarefa e obter aprovações sem adquirir a capacidade de descriptografar a credencial usada para concluí-la. A assinatura de um aprovador autoriza a liberação; ela não concede automaticamente acesso ao segredo liberado.

A criptografia por trás da importação e da exportação

A documentação do canal seguro da Turnkey descreve um protocolo baseado em Criptografia Híbrida de Chave Pública, ou HPKE. Ele combina o acordo de chaves de chave pública com a criptografia autenticada para que informações confidenciais possam atravessar sistemas intermediários na forma de texto cifrado. Durante a importação, o cliente verifica o material de chave assinado pelo enclave; na exportação, os dados são criptografados para uma chave pública fornecida na solicitação assinada.

As chaves dos destinatários destinam-se a uso único. A Turnkey observa que os próprios clientes precisam respeitar essa regra: o protocolo não consegue impedir que um cliente com falhas reutilize a chave de destino. Assim, a implementação do cliente, junto com o enclave, passa a fazer parte do modelo de segurança.

A página do produto Managed Secrets especifica criptografia AES-256-GCM de cada segredo em repouso. A API oferece suporte tanto a credenciais individuais quanto a solicitações de vários segredos. As exportações em lote falham por completo se algum dos segredos solicitados não tiver autorização, impedindo a liberação de um pacote parcialmente aprovado.

Por que o destinatário continua sendo importante

A expressão “agentes podem usar credenciais sem vê-las” descreve um padrão de integração, e não uma garantia de que todos os processos que recebem essas credenciais continuarão sem poder ler o texto simples. A documentação para desenvolvedores da Turnkey afirma explicitamente que o texto simples pode existir dentro do enclave e no cliente que importa ou exporta um segredo.

Se um serviço de execução separado detiver a chave do destinatário, poderá descriptografar e usar uma credencial sem que ela chegue ao modelo. Se essa chave estiver no próprio ambiente de execução do agente, esse ambiente poderá descriptografá-la. Portanto, continua sendo necessário proteger o destinatário, sua memória e seus registros.

Há um segundo limite: as políticas podem analisar o contexto da solicitação, como o domínio de checkout informado, mas a Turnkey não verifica de forma independente se essa informação é verdadeira. Uma declaração assinada identifica quem a fez. Os aplicativos ainda precisam de verificações confiáveis que vinculem essa declaração à operação real.

Aprovações que podem evoluir com o fluxo de trabalho

As equipes podem permitir o acesso direto, exigir que uma pessoa aprove uma solicitação ou exigir o acordo entre várias funções de agente. As políticas podem ser alteradas sem que seja necessário importar o segredo novamente, permitindo que um fluxo de trabalho comece sob supervisão rigorosa e, mais tarde, automatize solicitações específicas.

O guia de acesso programável da Turnkey mostra um agente de navegador e um agente de pagamento assinando juntos uma solicitação. Somente o agente de pagamento recebe os dados do cartão em formato descriptografável. Antes de aprovar, o componente de navegador verifica se o domínio proposto corresponde à página que está usando. O exemplo mostra por que funções independentes e validação são mais importantes do que simplesmente contar duas aprovações.

As funções dos agentes podem usar credenciais de sessão com escopo limitado e prazo de validade, permitindo que os operadores revoguem uma instância em execução. No entanto, revogar o acesso futuro não apaga um segredo que o destinatário já tenha descriptografado; a rotação das credenciais subsequentes continua sendo um controle operacional separado.

Da infraestrutura de carteiras digitais à automação financeira

A arquitetura de segurança já existente da Turnkey usa AWS Nitro Enclaves e combina isolamento por hardware com compilações reproduzíveis e atestação remota. A reprodutibilidade permite comparar compilações de software, enquanto a atestação fornece evidências sobre o código em execução no enclave. O Managed Secrets estende essa base a credenciais que vão além das chaves de assinatura de blockchain.

A empresa aponta empresas de negociação, sistemas de back-end de fintechs, desenvolvedores de agentes de IA e custodiantes de MPC como usuários potenciais. Credenciais de exchanges e tokens OAuth permitem o acesso contínuo aos serviços; backups de partes de chaves e chaves de recuperação atendem às necessidades de resiliência. São usos distintos, com diferentes requisitos de aprovação e de destinatários, mesmo quando compartilham a infraestrutura de armazenamento.

Para as equipes de tecnologia financeira, a importância está em separar com mais clareza a solicitação de uma ação, a autorização do acesso e o recebimento de uma credencial utilizável. O Managed Secrets fornece a infraestrutura necessária para essa separação. A proteção resultante depende de políticas restritivas, aprovadores confiáveis e um serviço bem protegido que, em última instância, utiliza o segredo.