Micha Rave, CEO e Co-Fundador da Hush Security – Série de Entrevistas

Micha Rave, CEO e cofundador da Hush Security, é um executivo experiente em cibersegurança e tecnologia, cuja carreira abrange engenharia de software, gerenciamento de produto, redes corporativas, segurança em nuvem e identidade. Antes de cofundar a Hush Security em 2024, passou mais de cinco anos na Proofpoint como Diretor Sênior de Gerenciamento de Produto para Segurança em Nuvem, onde era responsável pelas linhas de produto Zero Trust Network Access (ZTNA) e Secure Web Gateway (SWG). Anteriormente, atuou como VP de Gerenciamento de Produto na Meta Networks, focado em redes corporativas e segurança, e ocupou cargos de liderança em produto e engenharia na HARMAN International, Redbend, SanDisk, Hola, Jungo e Elbit Systems. Seu histórico combina desenvolvimento prático de software com mais de duas décadas de experiência na construção e comercialização de produtos de segurança, redes, virtualização e tecnologia embarcada.

Hush Security é uma empresa de cibersegurança focada em proteger agentes de IA e outras identidades não humanas, substituindo credenciais de longa duração e segredos estáticos por acesso baseado em identidade e controlado por políticas. Sua plataforma descobre agentes de IA, incluindo agentes sombra e desenvolvidos internamente, atribui-lhes identidades verificáveis e governa suas interações com sistemas corporativos usando permissões de escopo, concedidas just-in-time, políticas centralizadas e registros de atividade auditáveis. A empresa foi fundada por veteranos de segurança da equipe por trás da Meta Networks, que a Proofpoint adquiriu em 2019. Em julho de 2026, a Hush arrecadou US$ 30 milhões em uma rodada Series A, com a Akamai Technologies entrando como investidora estratégica ao lado da Battery Ventures e da YL Ventures, elevando o financiamento total para US$ 41 milhões enquanto a empresa expande sua tecnologia para governar agentes de IA corporativos e infraestrutura não humana.

Antes de fundar a Hush Security, você passou anos desenvolvendo e liderando produtos de segurança, incluindo segurança em nuvem na Proofpoint. O que você observou no mercado que o convenceu de que havia necessidade de criar a Hush, e como essa tese original evoluiu com a rápida ascensão da IA agente?

Na Proofpoint, observamos as empresas resolverem a identidade humana enquanto tudo o que não era humano ainda operava com segredos estáticos. Contas de serviço, cargas de trabalho, pipelines, todos autenticando com chaves que ninguém possuía e que nunca expiravam. A indústria respondeu com cofres melhores. Isso é um cofre melhor, não uma solução.

A tese fundadora era mover o acesso não humano de segredos para identidade. Identidade verificável de cargas de trabalho, credenciais de curta duração emitidas just-in-time, políticas aplicadas inline. Sem reescritas de código.

A IA agente tornou isso urgente. Um agente é um NHI que raciocina e decide em tempo de execução quais ferramentas chamar. Se você lhe der uma chave estática, concedeu ao software autônomo acesso permanente à produção, e os agentes são implantados fora de qualquer processo de mudança; um desenvolvedor configura um servidor MCP na terça‑feira e já está acessando dados de clientes na sexta‑feira.

A tese não mudou. O escopo mudou. O acesso baseado em identidade era a resposta correta para workloads. Para agentes, é a única viável: conhecer cada agente que existe, conceder a cada um a menor agência por padrão e auditar cada ação. Humanos receberam um IdP. Agentes também precisam de um, e essa é a Hush.

A Hush argumenta que agentes de IA corporativos devem ter suas próprias identidades e permissões delegadas, em vez de simplesmente herdar os direitos de acesso dos humanos que os utilizam. Por que os sistemas tradicionais de Identity and Access Management (IAM) têm dificuldades com agentes autônomos, e o que precisa mudar?

