Anthropic comprou a Stainless. Aqui está como estou fortalecendo servidores MCP de múltiplos fornecedores esta semana.

Contexto rápido para quem perdeu as notícias de ontem: a Anthropic adquiriu a Stainless em 18-05-2026. A Stainless é a empresa de scaffolding de SDK e servidor MCP que alimentou todos os SDKs oficiais da Anthropic desde o primeiro dia — e os SDKs oficiais da OpenAI, Google, Cloudflare, Llama Stack da Meta, Runway, Replicate, Cerebras, Groq e Modern Treasury. O TechCrunch confirma o negócio por mais de $300M. O gerador de SDK hospedado: encerrando hoje.

Fontes:

• https://www.anthropic.com/news/anthropic-acquires-stainless
• https://techcrunch.com/2026/05/18/anthropic-has-acquired-the-dev-tools-startup-used-by-openai-google-and-cloudflare/

Se você envia servidores MCP em produção e utiliza mais de um fornecedor de modelo (a maioria das empresas de produção faz isso), a mudança prática é que o lado do produtor da cadeia de suprimentos MCP e o lado da política agora compartilham um fornecedor. A cadência de patches, os padrões de validação de esquema e a postura STDIO para servidores gerados pela Stainless agora são uma decisão da roadmap da Anthropic.

Aqui está o plano concreto que estou executando esta semana para a suíte de regressão CVE do agente-airlock, caso seja útil.

1. Marque cada servidor MCP por proveniência

Adicione um único campo ao seu log de auditoria:

@dataclass
class McpServerCallRecord:
    server_name: str
    server_provenance: Literal[
        "stainless-generated",     # SDK ou servidor foi gerado pela Stainless
        "stainless-then-hand-edited",  # Gerado pela Stainless, depois editado
        "hand-written",            # nunca tocado pela Stainless
        "vendor-bundled",          # e.g. Splunk / MongoDB / Elastic / GitLab / Fivetran MCP de primeira parte
        "unknown",                 # padrão — investigar
    ]
    tool_name: str
    args_hash: str
    started_at: datetime
    duration_ms: int
    outcome: Literal["ok", "denied", "error"]

A razão pela qual isso é importante: após a aquisição, os padrões padrão dos servidores gerados pela Stainless vão divergir dos padrões dos servidores da política da Anthropic em uma cadência trimestral. Você vai querer ser capaz de grep seu log de auditoria por server_provenance = "stainless-generated" quando uma atualização de código da Stainless chegar, para que você saiba quais servidores em sua frota você precisa re-testar primeiro.

2. Mova o STDIO MCP para negar por padrão (se você ainda não fez isso)

Esta é a melhor prática do CVE-2026-30623 e se torna ainda mais importante agora. A postura mínima:

from agent_airlock import airlock, RbacPolicy, NetworkAirgap

@airlock(
    rbac=RbacPolicy.deny_all_then_allow(["read_file", "list_files"]),
    network=NetworkAirgap.allow_only(["https://api.attri.ai"]),
    pii_mask=True,
    strip_ghost_args=True,
    sandbox=E2BSandbox(timeout_s=30),
    cost_budget_usd=0.10,
)
def call_mcp_tool(server: str, tool: str, args: dict) -> dict:
    ...

Um decorador. O mesmo decorador funciona se o servidor MCP downstream foi gerado pela Stainless, escrito à mão ou empacotado pelo fornecedor. Essa é a propriedade que sobrevive ao negócio de ontem.

3. Fixe e monitore as versões dos seus SDKs gerados pela Stainless

Os clientes existentes da Stainless mantêm o que geraram — tanto o TechCrunch quanto o FAQ da Anthropic confirmam isso — mas o upstream está fechado para novas inscrições. Então:

• Fixe cada SDK gerado pela Stainless a uma versão explícita no seu arquivo de bloqueio.
• Configure uma verificação de diferença semanal contra o último snapshot aberto do repositório de templates da Stainless (se disponível — provavelmente os repositórios de templates se tornarão privados da Anthropic nos próximos 30 dias, vale a pena raspar uma cópia congelada hoje).
• Trate qualquer aviso futuro de "atualização do SDK da Stainless" como um evento de segurança que requer re-teste, não como um aumento de dependência de rotina.

4. Adicione o HarnessAudit-Bench à sua suíte de regressão

O artigo HarnessAudit da UCSD / Florida / Princeton (arXiv 2605.14271) lançou um benchmark de 210 tarefas avaliando harnesses de agentes em violações de acesso a recursos e violações de transferência de informações entre agentes em 8 domínios do mundo real. Esses são os dois modos de falha que uma camada de endurecimento MCP deve ser comparável.

Concreto: estou conectando harness-audit-bench ao agente-ai