Shahar Man, Co-fundador e CEO da Backslash Security – Série de Entrevistas

Shahar Man, co-fundador e CEO da Backslash Security, é um líder tecnológico experiente com profunda especialização em desenvolvimento de nuvem, cibersegurança e software empresarial. Atualmente, lidera a Backslash Security, uma empresa focada em proteger ambientes de desenvolvimento de software nativos em IA, protegendo tudo, desde IDEs e agentes de IA até código gerado e fluxos de trabalho de prompt. Anteriormente, ocupou cargos de liderança sênior na Aqua Security, onde atuou como vice-presidente de gerenciamento de produtos e vice-presidente de P&D, ajudando a construir uma das principais plataformas de segurança de contêineres ao longo do ciclo de desenvolvimento. No início de sua carreira, Man passou mais de uma década na SAP, onde liderou iniciativas de desenvolvimento e produtos, incluindo o SAP Web IDE, e trabalhou em estreita colaboração com clientes empresariais globais, ao mesmo tempo em que contribuía para o crescimento do ecossistema de desenvolvedores. Sua carreira começou em papéis técnicos e de liderança em ambientes de startup e unidades de tecnologia de defesa de Israel, dando-lhe uma forte base em engenharia e sistemas em larga escala.

Backslash Security é uma plataforma emergente de cibersegurança projetada especificamente para a era do desenvolvimento de software impulsionado por IA. A empresa se concentra em proteger toda a pilha de desenvolvimento nativa em IA, incluindo agentes de IA, pipelines de geração de código e fluxos de trabalho de desenvolvedores modernos, uma área frequentemente negligenciada por ferramentas de segurança tradicionais. Ao fornecer visibilidade, governança e proteção em tempo real sem interromper a velocidade dos desenvolvedores, a Backslash visa abordar os riscos crescentes introduzidos por ambientes de codificação automatizados e “vibe coding”. À medida que a criação de software se desloca cada vez mais para sistemas assistidos por IA, a plataforma é projetada para garantir que a segurança evolua em paralelo, em vez de se tornar um gargalo, posicionando a Backslash na interseção entre DevSecOps e desenvolvimento de IA de próxima geração.

Você ocupou cargos de liderança em produtos e P&D em empresas como Aqua Security e SAP antes de fundar a Backslash. Quais foram os primeiros sinais que o convenceram de que o desenvolvimento nativo em IA e o “vibe coding” iriam redefinir fundamentalmente a criação de software, e que a segurança precisava ser reconstruída para apoiá-lo?

Já havia vivenciado uma grande mudança quando o software se moveu para arquiteturas nativas em nuvem. Na SAP e, posteriormente, na Aqua, vimos de primeira mão que, quando o desenvolvimento muda tanto, a segurança geralmente fica para trás. A IA levou essa verdade a um novo nível, não apenas porque pode ajudar a escrever código mais rápido, mas porque começou a redefinir todo o ambiente ao redor da criação de software.

Proteger o código agora é menos sobre o código em si e mais sobre o ambiente ao seu redor. Em menos de um ano, o que costumava ser um conjunto de desenvolvimento relativamente contido e de baixo risco expandiu-se para uma superfície de ataque vasta e altamente conectada, com pouca supervisão ou governança. Uma vez que isso aconteceu, as questões de segurança em torno das vulnerabilidades do código mudaram completamente. A questão real não é se um determinado pedaço de código é vulnerável. A questão é que, ao permitir o desenvolvimento impulsionado por IA, introduzimos sistemas, agentes, integrações e caminhos de acesso que se estendem muito além do próprio código. A segurança não pode mais se concentrar apenas na saída do código. Ela precisa levar em conta todo o ambiente que torna esse código possível.

Você descreve o “vibe coding” como a expansão da superfície de ataque para além do código, incluindo prompts, agentes, servidores MCP e camadas de ferramentas. Quais são os riscos mais mal compreendidos nessa nova pilha que os desenvolvedores e as equipes de segurança estão atualmente ignorando?

O maior mal-entendido é que muitas equipes ainda pensam que o risco reside principalmente no código gerado. Isso é apenas uma camada. No desenvolvimento nativo em IA, o risco é introduzido mais cedo e em muitos mais lugares. Isso pode ser nos prompts, no contexto fornecido ao modelo, nas permissões concedidas aos agentes, nos servidores MCP aos quais se conectam, ou nas ferramentas e plugins externos que estendem seu alcance. Um laptop de um único usuário pode ser tomado e usado como um ponto de partida para um ataque mais amplo. É um ponto de dor de endpoint disfarçado de problema de codificação de IA. Ao contrário das vulnerabilidades de código, isso não coloca apenas as aplicações em risco – pode colocar toda a organização em risco. Se você está apenas olhando para o código, está perdendo a maior parte da imagem.

A segurança de aplicativos tradicional se concentrou fortemente na revisão de código. Como o pensamento de segurança precisa evoluir quando os agentes de IA estão gerando, modificando e implantando código em tempo real?