O caso óbvio é um agente atuando para um usuário. O caso mais complexo é um agente sem nenhum usuário: um job agendado, um respondedor SOC autônomo, um pipeline que raciocina e age por conta própria. Não há ninguém de quem delegar, então as equipes recorrem à única ferramenta que têm, uma conta de serviço estática com permissões amplas e uma chave que nunca expira. Esse é o mesmo modelo de segredo compartilhado que vem falhando há uma década, agora ligado a um software que improvisa.

Os sistemas do outro lado pioram a situação. A maioria das APIs internas, bancos de dados e servidores MCP não realizam autorização real. Eles verificam se você possui um token válido, não o que você está autorizado a fazer com ele. Posse equivale a permissão.

O que precisa mudar: cada agente recebe sua própria identidade, emitida criptograficamente, independentemente de haver ou não um humano por trás dele. O acesso é concedido por ação, de curta duração e com escopo, com políticas aplicadas inline em vez de confiar no sistema de destino. Quando há um usuário, as permissões do agente são a interseção entre o que o usuário pode fazer e o que esse agente está autorizado a fazer para aquela tarefa. Quando não há, a identidade e a política próprias do agente contam toda a história. Humanos obtiveram o princípio do menor privilégio. Agentes precisam do princípio da menor agência.

Você utiliza o conceito de “menor agência” ao discutir a segurança de IA. Como a menor agência difere do tradicional princípio de cibersegurança do menor privilégio, e como as organizações podem determinar exatamente o que um agente de IA deve ser autorizado a fazer para uma tarefa específica?

Os agentes não têm comportamento fixo. Conceder a um agente acesso de leitura a um CRM e acesso de escrita ao e‑mail não significa que você concedeu duas permissões; você concedeu todo o caminho entre elas. O menor privilégio delimita o que um agente pode tocar. Não diz nada sobre o que ele deve fazer com isso.

Least agency adiciona a dimensão que falta: quais ações, para qual tarefa, agora. Um agente que triage tickets precisa ler e comentar. Não precisa fechar, excluir ou tocar a cobrança, mesmo que o token permita. Quando a tarefa termina, o acesso termina.

Decidir o que é permitido começa com observação, não com suposições. Execute o agente, observe o que ele realmente chama e deixe isso definir a linha de base. Em seguida, restrinja usando três entradas: a tarefa para a qual ele existe, o usuário para quem ele age (nunca mais do que esse usuário poderia fazer) e o raio de explosão de cada ação, porque publicar um comentário e processar um pagamento não deveriam compartilhar um caminho de aprovação.

O princípio do menor privilégio decide quem recebe as chaves. O princípio da menor agência decide o que eles podem fazer uma vez dentro.

Frequentemente “emprestamos” nossa identidade ao agente, mas não queremos que o agente tenha o mesmo nível de permissões que nós — essa é a definição de menor agência.

A Hush levantou recentemente um Série A de 30 milhões de dólares, elevando o financiamento total para $41 million, com a Akamai entrando como investidora estratégica ao lado da Battery Ventures e da YL Ventures. O que a participação da Akamai traz além de capital, e como você espera que a parceria influencie a expansão da Hush na segurança de agentes de IA corporativos?

A Akamai está no caminho de tráfego da maioria das empresas globais, e é exatamente onde a segurança de agentes precisa estar. Você não governa um agente a partir de um painel depois do fato. Você o governa inline, no momento em que ele chama uma ferramenta ou API. A Akamai construiu seu negócio nesse modelo.

Além do capital, eles trazem três coisas: distribuição para CISOs que já perguntam como controlar agentes e o tráfego MCP; validação de que a identidade do agente é uma categoria real, não apenas um recurso; e décadas de experiência em proteger tráfego máquina‑a‑máquina em escala global, que é o que o tráfego agente‑para‑ferramenta está prestes a se tornar.

Model Context Protocol (MCP) está se tornando rapidamente uma camada importante para conectar agentes de IA a ferramentas e dados corporativos. De uma perspectiva de segurança, quais novos riscos o MCP introduz e como as organizações devem pensar sobre identidade e autorização entre o agente, o servidor MCP e o recurso subjacente?

