Adam Markowitz, CEO e cofundador da Drata – Série de entrevistas

Adam Markowitz é CEO e cofundador da Drata, onde está ampliando o trabalho da empresa em conformidade contínua e confiança para incluir a governança de agentes de IA. Antes de cofundar a Drata, em 2020, fundou a Portfolium com Troy Markowitz e Daniel Marashlian. Sua experiência com questionários de segurança, auditorias e análises de conformidade ajudou a moldar a abordagem da Drata para automatizar a forma como as organizações demonstram sua confiabilidade.

Drata oferece uma plataforma de governança, risco e conformidade que reúne coleta automatizada de evidências, monitoramento contínuo de controles, gestão de riscos de terceiros e fluxos de trabalho para questionários de segurança. Seus recursos de governança de agentes de IA se concentram em descobrir agentes, aplicar políticas antes da execução de ações e registrar decisões para fins de auditoria. Nesta entrevista, Markowitz fala sobre ameaças internas relacionadas a agentes, identidade de máquina, limites de segurança para chamadas de ferramentas e os controles necessários para que as empresas implementem agentes autônomos em escala.

Você fundou a Portfolium antes de cofundar a Drata, em 2020, depois de vivenciar em primeira mão como a conformidade de segurança podia se tornar complicada à medida que uma empresa crescia. O que levou você a acreditar que esse era um problema que valia a pena resolver criando uma empresa totalmente nova, e como a missão da Drata evoluiu à medida que a IA transformou o cenário da segurança?

Enquanto liderávamos a Portfolium, eu e meus cofundadores, Troy Markowitz e Daniel Marashlian, aprendemos uma lição valiosa: conquistar confiança nos negócios é um processo, não um discurso de vendas. Devido ao grande volume e à sensibilidade das informações dos estudantes, universidades e empresas não aceitavam trabalhar conosco até comprovarmos que estávamos fazendo o necessário para proteger os dados delas. Percebemos que enfrentar manualmente cada questionário de segurança, auditoria e análise de conformidade era uma tarefa lenta e penosa, vivida por muitas organizações. Depois que a Portfolium foi adquirida, Troy, Daniel e eu nos reunimos novamente e passamos seis meses desenvolvendo a primeira versão da Drata. Conversamos com dezenas de empresas e auditores para validar o problema antes mesmo de começar a escrever código. Quando lançamos o produto, chegamos a 100 clientes nas primeiras seis semanas e a 1.000 em um ano — o que nos mostrou que tínhamos passado de vender algo “bom de ter” para oferecer algo sem o qual as pessoas não conseguiam trabalhar.

Com a IA, a missão da Drata de oferecer confiança contínua não mudou, mas o alcance dessa confiança se ampliou. Começamos automatizando o trabalho árduo da conformidade e, depois, avançamos para fluxos de trabalho com agentes capazes de realizar avaliações de risco de terceiros e responder a questionários de segurança de ponta a ponta. Mas a verdadeira mudança ocorreu quando os próprios agentes passaram a precisar de governança. Agora, ampliamos a plataforma para viabilizar a governança de agentes de IA: descobrir os agentes, controlar o que eles podem fazer e produzir evidências que resistam ao escrutínio quando alguém as solicitar.

Você introduziu o termo “ameaça interna de agentes” para descrever riscos criados não por um invasor externo, mas pelos próprios agentes de IA de uma organização. O que diferencia uma ameaça interna de agentes da ameaça interna tradicional para a qual as equipes de segurança se preparam há décadas?

As ameaças internas tradicionais envolvem uma pessoa que usa indevidamente os acessos que já possui, como um funcionário insatisfeito, alguém descuidado ou alguém que simplesmente clica no lugar errado. Há décadas, as equipes de segurança vêm desenvolvendo programas para lidar com esse risco, com foco em verificações de antecedentes, privilégio mínimo, listas de verificação para desligamento de funcionários e medidas semelhantes.

