Proteções MCP: permissões seguras para agentes de IA

Um token MCP é a senha da sua conta com uma API conectada. Entregue-o a um agente e você terá um usuário que nunca se cansa, lê qualquer página para a qual você o aponta e faz exatamente o que a última instrução no contexto dele mandou. Na maior parte do tempo, é isso que você quer. Esta página trata do resto do tempo.

Tudo abaixo foi conferido no servidor em produção na data indicada no topo: a lista de ferramentas vem de tools/list em https://mcp.eqvps.com/mcp, os limites vêm da própria API. Se você está começando, veja primeiro como conectar um cliente MCP e tokens de API, e depois volte.

Modelo de ameaças: o que dá errado na prática

Três coisas, na ordem em que as vemos:

1. O agente entende errado. «Limpa a máquina de teste» vira a reinstalação do servidor errado. Sem malícia, só um modelo preenchendo uma lacuna na instrução.
2. Injeção de prompt. O agente lê um texto que você não escreveu (um README, uma resposta do suporte, uma página da web) e esse texto manda ele fazer algo. Se o agente tem um token com todos os direitos, a instrução injetada também tem.
3. O token vaza. Ele vai parar num histórico do shell, num repositório público, numa configuração MCP compartilhada ou numa linha de log.

O servidor MCP verifica se o token é válido e se o servidor pertence àquela conta (ou foi delegado a ela). Ele não sabe o que você quis dizer. Cada proteção abaixo responde a uma única pergunta: quanto estrago é possível quando a instrução está errada?

Todas as ferramentas MCP, por nível de risco

Um token de cliente vê 45 ferramentas (servidor MCP 1.6.0). Um token de revendedor (rk_…) vê um conjunto separado de 30 ferramentas de revenda e nenhuma destas, então o endpoint tem 75 no total. O seu cliente recebe de tools/list apenas o próprio conjunto.

Esta página organiza as ferramentas por risco. Os parâmetros e exemplos de chamadas de cada uma estão na referência de parâmetros; todas as ferramentas em uma linha, incluindo as 30 de revendedor, estão na lista completa.

Ainda não publicamos anotações de ferramentas MCP (readOnlyHint, destructiveHint), então o seu cliente não consegue classificá-las sozinho. Configure as aprovações à mão com base nos níveis abaixo.

Nível 0 — públicas, sem token (5)

Nível 1 — leitura da conta, sem efeitos colaterais (15)

Nível 2 — mudam o estado, não gastam nada (17)

Nível 3 — gastam dinheiro, destroem dados ou concedem acesso (8)

Changelog do conjunto de ferramentas

A versão em execução é pública: curl -s https://mcp.eqvps.com/healthz. Quando ela mudar, esta tabela muda junto.

O saldo é o teto de gastos

A EQVPS é pré-paga. Sem cartão salvo, sem linha de crédito e sem saldo negativo: o máximo que um agente pode gastar é o que está no saldo. Três ferramentas gastam: order_vps, change_plan e create_sandbox. As renovações dos seus servidores atuais saem do mesmo saldo.

O agente pode criar pedidos de dinheiro, mas não pagá-los. topup_balance e pay_invoice retornam um link de pagamento cripto, e um link não faz nada sem uma carteira por trás. Também não existe endpoint de saque: o dinheiro do saldo pode comprar serviços na sua conta, não sair dela. Reembolsos de um cancelamento imediato também voltam para o saldo.

Uma ressalva, e ela é séria. Se você deixar o saldo muito baixo para frear o agente, as suas próprias renovações começam a falhar e os servidores entram no período de carência. Nossa regra prática: um ciclo de renovação do que você já tem rodando, mais o orçamento da tarefa atual do agente. O guia de orçamento para agentes mostra o cálculo. E se você der ao agente uma carteira própria com fundos, essa carteira vira um segundo teto que você também precisa vigiar.

Privilégio mínimo: não existe token somente leitura (ainda)

Resposta direta: todo token de cliente tem os mesmos direitos da conta no painel. Nome e validade do token são configuráveis; escopos, não.

O mais restrito que existe hoje é a delegação. Você dá ao agente uma conta própria, com saldo zero, e delega a ele um servidor:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

O mesmo via REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

O convite precisa ser aceito com a sessão aberta nesse e-mail (accept_delegation), e expires_days vai de 1 a 365. Passo a passo com capturas de tela: delegar acesso e o acesso na documentação.

Repare nas duas últimas linhas da esquerda. Um delegado não consegue gastar o seu dinheiro, mas consegue apagar aquele servidor. Ative backups em qualquer servidor que um agente possa reinstalar.

Higiene de tokens

Um token por agente, com nome. Crie-o em Painel → Configurações → Tokens de API para agentes, ou assim:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