O MCP tornou trivial conectar um agente a uma ferramenta. Esse é o risco. Um desenvolvedor adiciona um servidor a um arquivo de configuração e o modelo pode agora ler o Jira, consultar um banco de dados ou enviar e‑mail. Sem revisão, sem inventário, sem política. A segurança só descobre quando algo quebra.

Existem três novos problemas agora:

1. Shadow MCP – ninguém sabe quantos servidores estão em execução ou o que eles acessam.
2. Dispersão de credenciais – a maioria dos servidores autentica com um token estático que concede todo o escopo, de modo que o agente obtém tudo o que o token pode fazer.
3. A cadeia colapsada – o recurso vê apenas a credencial do servidor MCP, portanto não consegue identificar qual agente, agindo em nome de qual usuário, fez a chamada. A identidade precisa estar na base de cada interação, o acesso deve ser efêmero, limitado e baseado nas permissões do agente e do usuário.

A Hush foi originalmente construída em torno da ideia de que segredos estáticos e credenciais de longa duração são uma base quebrada para acesso de máquinas. Como a maioria das infraestruturas corporativas ainda depende fortemente de chaves de API, tokens e outros segredos, como as empresas podem avançar realisticamente para acesso baseado em identidade, de curta duração, sem reconstruir todo o seu stack tecnológico?

Você não reconstrói. Quem diz o contrário nunca encontrou uma empresa. A maior parte do que protegemos antecede a expressão identidade não humana, e não está sendo reescrita.

Portanto, não pedimos isso. A Hush é implantada sem alterações de código e fica no caminho de acesso. O primeiro passo é a descoberta: cada segredo, quem o usa, o que ele alcança, o que realmente faz em tempo de execução. A maioria das empresas nunca viu esse panorama.

Então é uma jornada, não uma migração. A descoberta mostra quais segredos estão obsoletos, superespecificados ou de maior risco. Corrija esses primeiro. Em seguida, troque chaves estáticas por credenciais de curta duração emitidas por identidade, um sistema de cada vez. O aplicativo ainda pensa que está usando uma chave. A chave simplesmente deixa de ser de longa duração, e a política passa a ser nossa.

O mesmo modelo cobre um serviço Java de quinze anos e um servidor MCP instalado na semana passada. Comece onde o risco está, prove, continue.

Os agentes de IA trabalharão cada vez mais em nome de humanos e, em muitos casos, delegarão tarefas a outros agentes. À medida que esses fluxos de trabalho multi‑agente se tornam mais complexos, como você mantém uma cadeia clara de identidade, autorização, propriedade e responsabilidade para cada ação que ocorre?

O modo de falha: um usuário solicita a um orquestrador, que delega a um segundo agente, que chama uma ferramenta através de um servidor MCP, que acessa um banco de dados com uma conta de serviço. Quatro saltos depois, o log mostra apenas um token válido. Quem solicitou, quem decidiu e quem é responsável desaparecem.

A solução é recusar que a identidade colapse em qualquer salto. Cada agente tem sua própria identidade criptográfica. Quando delega, não entrega seu token. Emite uma delegação limitada: este sub‑agente, esta tarefa, estas ações, em nome deste usuário. Cada salto transporta a cadeia completa e suas próprias permissões.

A responsabilidade vem da aplicação e registro em linha, no ponto de ação. O registro do gateway do que lhe foi permitido fazer, o que chamou e a cadeia por trás disso.

Os sistemas multiagente se tornarão mais difíceis de compreender. A cadeia de custódia de cada ação não precisa ser.

Injeção de prompt e outros ataques podem potencialmente manipular um agente de IA aparentemente legítimo a executar ações que seu operador nunca pretendia. Até que ponto os controles de acesso baseados em identidade podem limitar os danos de um agente comprometido ou manipulado, mesmo quando o modelo de IA subjacente se comporta incorretamente?