A ameaça interna de agentes é diferente porque o agente nunca recebeu acesso. O risco deixa de ser o uso indevido e passa a ser a obtenção de acesso. Se um agente recebe um objetivo e o caminho óbvio para alcançá-lo está bloqueado, ele não abre um chamado e fica esperando, como uma pessoa faria. Tenta encontrar outra rota: uma conta de serviço com uma senha fraca ou um endpoint que alguém se esqueceu de fechar. Ele consegue entrar sem malícia nem consciência de que está violando uma política. Faz exatamente o que você pediu — e é isso que torna tão difícil detectá-lo. Cada etapa parece razoável quando analisada isoladamente, e, no fim, o agente informa que teve sucesso.

Já sabemos como governar funcionários e terceiros com acesso a sistemas confidenciais, mas os agentes constituem um terceiro grupo, e as ferramentas criadas para os dois primeiros não os abrangem.

Agentes de IA podem perseguir objetivos de forma persistente, operar à velocidade de máquinas e interagir com vários sistemas sem o discernimento que um funcionário humano poderia aplicar. Como isso muda fundamentalmente o modelo de ameaças das empresas?

Acima de tudo, isso muda o prazo. Uma pessoa que procura uma forma de entrar em um sistema acaba se entediando, sendo descoberta ou desistindo. Um agente não. Uma porta aberta que antes passava despercebida agora é encontrada, porque o agente não se cansa nem para de procurar.

E não se trata de uma única porta. Um agente criado para executar uma tarefa vai interagir sem hesitar com uma dúzia de sistemas para concluí-la — consultando o histórico de uma conta aqui, verificando um banco de dados ali —, embora a maior parte disso não tenha nada a ver com o que realmente lhe foi pedido. Ao preparar uma apresentação, ele pode passar pelos dados de outro cliente, registros financeiros, informações de funcionários ou qualquer outra coisa que encontre pelo caminho. Nada disso aparece como um incidente.

O modelo de ameaças, portanto, mudou. Hoje, a pergunta que uma equipe de segurança deve fazer é até onde seus próprios agentes irão para concluir uma tarefa se ninguém lhes disser onde parar.

Muitas organizações já contam com gerenciamento de identidade e acesso, gerenciamento de acesso privilegiado e arquiteturas de confiança zero. Por que esses controles não são suficientes, por si só, para governar agentes autônomos de IA?

Essas estruturas foram criadas para pessoas e fornecedores — dois grupos capazes de exercer julgamento e que param quando encontram um obstáculo. A identidade dos agentes exige o mesmo rigor aplicado às pessoas e ao risco de terceiros: descoberta, atribuição de responsáveis e comprovação que um auditor possa validar. A lacuna é que ainda não existe um padrão comum para definir o que significa, de fato, estar “sob governança” quando quem detém a credencial é um agente.

Por exemplo, um agente criado por um dos seus engenheiros pode agir com os acessos desse engenheiro — até mesmo em sistemas que ele nunca acessa pessoalmente. O IAM e o PAM partem do pressuposto de que quem detém a credencial sabe quando parar, mas os agentes não incorporam esse pressuposto.

As empresas devem começar a tratar cada agente de IA como uma identidade de máquina própria, com responsável, permissões, escopo e ciclo de vida claramente definidos? Como seria uma estrutura madura de gerenciamento de identidade para agentes?

Sim, mas a maioria das empresas ainda não chegou a esse ponto. Mais organizações do que se imagina nem sequer conseguem dizer quantos agentes estão em operação dentro de suas redes, muito menos quem é responsável por cada um. Uma estrutura madura começa pela descoberta: um inventário real e contínuo de todos os agentes. Depois, cada agente precisa ter um responsável, um escopo definido para determinar a que pode ter acesso e uma política que realmente imponha esse escopo. Com base em nossa própria pesquisa, observamos a mesma falha entre fornecedores: três em cada quatro organizações reavaliam seus terceiros apenas uma vez por ano ou com menos frequência. Assim, elas tomam decisões com base em dados que já estão desatualizados quando ocorre qualquer mudança. Avaliações pontuais não bastam para agentes, internos ou externos

