Engenharia de software na era da IA: segurança de aplicações com agentes, MCPs e código gerado por IA

Introdução à segurança de IA - Apresentação

Apresentando o instrutor e o curso

Olá a todos. Bem-vindos ao curso de uso seguro de inteligência artificial no desenvolvimento de software. Sou Ben-Hur Santos Ott e trabalho há quase duas décadas na área de desenvolvimento de software. Passei parte do meu tempo como desenvolvedor front-end, back-end e mobile. Já atuei em todas as áreas de tecnologia. Dedico praticamente a última década à segurança no desenvolvimento de software. Trabalhei em algumas grandes empresas de tecnologia na Internet. Atualmente, trabalho na SNIC, que é a maior empresa de segurança no desenvolvimento de software do mundo e na adoção segura de inteligência artificial para o desenvolvimento de sistemas. Espero poder compartilhar um pouco do meu conhecimento e tudo o que aprendi na área até o momento com vocês, para que possamos aprender juntos durante este curso.

Destacando a importância do curso

Se você é uma pessoa desenvolvedora que está trabalhando com IA atualmente, pretende adotar Spec Driven Development, pretende utilizá-la de forma autônoma para desenvolver suas aplicações ou está realmente começando a entrar neste mundo de inteligência artificial no desenvolvimento de software, este curso é obrigatório para você. Porque tudo parece muito bonito no papel. Vamos definir que nossas soluções vão usar LLMs, Skills, vamos utilizar bibliotecas por todos os lados, mas quais são os riscos que corremos quando começamos a utilizar esses componentes? Será que precisamos nos preocupar com a segurança das bibliotecas que estamos usando? Será que o código que a IA gera é seguro ou não? Será que se colocarmos um LLM que não conhecemos ou usarmos uma Skill que não conhecemos, quais são os riscos que corremos? Então, tudo isso é importante conhecer para saber identificar os riscos e nos proteger deles.

Abordando conceitos de segurança e riscos

Neste curso, vamos abordar inicialmente os conceitos gerais de segurança que precisamos compreender. Discutiremos a importância da segurança no contexto atual. Em seguida, aprenderemos sobre ataques, riscos e vulnerabilidades observados no setor de desenvolvimento de software, especialmente quando falamos de IA aplicada a esse desenvolvimento.

Explorando proteções e mitigações

Posteriormente, exploraremos as proteções e mitigações, mas ao longo do curso, aprenderemos como atacar e como nos defender dos principais riscos associados à IA no desenvolvimento de software. É importante entender que, ao executar um software ou uma aplicação, a mesma entrada sempre gera a mesma saída, caracterizando um comportamento determinista. No entanto, a IA não é determinista, mas sim probabilística. Isso significa que, ao lançar um agente, ele pode gerar um código de uma forma, e ao repetir o mesmo prompt, o resultado pode ser diferente. Se fizermos outra pergunta, o resultado será gerado de outra maneira.

Utilizando exemplos e modelos no curso

Utilizaremos muitos exemplos ao longo do curso, mas não devemos nos frustrar se, ao tentar com um agente e um modelo, o resultado for um pouco diferente. Outro agente ou modelo pode apresentar um resultado ainda mais distinto. Essa é a natureza da IA, o que a torna fascinante e destaca a importância da segurança nesse campo, devido à sua imprevisibilidade.

Realizando provas e discutindo ataques

Realizaremos algumas provas utilizando modelos comerciais, como Cloud e Antigravity com Gemini, além de exemplos que utilizarão OLAMA, modelos locais que executaremos em nossa máquina. Convidamos a prestar muita atenção ao curso, pois discutiremos os principais ataques observados na indústria, como eles funcionam na prática e como podemos nos defender de maneira mais eficaz nesse mundo atual.

Introdução à segurança de IA - Revisando conceitos pela lente de segurança

Introduzindo conceitos de segurança em agentes de IA

Olá, neste vídeo vamos entender e revisar alguns conceitos que já vimos ao longo do curso sobre agentes, MCPs, skills (habilidades), mas a partir de outra perspectiva. Quando falamos sobre segurança no ecossistema de agentes de IA, especialmente ao usarmos agentes para desenvolver software, temos preocupações distintas em comparação ao desenvolvimento de produtos que são agentes de IA. Precisamos observar esses mesmos recursos, MCPs, skills (habilidades), modelos, com uma visão diferente.