O token aparece uma única vez. Validade de 1 a 1825 dias, 365 se você não informar. Para agentes, escolheríamos 90.

Guarde-o num arquivo que só você consegue ler, não no repositório, não no prompt, não numa variável de shell que você fica copiando:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # esperado: -rw-------

Depois carregue-o no serviço do agente com EnvironmentFile= (systemd) ou set -a; . ~/.config/eqvps/agent.env; set +a.

Faça a rotação antes de expirar. A ferramenta refresh_token, ou POST /auth/tokens/{id}/refresh, emite um token novo com o mesmo nome e revoga o antigo na hora. Se o seu cliente MCP tem o token fixo na configuração, atualize logo em seguida, senão a próxima sessão recebe 401.

Confira quem usa o quê: GET /auth/tokens lista cada token com nome, validade e last_used_at. Um token que você não reconhece, ou um usado depois que você desligou o agente, é o seu sinal.

Se um token vazar

Nesta ordem:

1. Revogue. Painel → Configurações → Tokens de API para agentes → Revogar, ou curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Ele para de funcionar na próxima requisição.
2. Procure tokens novos que você não criou e revogue-os também.
3. Avalie o que pode ter sido afetado: o histórico do serviço de cada servidor, faturas e saldo, e list_delegations em busca de acessos que você não concedeu.
4. Troque as senhas root de todos os servidores que aquele token podia ver. get_vps_status com reveal: true entrega a senha root, então um token vazado é uma senha root vazada. Aproveite para conferir ~/.ssh/authorized_keys.
5. Feche a porta da senha. Se a sua conta nunca teve senha, quem tinha o token pode ter definido uma com set_password. Entre com um código por e-mail e troque-a.

Prevenir o passo 5 não custa nada: defina você mesmo uma senha para a conta agora, e set_password vai retornar 409 para qualquer um que vier depois.

Aprovação humana

O que o servidor impõe:

• reinstall_vps, reset_password e cancel_service com type: immediate exigem confirm igual ao hostname exato (DELETE também serve para reinstalação e redefinição).
• change_plan exige confirm: true.
• O cancelamento padrão é end_of_period: o servidor segue até o fim do período pago, e undo_cancel desfaz.
• Limites por conta: reinstalação 4/min, redefinição de senha 6/min, energia 20/min, pedidos 20/min. O bastante para um loop não fazer isso cinquenta vezes, não para impedir uma única chamada errada.

Tenha claro o que o confirm é. Ele impede um agente de agir em cima de um «limpa isso aí». Não segura um atacante, porque o hostname está a uma chamada de get_vps_status. A aprovação de verdade fica no seu cliente MCP. A maioria dos clientes consegue perguntar antes de cada chamada: deixe os níveis 0 e 1 rodarem livres e faça o nível 3 sempre perguntar. Em clientes com permissões por ferramenta, como o settings.json do Claude Code (servidor registrado como eqvps):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

Acrescente também uma linha às instruções do agente. Sozinha ela não é um controle de segurança, mas reduz os mal-entendidos (deixe em inglês, os modelos entendem igual):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

Se o agente entra com um código por e-mail em vez de guardar um token de longa duração, veja login do agente via MCP.

Auditoria: o que dá para ver depois

• Lista de tokens (GET /auth/tokens, ou Configurações → Tokens de API para agentes): nome, criação, validade, last_used_at. É por isso que vale nomear os tokens por agente.
• Histórico do serviço (painel, página do servidor): ações de energia, reinstalações, redefinições de senha, trocas de plano, pagamentos, cada um com horário e autor: você, suporte ou automático. Ele não diz qual token ou delegado agiu, só que a ação veio do seu lado.
• Faturas e saldo: cada cobrança e cada reembolso.
• list_delegations: quem tem acesso a quê e até quando.

Essa lacuna no histórico do serviço é o limite honesto da auditoria do lado do servidor hoje. Se você precisa saber qual agente fez o quê, registre cada chamada de ferramenta com os argumentos (sem segredos) do lado do agente.

A configuração que usaríamos

Para um agente que cuida de um servidor de produção:

1. Uma conta separada para o agente, saldo zero, o servidor delegado com expires_days: 90.
2. O seu token de dono fica com você, fora de qualquer configuração do agente.
3. Backups nesse servidor, porque um delegado pode reinstalar.
4. Ferramentas de nível 3 em «ask» ou «deny» no cliente.
5. O token do agente num arquivo 600, renovado antes de expirar.

Para um agente que precisa pedir servidores ou rodar sandboxes, delegação não basta, porque ele precisa de saldo. Aí o saldo é o seu teto: recarregue por tarefa, dê nome ao token e olhe o last_used_at uma vez por semana. Se um token somente leitura mudaria a forma como você coloca agentes para rodar, conte para nós no suporte: é esse tipo de retorno que decide o que construímos depois.