Você não impedirá a injeção de prompt no modelo. Os modelos leem conteúdo não confiável por design. Presuma que o agente acabará sendo induzido a algo errado. A questão é o que ele pode fazer quando isso ocorre.

O acesso baseado em identidade delimita o raio de impacto. Um agente manipulado com mínima agência só pode usar indevidamente as ações que lhe foram concedidas para aquela tarefa. Se ele pode ler tickets e postar comentários, nenhuma injeção o fará exfiltrar o banco de dados do cliente. O token não tem esse alcance.

A atribuição de usuário mantém a cadeia intacta: qual usuário, qual agente, qual tarefa, em cada chamada. O agente nunca excede o que o usuário poderia fazer, e cada ação pode ser rastreada.

A detecção de anomalias captura o que a política permite, mas a intenção não. Um agente que normalmente lê cinco registros e de repente extrai cinco mil está fora do padrão, mesmo que cada chamada seja autorizada. Como o gateway está em linha e conhece a linha de base, ele pode sinalizar ou bloquear isso em tempo real.

O modelo estará errado às vezes. Identidade delimitada, atribuição e linhas de base comportamentais tornam o erro tolerável.

A Hush tem foco principal em proteger IA, mas como vocês utilizam IA dentro da própria Hush? Existem áreas como descoberta de identidades não humanas, análise de padrões de acesso, priorização de risco ou aplicação de políticas onde a IA pode melhorar materialmente a plataforma de segurança?

Nós a usamos onde quer que ela mereça estar.

No produto, a parte difícil não é encontrar segredos, mas compreendê‑los. Uma chave aparece no tráfego. Identidade de carga de trabalho, integração de fornecedor, token de teste de desenvolvimento, credencial obsoleta? Um LLM lê o contexto de tempo de execução e os sinais do proprietário e propõe uma resposta com uma pontuação de confiança. Ele resume o que uma identidade realmente faz em linguagem humana simples, de modo que a política seja uma que um humano aprovará. Ele classifica o risco pelo alcance real e pelo raio de impacto, não pela gravidade estática. A aplicação permanece determinística. A IA ajuda a escrever a política – ela não recebe voto em tempo de execução.

Dentro da Hush, a programação agente mudou nosso ritmo. Funcionalidades que levavam um sprint agora levam dias, e entregamos integrações em um ritmo que uma equipe Series A não poderia pagar de outra forma. LLMs triagem tickets de suporte, agrupam causas raiz e destacam solicitações de clientes para discussões de roadmap. Nosso próprio gateway MCP fica à frente de tudo isso, ajudando nossos clientes a raciocinar e consumir NHI e risco agente.

A Hush afirma que várias empresas da Fortune 500 já utilizam sua tecnologia, enquanto a Kyndryl implantou a Hush internamente e começou a revender para clientes corporativos. O que vocês estão aprendendo com essas implantações em larga escala sobre os problemas de governança do mundo real que as empresas enfrentam quando agentes de IA passam da experimentação para a produção?

Ninguém sabe o que tem. Toda grande implantação começa da mesma forma: a segurança pensa que há uma dúzia de agentes em produção, a descoberta encontra centenas, já acessando dados de clientes. O problema de governança não é a política, é o inventário primeiro.

As credenciais são piores que os agentes. Quase todo agente de produção roda em uma conta de serviço estática que o antecede, com permissões acumuladas ao longo de anos para outra finalidade. Ela não recebeu acesso delimitado.

A propriedade está ausente. Pergunte quem é responsável por um agente, ou por um NHI, e você obtém no máximo o nome de uma equipe, um contratado que já saiu, ou silêncio.

E o comprador mudou. Isso era um problema da equipe de plataforma. Agora o CISO o possui porque a diretoria está exigindo. Isso nos levou de pilotos a implantações corporativas, e é o motivo pelo qual a Kyndryl implantou internamente antes de revender.

Os agentes não criaram novos problemas de governança. Eles pegaram os que as empresas ignoraram por uma década com contas de serviço e os agravaram muito.

Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar Hush Security.