Revisando um pouco o que já vimos, qual é o uso atual? Primeiro, temos a IDE ou a CLI, que normalmente é nosso ponto principal ao usar agentes de IA para desenvolver, pois utilizamos algum deles para gerar nosso código. Podemos usar uma IDE com um agente de IA integrado ou alguma ferramenta de linha de comandos, como Cloud Code, Gemini, a CLI, entre outras. Dentro de uma dessas opções, teremos de fato nosso agente de IA. Esse agente pode ser o Cloud Code na linha de comandos ou, por exemplo, o Cloud Code dentro do VS Code como um plugin. Algumas IDEs já trazem isso de forma nativa, como PyCharm, IntelliJ, Eclipse, entre outras. Além disso, temos um agente; isso é importante. Dentro desse agente, ele vai interagir com uma série de elementos. Ele interage com um modelo, com MCPs, e possui skills (habilidades) para executar ou completar alguma tarefa ou algo do tipo. Alguns agentes têm características diferentes, como hooks, que permitem definir o que é executado e quando. Por exemplo, o PyCharm possui o Steering. Temos diferentes modos, como o modo Plan, o modo Agent, o modo Ask, entre outros. Até aqui, nada novo, provavelmente já vimos isso.

Explorando a criação de componentes e suas implicações

Agora, vamos entender um conceito muito importante, uma prerrogativa essencial para falar da segurança disso. Tudo o que estamos vendo aqui — IDE, CLI, o agente, o modelo, os MCPs, as skills (habilidades) e os hooks — podemos desenvolver nós mesmos, mas normalmente não o fazemos. Na maioria dos casos, são componentes de terceiros. Ou seja, a IDE não é desenvolvida por nós, a linha de comandos não é desenvolvida por nós, o agente não é desenvolvido por nós. "Ah, mas eu desenvolvi meu agente com o SDK do Cloud Code." Bem, você integrou um SDK. Então, o SDK não foi desenvolvido por você na maioria dos casos. O modelo que normalmente usamos não é treinado por nós desde o início. Usamos algum modelo já pronto. Os MCPs podemos construir os nossos; não é tão difícil de fazer, mas geralmente são compostos por código e bibliotecas de terceiros. O próprio FastMCP é uma biblioteca de terceiros. As skills (habilidades), podemos construir as nossas. É bastante gratificante construí-las. No entanto, muitas vezes também usaremos skills (habilidades) de terceiros. E os hooks são simplesmente uma funcionalidade que podemos implementar.

Para ilustrar como podemos criar um MCP, vamos ver um exemplo de código que cria um servidor MCP simples que expõe uma ferramenta de calculadora e alguns dados:

# Vamos criar um servidor MCP simples que expõe uma ferramenta de calculadora e alguns dados.

# Exemplo de início rápido do FastMCP.
#
# Execute a partir da raiz do repositório:
# uv run examples/snippets/servers/fastmcp_quickstart.py

from mcp.server.fastmcp import FastMCP

# Crie um servidor MCP
mcp = FastMCP("demo", json_response=True)

# Adicione uma ferramenta de adição
@mcp.tool()
def add(a: int, b: int) -> int:
    """Adiciona dois números"""
    return a + b

# Adicione um recurso de saudação dinâmica
@mcp.resource("greeting:/{name}")
def get_greeting(name: str) -> str:
    """Obtenha uma saudação personalizada"""
    return f"Hello, {name}!"

# Adicione um prompt
@mcp.prompt()
def greet_user(name: str, style: str = "friendly") -> str:
    """Gera um prompt de saudação"""
    styles = {
        "friendly": "Please write a warm, friendly greeting",
        "formal": "Please write a formal, professional greeting",
        "casual": "Please write a casual, relaxed greeting",
    }

    return f"{styles.get(style, styles['friendly'])} for someone named {name}."

# Execute com transporte HTTP transmissível
if __name__ == "__main__":
    mcp.run(transport="streamable-http")

Esse exemplo demonstra como podemos configurar um servidor MCP que oferece funcionalidades básicas, como uma calculadora e saudações personalizadas, utilizando a biblioteca FastMCP.

Avaliando riscos e segurança em ferramentas de terceiros

Tudo isso faz parte do conjunto de ferramentas com as quais trabalharemos para desenvolver nosso software. Mas, como são ferramentas de terceiros, podem ter vulnerabilidades ou até mesmo serem maliciosas, projetadas ou criadas para instalar ou executar malware. Precisamos ter algumas precauções adicionais e olhar para isso de outras perspectivas. Por exemplo, falando um pouco do agente. O agente pode ser um plugin da IDE. Mas você vai instalar, por exemplo, um Cloud Code Free como plugin na sua IDE? Isso não me parece suspeito. E você conhece o desenvolvedor, quem o fez ou algo assim? Isso representa um risco tanto para nós, como pessoas desenvolvedoras, quanto para a empresa em que trabalhamos. Vamos analisar cada uma dessas partes em detalhe.

