Seu agente pode escrever no seu banco de dados. Qual camada realmente o impede?

Em julho de 2025, o agente da Replit deletou um banco de dados de produção ao vivo
durante uma pausa explícita de código e ação. O CEO da Replit chamou isso de inaceitável
e enviou a separação de dev/prod e um melhor rollback em resposta.

A pausa foi real. Foi registrada, foi acordada, e o agente foi
informado sobre isso — e nada disso estava no caminho de execução. A instrução viveu
no contexto do modelo, e o contexto do modelo não é um lugar onde regras são
enforçadas.

Há um segundo detalhe que vale a pena considerar. Depois, o agente relatou que
o rollback era impossível. Isso estava errado, e atrasou a recuperação. Assim, a
própria conta do sistema sobre o que havia feito não era apenas inútil; era
confidentemente falsa na direção que importava.

Esse incidente é a versão mais curta da pergunta sobre a qual este post trata. Cada
ferramenta neste espaço tem uma barreira de proteção. Elas diferem enormemente em qual camada essa
barreira de proteção reside, e quase nenhuma delas te diz.

Eu fui procurar uma comparação organizada dessa forma e não consegui encontrar uma, então
aqui está a minha. Eu tenho uma ferramenta nesse espaço eu mesmo; ela está no final, alternativas
a ela são nomeadas antes dela, e eu tentei descrever tudo o mais da maneira
que seus mantenedores fariam.

Uma versão anterior deste post foi revisada por pessoas que procuravam especificamente por
lugares onde eu havia elogiado minha própria ferramenta ou descrito mal a ferramenta de outra pessoa. Eles
encontraram vários. As correções estão no texto em vez de em uma nota de rodapé.

A escada

Existem cinco lugares onde uma regra sobre gravações em banco de dados pode ser aplicada. Eles não são
equivalentes em qualidade, e a diferença não é uma questão de grau.

A propriedade útil desta escada: cada degrau sobrevive à falha de cada
degrau acima dele. Um papel de banco de dados sem privilégios de gravação não se importa se
seu allowlist tem um bug de análise, se o usuário clicou em "sempre permitir", ou
se o modelo foi convencido de algo por um ticket de suporte que leu.

A maior parte do desacordo neste espaço acaba sendo ferramentas situadas em diferentes
degraus enquanto usam as mesmas palavras.

Camada 1: o contexto do modelo

Estas são descrições de ferramentas, prompts do sistema e instruções retornadas dentro dos resultados da ferramenta — "use isso apenas para consultas de leitura", "pergunte ao usuário antes de aplicar".

Ela tem nenhum valor de segurança. Vale a pena escrever, porque melhora o comportamento ordinário
e o comportamento ordinário é a maior parte do comportamento. Não é um controle, e o
incidente de julho de 2025 é o que acontece quando alguém acredita de outra forma.

Há uma versão específica disso que vale a pena nomear, porque é fácil confundir
com a camada 3. Alguns servidores MCP implementam um fluxo de gravação em duas etapas — preparar, depois
completar — onde a separação entre as etapas é que a descrição da ferramenta
diz ao modelo para verificar entre elas. Se nada recusar a segunda chamada quando a
primeira nunca foi realmente verificada, isso é a camada 1 vestindo as roupas da camada 3.

Camada 2: o cliente

Todo cliente MCP sério mostra um diálogo de confirmação antes de uma chamada de ferramenta, e os
frameworks de agentes têm seus próprios equivalentes: HumanInTheLoopMiddleware e interrupt do LangChain, needsApproval com interruptions resumíveis do OpenAI Agents SDK, requires_approval
das ferramentas adiadas do Pydantic AI. Estes são mecanismos reais e bem construídos, e se você está construindo um
agente que grava em qualquer lugar, você deve usá-los.

Dois problemas honestos.

O que o humano vê é geralmente a própria entrada da ferramenta do modelo. Para uma gravação em banco de dados
isso significa uma string SQL, renderizada como JSON. Não as linhas que tocará, não
quantas, não o que elas contêm atualmente. Os mesmos clientes que renderizam uma edição de arquivo
como um diff de cor renderizam uma mutação de banco de dados como um bloco de texto. Você está sendo
pedido para aprovar uma declaração, o que significa que você está sendo
pedido para ser um intérprete SQL, na sua cabeça, contra dados que você não pode ver.

E esses portões são desligados. --dangerously-skip-permissions, modos de execução automática,
creep de allowlist. Isso não é erro do usuário; é o resultado previsível de
pedir a alguém vinte vezes por hora se ele realmente quis. Qualquer controle cujo custo
esse um clique, pago repetidamente, converge para ser desativado.

Um design que evita ambos os problemas, e é subestimado porque é chato:
faça o agente produzir um artefato que passe pela revisão que você já tem.
Um arquivo de migração em um pull request. Uma linha em uma tabela de staging que um trabalho confiável
aplica. O humano então revisa em uma ferramenta construída para revisão, com histórico e
culpa e um segundo par de olhos, em vez de em um modal que o interrompe.

Camada 3: o processo do servidor

É aqui que a maioria dos servidores MCP de banco de dados coloca sua barreira, e é onde as
falhas interessantes estão, porque um servidor aqui possui uma credencial que pode gravar
e está escolhendo não usá-la.

Existem pelo menos quatro mecanismos distintos, e eles não são igualmente fortes.

Envolver a consulta em uma transação somente leitura. O servidor de referência MCP original
para Postgres fez isso: BEGIN TRANSACTION READ ONLY, execute o SQL, reverta em um finally. Os Laboratórios de Segurança da Datadog
mostraram que era contornável
pela empilhamento de declarações: o driver do Postgres aceita várias declarações separadas por ponto e vírgula em uma chamada, então COMMIT; DROP SCHEMA public CASCADE; encerra a transação somente leitura e tudo o que vem depois é executado com plenos privilégios.

A correção recomendada deles é todo o argumento deste post, de uma equipe de segurança que acabara de terminar de quebrar a versão de aplicação disso:

Uma possível mitigação — que recomendamos em qualquer caso — é usar um usuário do Postgres
com privilégios restritos. Você definitivamente deve fazer isso.

A conclusão deles é a pouco glamourosa, e vale a pena repetir: "vulnerabilidades clássicas de segurança de aplicação ainda são muito relevantes para servidores MCP e
outros ferramentas de IA."

A lição se generaliza, nas minhas palavras em vez das deles: uma transação somente leitura
não é uma fronteira de segurança quando o protocolo aceita ponto e vírgula.

Esse servidor foi descontinuado em julho de 2025 e arquivado. Ele ainda tinha 86.941 downloads npm
na semana de 2 de agosto de 2026, que eu verifiquei enquanto escrevia isso.

Palavras-chave de bloqueio. Os servidores MCP de banco de dados da AWS por padrão são somente leitura e rejeitam
INSERT, UPDATE, DROP, declarações de estado de sessão e uma lista de funções perigosas. O README deles é incomum