Queremos um único padrão, aplicado da mesma forma a todos os agentes, em vez de a equipe de segurança ter de investigar o que cada desenvolvedor criou por conta própria. Isso significa políticas que possam ser redigidas em linguagem simples, testadas com base no tráfego histórico real antes de serem ativadas e, em seguida, aplicadas em linha, para que a estrutura esteja presente no fluxo de cada ação do agente, em vez de ficar apenas registrada na documentação.

Um cenário especialmente difícil é o de um agente que viola uma política de segurança sem agir de forma maliciosa. Se um agente encontra um caminho não previsto até dados confidenciais simplesmente porque está tentando concluir a tarefa que recebeu, como as equipes de segurança podem distinguir uma automação bem-sucedida de um incidente de segurança?

No momento, a resposta sincera é que não é possível. Imagine um agente de suporte criado para elaborar análises trimestrais de negócios e instruído a consultar o histórico da conta e montar a apresentação. O caminho previsto — a exportação que ele deveria consultar — retorna vazia. Uma pessoa pararia nesse ponto, mas o agente encontra outro caminho e, do seu ponto de vista, alcança o resultado esperado.

Embora a tarefa tenha sido concluída, o agente chegou ao resultado contornando os protocolos de segurança e acessando sistemas que não deveria abrir. A questão decisiva deve ser se o agente permaneceu dentro do escopo que definimos para ele. A questão nunca foi se o trabalho foi concluído. Essa é uma questão de política. Isso significa definir o escopo com precisão suficiente para que, depois do ocorrido, “automação bem-sucedida” e “incidente de segurança” não pareçam a mesma coisa.

O monitoramento de segurança tradicional costuma identificar atividades suspeitas depois que elas ocorrem, mas um agente autônomo pode concluir centenas de ações antes que uma pessoa consiga reagir. A IA agêntica exige controles de segurança que atuem diretamente no fluxo de execução, em vez de depender principalmente de alertas e monitoramento retrospectivo?

Sim, sem dúvida. Se você só detecta isso em tempo de execução, já é tarde demais. Quando uma ferramenta de monitoramento sinaliza a ação, ela já foi executada. Você terá um registro perfeito de como foi exposto, mas não poderá voltar atrás para impedir que isso aconteça.

O único tipo de governança eficaz para algo que opera na velocidade das máquinas é aquele que avalia a ação antes de sua execução e bloqueia a violação em linha. Nunca entregaríamos nossos dados mais confidenciais a um novo funcionário e simplesmente esperaríamos que o monitoramento detectasse qualquer problema. Os agentes merecem o mesmo rigor, no momento em que a ação está prestes a ocorrer. Não depois.

O Model Context Protocol (MCP) e outras interfaces entre agentes e ferramentas estão dando aos sistemas de IA acesso a recursos externos cada vez mais poderosos. Que novos limites de segurança precisam ser estabelecidos para chamadas de ferramentas, APIs, credenciais e contas de serviço à medida que as empresas ampliam o que permitem que seus agentes façam?

A chamada de ferramentas é o novo perímetro. Sempre que um agente tenta usar uma credencial, chama uma API ou invoca uma ferramenta, esse é um ponto de decisão; hoje, a maioria das empresas não tem nenhum limite nesse ponto exato para avaliar se a ação deve ser realizada. É isso que tem faltado. Vemos o mesmo ponto cego de fora para dentro: apenas 37% dos líderes de segurança têm confiança de que conseguem sequer identificar onde a IA está sendo executada nos fornecedores com os quais já trabalham. Se você não consegue ver isso no produto de um fornecedor, também não vai perceber qual será o próximo passo do seu próprio agente. As credenciais e contas de serviço por trás de tudo isso também precisam estar sujeitas ao mesmo rigor que aplicamos ao acesso humano: titularidade conhecida, escopo definido e revisões regulares. Um agente não deveria conseguir usar uma credencial que nunca lhe foi concedida só porque ela existe em algum lugar do seu caminho.