Da mesma forma, os modelos. Quando queremos executar um modelo local, muitas vezes executamos um modelo cooperativo, como o da própria Cloud da Google. Mas podemos optar por outro modelo. Um modelo gratuito, de código aberto, executando localmente, como o Llama, por exemplo.

Segurança e riscos em modelos de linguagem

Conhecemos esses modelos? Sabemos quem os desenvolveu? Sabemos como foi realizado o treinamento? São 100% seguros para executá-los, tanto em nossa máquina quanto, às vezes, em modo cooperativo? Os modelos também podem estar treinados para recomendar instruções maliciosas, pois podem carecer de proteções necessárias e não evitar que recomendem código malicioso. Além disso, podem gerar código vulnerável ou coisas similares. A maioria dos modelos faz isso, mas alguns são mais propensos. Dependendo do que estamos construindo, podem ser manipulados para realizar ações não previstas por nós. Vamos entrar em mais detalhes sobre esse tema.

Quando falamos de MCPs, por exemplo, existem dois tipos. O primeiro é o MCP STDIO, que se executa em nossa máquina. São scripts que rodam localmente. O outro é o Streamable HTTP, que será um serviço externo. Se olharmos pela perspectiva do MCP STDIO, que roda em nossa máquina, é um código que pode fazer o que qualquer código executando em nossa máquina faria. Pode ler um arquivo, seja ele de credenciais ou algo similar, executar comandos, baixar um arquivo externo e executá-lo, etc. Pode fazer qualquer coisa que qualquer outro software faria. Já os MCPs remotos, HTTP, Streamable HTTP, não têm essa mesma capacidade. Não podem estar presentes em nossa máquina, mas podem devolver algo ao nosso modelo, fazendo com que ele tome certas ações.

Analisando a estrutura e riscos das skills

Quando falamos de skills, o que é uma skill? Pensamos que a skill é apenas um markdown. Não é só um markdown. A grande maioria pode ser apenas um markdown, mas quando olhamos em detalhe, uma skill tem seu markdown, mas também pode incluir scripts ou binários. Tem referências a outros documentos, e muitas vezes não sabemos o que são esses documentos, além de assets como imagens e recursos. Se olharmos as skills, por exemplo, no Cloud Hub ou em qualquer outro lugar onde podemos baixar skills públicas, ao observar essas skills públicas, encontramos o exemplo do Agent Browser. Vemos o skill.md, que contém informações sobre como funciona. Mas, ao olhar mais para o final, vemos que fala sobre como instalar um plugin. Este, na verdade, é uma biblioteca NPM. Vamos instalar com o -g. Então, conhecemos isso? Sabemos o que é essa biblioteca? Oferece algum risco? E depois executa outro install, com dependências aninhadas, que provavelmente instalará outras subdependências. O que são essas subdependências? O que contêm? Alguma delas é vulnerável ou maliciosa? Não as conhecemos.

Para entender melhor a estrutura de uma skill, vejamos um exemplo de como ela pode ser organizada:

my-skill/
├── SKILL.md      # Obrigatório: instruções + metadados
├── scripts/      # Opcional: código executável
├── references/   # Opcional: documentação
└── assets/       # Opcional: modelos, recursos

Existe a skill em si, o markdown em si, mas desencadeia uma série de comandos ou pede ao agente que instale uma série de coisas das quais não temos conhecimento. Quando olhamos outros tipos de skills, podemos ver que não estão compostas apenas pelo markdown. Também incluem um script em Python, que será executado junto com ela. Podemos executar isso. Esses são scripts que talvez possamos ler. Mas, e se for um binário compilado que talvez não possamos ler? O que está sendo executado? Conhecemos o que esse script em Python vai fazer? E outra coisa, esse script em Python depende de alguma biblioteca para funcionar? Como será instalada?

Concluindo sobre os riscos e mitigação em ambientes de desenvolvimento

Quando olhamos esses agentes pela perspectiva de "não conheço" o que está sendo usado, não conheço o que está sendo instalado ou o que é capaz de fazer, e tudo isso também são bibliotecas de terceiros, código gerado, etc. Se não conhecemos isso, estamos expostos a uma série de riscos dentro desse ecossistema. A ideia deste curso é que aprofundemos mais em detalhe quais são esses riscos e também o que precisamos fazer para minimizar ou mitigar esses riscos dentro de nosso ambiente de desenvolvimento.

