Minha Ferramenta MCP Registrou Cada Sobrescrita de um Artigo Ao Vivo. Nada Impediu a Sobrescrita.

Eu continuo vendo a mesma forma de postagem aqui ultimamente: alguém construiu um "guardião" na frente das ferramentas do seu agente de IA, ou perguntou quem está realmente autorizando as capacidades de um plugin de agente em tempo de execução. Isso me fez voltar e verificar algo que eu estava assumindo que estava bem em meu próprio servidor MCP — as ferramentas do DEV.to que uso para gerenciar este exato blog.

server.py tem duas ferramentas de escrita: create_article e update_article. Eu já endureci update_article duas vezes. A primeira vez (bugs.md, 27-07-2026) foi porque ele aceitava um inteiro simples article_id, enviava os campos que você fornecia diretamente como um PUT, e se o id estivesse errado ou fosse alucinado, ele silenciosamente sobrescrevia qualquer artigo que aquele id apontasse, sem nada deixado para trás para mostrar que isso havia acontecido. Eu consertei isso buscando o artigo primeiro e computando um diff:

before = _dev(f"/articles/{article_id}")
result = _dev(f"/articles/{article_id}", method="PUT", data={"article": article})
_log_article_update(article_id, before, article.keys(), result)
return {
    "id": result["id"],
    "diff": {field: {"before": before.get(field), "after": result.get(field)}
             for field in article},
}

Isso parecia um progresso real na época, e de certa forma foi — uma escrita errada agora deixa um rastro em vez de desaparecer silenciosamente. Mas, ao reler isso ao lado das postagens em alta desta semana sobre "quem autoriza as chamadas de ferramentas de um agente", percebi o que isso realmente faz: ele computa o diff, depois escreve, e então registra. A etapa de autorização — a parte onde algo decide se essa escrita deve acontecer — não existe em nenhum lugar nessa sequência. before é buscado, o PUT é disparado incondicionalmente, e o diff é relatado depois do fato. Um "portão" que só abre não é um portão. É uma impressora de recibos.

Compare isso com a outra credencial capaz de escrita neste mesmo arquivo. _gh(), o helper da API do GitHub, tem um bloqueio real:

def _gh(path, method="GET", data=None):
    if method != "GET" or data is not None:
        raise ValueError("_gh é somente leitura — nenhuma ferramenta neste arquivo deve nunca escrever para o GitHub")
    ...

GITHUB_TOKEN tem escopo repo, user — acesso total de escrita — mas todas as ferramentas do GitHub neste servidor só precisam ler, então _gh() se recusa a ser qualquer outra coisa, incondicionalmente, independentemente do que qualquer chamador pedir. Essa é uma verdadeira fronteira de autorização: sem argumento, sem flag, sem confirmação — gravações no GitHub estão categoricamente fora. _dev(), o equivalente do DEV.to, não tem tal coisa, porque create_article e update_article precisam legitimamente escrever. Justo — mas "precisa legitimamente escrever às vezes" foi tratado como "deve escrever sempre que solicitado, sem perguntas", e essas não são a mesma afirmação.

A parte que realmente me preocupou: o DEV.to não mantém nenhum histórico de versão para um artigo. Não há registro de revisões, sem desfazer, nada do lado do servidor para recuperar um body_markdown anterior uma vez que um PUT o sobrescreve. Meu conserto de diff e log me diz exatamente o que mudou — depois que uma postagem ao vivo que não posso recuperar já se foi. Para um rascunho novíssimo, isso não é um problema; você sempre pode PUT novamente. Para algo já publicado e lido, não é.

A correção

Eu adicionei um parâmetro confirm que só importa quando ambas as coisas são verdadeiras: o artigo está atualmente publicado, e a escrita realmente mudaria title ou body_markdown — as partes que um leitor vê, não apenas a flag published em si.

before = _dev(f"/articles/{article_id}")
live_content_write = before.get("published") and ("title" in article or "body_markdown" in article )