A segurança precisa mudar de inspeção periódica para supervisão contínua. A noção de confiança está completamente quebrada – você pode ter modelos confiáveis e servidores MCP confiáveis, mas devido à natureza não determinística da IA, eles ainda podem ser manipulados ou simplesmente se comportar mal para criar riscos inesperados.

Isso também significa que há uma mudança de mentalidade necessária, na qual a segurança opera ao lado do processo de desenvolvimento à medida que acontece e tem uma governança, guardrails e capacidades de detecção e resposta muito mais profundas dentro desse ambiente. Isso significa pensar criticamente sobre quais ferramentas estão sendo usadas, qual contexto elas estão consumindo, quais políticas devem governá-las e quais ações elas estão tomando em tempo real.

Além disso, não podemos ignorar o papel da IA e dos modelos de IA no tratamento de vulnerabilidades. Se um ano atrás os modelos de IA produziam muitas vulnerabilidades por padrão, as coisas melhoraram dramaticamente, e outros modelos agora são usados para encontrar zero days que nunca foram encontrados antes. Então, estamos nos dirigindo para melhores saídas – mas quem cuida da loja enquanto estamos fazendo isso? Os atacantes estão procurando em outro lugar.

Ferramentas como Cursor, Claude Code e GitHub Copilot estão se tornando padrão nos fluxos de trabalho dos desenvolvedores. Onde você vê as maiores lacunas de segurança quando as equipes adotam essas ferramentas sem uma camada de governança adequada?

A maior lacuna é a visibilidade. Em muitas organizações, essas ferramentas estão se espalhando rapidamente e sem uma revisão formal. As equipes de segurança frequentemente não sabem quais agentes estão sendo usados, como estão configurados, quais dados podem acessar ou quais sistemas externos estão conectados. Isso cria um problema de IA sombra, que é semelhante ao problema de TI sombra em princípio, apenas mais rápido e mais dinâmico.

A segunda maior lacuna é a falta de políticas aplicáveis. A maioria das organizações pode ter diretrizes, mas diretrizes sozinhas não ajudam muito quando um desenvolvedor está se movendo rapidamente dentro do IDE. Sem governança na camada de ferramentas e fluxos de trabalho, as equipes correm o risco de ter ferramentas superpermissivas que não atendem aos padrões empresariais. Essas ferramentas não são inerentemente más, mas adotá-las sem governança significa que você está efetivamente escalando a velocidade de desenvolvimento sem escalar o controle.

Uma terceira lacuna emergente é que qualquer pessoa pode potencialmente se tornar um desenvolvedor – o que chamamos de desenvolvedores cidadãos, usando ferramentas de codificação de vibe. Quando a pessoa de finanças usa o Claude Code para automatizar processos e se conectar a sistemas internos, isso cria um risco potencial e é um ponto cego enorme, mesmo hoje.

A Backslash se concentra em proteger todo o ecossistema de desenvolvimento de IA, em vez de ferramentas individuais. Por que essa abordagem de pilha completa é necessária, e o que acontece se as organizações continuam tratando esses riscos de forma isolada?

Porque o risco não reside apenas dentro de um produto específico na sua pilha. O desenvolvimento nativo em IA é inerentemente um problema de ecossistema, pois opera em muitos lugares diferentes, usando muitas ferramentas diferentes. O IDE, o modelo, os agentes, os servidores MCP, as ferramentas e plugins externos, as identidades e as fontes de dados conectadas todas influenciam o que é construído e como. As organizações não estão padronizando em uma única ferramenta porque suas forças relativas estão mudando tão rapidamente. Se você segura apenas um ponto naquela corrente, ainda perde como o risco se move pelo sistema.

Tratar esses riscos de forma isolada leva a defesas fragmentadas e pontos cegos perigosos. Você pode endurecer o scanner de código, mas ignorar o servidor MCP que alimentou contexto arriscado no modelo. É por isso que acreditamos que a abordagem certa é a visibilidade de pilha completa e proteção em tempo real em todo o ecossistema de desenvolvimento de IA. Caso contrário, as organizações continuarão resolvendo sintomas enquanto a superfície de ataque real continua se expandindo abaixo delas.

O prompting está surgindo como uma nova camada de programabilidade. Como as organizações devem abordar a segurança de prompts e prevenir problemas como injeção de prompt, vazamento de dados ou manipulação?

Os prompts cada vez mais moldam a lógica e o comportamento. Em muitos casos, eles são efetivamente um novo plano de controle para a criação de software. Isso significa que eles precisam de política, monitoramento e guardrails, assim como definições de código ou infraestrutura. Na prática, isso começa limitando o que os prompts podem acessar e quais ações downstream podem desencadear. Isso também significa definir regras de prompt que alinhem as expectativas de segurança e qualidade, prevenindo a exposição de dados sensíveis por meio de janelas de contexto, e vigiando tentativas de manipulação, como injeção de prompt ou hijack de instrução indireta. E também inclui garantir que as regras em si não sejam usadas como backdoors para injeção de prompt. O ponto mais amplo é que você não segura o prompting instruindo os desenvolvedores e agentes a “ter cuidado”. Você segura isso incorporando controles no ambiente onde o prompting realmente acontece.