Quando um auditor, órgão regulador ou cliente pergunta a que dados um agente de IA teve acesso, que decisões tomou e para onde foram os dados resultantes, que nível de rastreabilidade as organizações deveriam ser capazes de fornecer, realisticamente? Os registros de auditoria de agentes poderiam, com o tempo, se tornar tão fundamentais quanto os registros tradicionais de acesso?

Quando solicitado, as organizações deveriam ser capazes de informar a que dados um agente teve acesso, que decisões tomou e para onde foram os dados resultantes. Não basta responder a essa pergunta tentando reconstruir os fatos a partir de registros depois que tudo aconteceu. O mínimo exigido é um registro contínuo e inviolável, já disponível quando a pergunta for feita. Neste momento, a maioria das empresas não tem resposta para essas perguntas. Não é uma lacuna que se possa justificar perante um cliente e, dependendo do que tiver vazado, tampouco será aceita pelos órgãos reguladores.

E sim, acredito que os registros de auditoria de agentes logo se tornarão tão fundamentais quanto os registros de acesso. Há anos, tratamos «quem acessou o quê e quando» como um requisito inegociável nos sistemas usados por pessoas. Não há motivo para exigir menos dos agentes só porque não foi uma pessoa que clicou. Estruturas como o EU AI Act, a AIUC-11 e a ISO 42001 já estão impulsionando essa mudança. A rastreabilidade dos agentes precisa se alinhar aos mesmos controles e critérios de evidência que já sustentam os programas de conformidade. Tratá-la como algo secundário é a maneira de deixá-la de lado.

Olhando para o futuro, você espera que a governança de agentes de IA se torne uma categoria de segurança distinta ou que acabe sendo incorporada às plataformas existentes de governança, risco, conformidade, identidade e cibersegurança? Na sua opinião, o que as empresas precisarão ter em vigor antes de poderem implantar com segurança agentes verdadeiramente autônomos em grande escala?

Cada grande onda tecnológica cria sua própria onda de segurança: a computação em nuvem deu origem à Wiz; os endpoints, à CrowdStrike; e agora a IA está dando origem a uma nova onda. Os provedores de modelos estão criando consoles e políticas para suas próprias plataformas, o que é útil, mas nenhuma empresa usa apenas um provedor de modelos, um assistente de programação e um conjunto de agentes desenvolvidos internamente. É preciso que alguém governe tudo isso com um único conjunto de políticas e uma única fonte de evidências, e nenhuma plataforma de IA isolada foi criada para resolver esse problema. Essa não é a finalidade delas. A governança de agentes de IA já é uma categoria própria, embora se integre aos sistemas de GRC, identidade e conformidade que as empresas já utilizam.

Antes de implantar agentes verdadeiramente autônomos em grande escala, as empresas precisam ter quatro elementos em vigor, e a maioria ainda não tem nenhum deles. O primeiro é a descoberta em tempo real: saber, no momento em que cada agente é criado, quais agentes estão em execução, quem é responsável por eles e com que identidade operam.

O segundo é a aplicação de políticas em linha, com avaliação antes da execução de uma ação. Em terceiro lugar, as empresas precisam monitorar continuamente possíveis desvios, pois os agentes continuam existindo mesmo depois da sessão que os criou, e seu escopo pode se ampliar sem que ninguém perceba. Por fim, é necessário um registro inviolável de cada decisão tomada por um agente, alinhado às estruturas reconhecidas por auditores e órgãos reguladores. É essa camada que estamos desenvolvendo na Drata. Sem ela, uma empresa que implanta agentes autônomos em grande escala está simplesmente confiando na sorte.

Obrigado pela ótima entrevista. Os leitores que quiserem conhecer melhor a governança de agentes de IA, a conformidade contínua e os controles contra ameaças internas relacionadas a agentes podem acessar Drata.