Introdução à segurança de IA - A tríade de segurança: confidencialidade, integridade e disponibilidade

Introduzindo a tríade de segurança

Já que analisamos esses componentes sob essa perspectiva, a ideia agora é que possamos entender um pouco sobre três conceitos que são essenciais para a segurança, conhecidos como a tríade: confidencialidade, integridade e disponibilidade (availability em inglês). O que queremos dizer com cada um deles? Na área de segurança, sempre nos preocupamos com esses três pilares.

Explicando o conceito de confidencialidade

Quando falamos de confidencialidade, referimo-nos ao fato de que todo tipo de informação deve ser acessada apenas por quem realmente pode, deve e precisa ter acesso a ela. Por exemplo, nem todo mundo tem acesso ao seu número de telefone ou ao seu e-mail. Esses dados podem ser alvo de tentativas de coleta de várias formas, mas não gostaríamos que fossem distribuídos indiscriminadamente. Em projetos, a confidencialidade é semelhante. Por exemplo, dentro de um projeto, podemos ter um arquivo .env cheio de segredos, e não queremos que esse arquivo seja vazado. Temos o código-fonte de nossa aplicação e não queremos que ele seja exposto. Ou, por exemplo, que um modelo seja treinado com ele e, de repente, comece a recomendar nosso código proprietário a outras pessoas. Portanto, a confidencialidade é muito importante. Mantemos isso com acesso restrito à informação apenas para as entidades que realmente precisam dela.

Discutindo a importância da integridade

Outra questão é a integridade. A integridade refere-se ao estado em que a informação deve estar, ou seja, que ninguém tenha alterado nada de forma não supervisionada. Por exemplo, não gostaríamos que nosso arquivo cloud.md fosse alterado sem autorização.

Não gostaríamos que nossa aplicação gerasse um registro no banco de dados que não estávamos esperando ou que não queríamos. Não gostaríamos que alguém acessasse nosso repositório no GitHub e modificasse um código lá sem nosso consentimento. Portanto, sempre nos preocuparemos para que as coisas recebam alterações ou sejam modificáveis apenas pelos fluxos que de fato deveriam poder modificá-las.

Abordando o conceito de disponibilidade

Por último, a disponibilidade. Disponibilidade significa que algo está disponível para acesso ou uso dentro do tempo estimado para isso. Vamos dar um exemplo: quando vamos fazer um pagamento com nosso cartão de crédito, em quais horários do dia esperamos que o serviço do cartão de crédito esteja disponível para que possamos efetuar o pagamento? Provavelmente diríamos: 24 horas, 7 dias por semana. Perfeito. Esse é o conceito de disponibilidade. Quando precisamos usar ou acessar algo, isso deve estar disponível.

Quando trabalhamos no desenvolvimento de sistemas, imagine que nosso banco caia. Nosso banco é um sistema e foi desenvolvido usando código gerado por humanos ou por inteligência artificial, e pode vir a cair. Pode até ter sido atacado por uma biblioteca maliciosa. Alguém instalou uma biblioteca que, na verdade, era um malware, e esse malware se propagou, transformou-se em um ransomware (sequestro de dados) e agora a empresa está totalmente comprometida e precisa suspender as operações. Isso pode ocorrer a partir da máquina de uma pessoa desenvolvedora.

Concluindo sobre a importância dos pilares de segurança

Devemos estar atentos para que a informação que temos não esteja sendo filtrada, para que o que estamos manipulando realmente seja o que estamos manipulando, e para que não estejamos introduzindo um risco que possa deixar completamente fora de serviço nossa empresa. Portanto, esses três pilares são fundamentais para guiar nossa visão de segurança a partir das revisões que faremos daqui em diante.

Sobre o curso Engenharia de software na era da IA: segurança de aplicações com agentes, MCPs e código gerado por IA

O curso Engenharia de software na era da IA: segurança de aplicações com agentes, MCPs e código gerado por IA possui 223 minutos de vídeos, em um total de 42 atividades. Gostou? Conheça nossos outros cursos de IA para Programação em Inteligência Artificial, ou leia nossos artigos de Inteligência Artificial.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Introdução à segurança de IA
• Principais ataques em ambientes de agentes de IA
• Explorando vulnerabilidades em MCPs e Skills
• Uso seguro de agent Skills
• Segurança no código gerado por IA