Servidores MCP e habilidades de agente introduzem conexões dinâmicas entre sistemas. Do ponto de vista de segurança, esses representam o vetor de risco mais significativo no desenvolvimento impulsionado por IA?

Servidores MCP e habilidades de agente representam uma camada de risco significativa porque definem como os sistemas de IA se conectam e interagem com o mundo real. As habilidades definem o que um agente está autorizado a fazer, enquanto o MCP estende seu acesso a contexto e sistemas. Juntos, eles moldam o comportamento real do agente. Se essas camadas não forem controladas rigidamente, as organizações perdem a visibilidade do que suas ferramentas de IA são capazes de fazer e do que estão realmente fazendo. A mudança de geração de código para ação é o que torna essa área tão crítica para a segurança, e elas se tornam mais imprevisíveis quando você as encadeia.

Uma de suas principais temáticas é “ser o departamento do Sim” – permitir a segurança sem retardar os desenvolvedores. Como você equilibra a proteção em tempo real com a velocidade dos desenvolvedores em ambientes onde a velocidade é crítica?

A segurança cria fricção quando acontece tarde ou está desconectada de como os desenvolvedores realmente trabalham. Ela se torna muito mais eficaz quando está incorporada diretamente no fluxo de trabalho e focada no que realmente importa. Isso tem sido parte do nosso pensamento desde o início da Backslash, e importa ainda mais agora no desenvolvimento impulsionado por IA.

Na prática, isso significa apresentar os poucos problemas que representam risco real, não inundar os desenvolvedores com tudo o que parece teoricamente suspeito. Isso significa aplicar política no IDE e no fluxo de trabalho do agente, não após o fato. E isso significa criar guardrails transparentes e determinísticos, para que as equipes possam se mover rapidamente, sabendo quais ferramentas estão em uso, quais permissões elas têm e quando algo anormal está acontecendo. O objetivo não é retardar a adoção da IA, mas ajudar as organizações a adotá-la com confiança, sem perder o controle. Em termos reais, isso significa que um desenvolvedor teria menos espaço para cometer erros, mas se cometer um, ele será detectado e tratado rapidamente.

Estamos vendo usuários não técnicos construírem software cada vez mais usando ferramentas de IA. Como o surgimento de desenvolvedores de vibe não técnicos muda o cenário de ameaças?

Isso amplia o cenário de ameaças de duas maneiras. Primeiro, aumenta dramaticamente o número de pessoas que podem produzir saídas semelhantes a software sem entender as implicações de segurança. Segundo, cria uma falsa sensação de segurança porque as ferramentas tornam o desenvolvimento conversacional e de baixo atrito.

Isso significa que as organizações verão mais aplicações, automações e integrações criadas por pessoas que não são treinadas para considerar limites de confiança, validação de entrada, higiene de dependência, controle de acesso ou exposição de dados. Em outras palavras, a superfície de ataque se expande não apenas porque a IA escreve mais código, mas porque mais pessoas agora podem gerar fluxos de trabalho e sistemas que se comportam como software, sem aplicar a disciplina de engenharia básica. Isso torna a visibilidade e as salvaguardas incorporadas ainda mais importantes, porque você não pode mais supor conhecimento de segurança no ponto de criação.

Olhando para os próximos 12 a 24 meses, quais tipos de ataques ou vulnerabilidades você espera que surjam especificamente devido a fluxos de trabalho de desenvolvimento nativos em IA?

Esperamos que muitas das vulnerabilidades de código comuns sejam evitadas inicialmente por meio de melhorias nos próprios LLMs, ou por meio de regras de prompt incorporadas no “harness” que cerca essas ferramentas. Se agora estamos vendo um aumento no volume de vulnerabilidades apenas devido à velocidade aumentada, isso se corrigirá. E o que não for corrigido será perseguido por SAST e SCA habilitados por IA (alguns dos quais também serão fornecidos pelos próprios fornecedores de plataforma de IA, por exemplo, Claude Code Security e projeto Glasswing).

No entanto, espero resultados muito piores quando se trata de exposições devido ao uso de ferramentas de IA não verificadas e não supervisionadas no desenvolvimento de aplicações – como agentes de código aberto (OpenClaw é um bom exemplo), que têm configurações de segurança muito pobres, combinadas com uma base de usuários cujo conhecimento de segurança é muito superado por seu entusiasmo por codificação de vibe.

Como consequência, acredito que veremos uma mudança em direção a ataques que visam o ecossistema de desenvolvimento em si, em vez de apenas sistemas de produção. À medida que a IA se torna parte de como o software é criado, os atacantes se concentrarão em manipular as ferramentas e conexões que moldam esse processo, efetivamente comprometendo o software antes que ele seja implantado.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Backslash Security.