Tokens MCP somente leitura e por projeto para agentes de IA

“Devo dar a um agente de IA acesso à minha lista de tarefas?” são, na verdade, três perguntas diferentes disfarçadas de uma: quanto ele consegue ver, com que rapidez eu consigo cortar o acesso se algo der errado e o que continua precisando do meu aval mesmo enquanto ele está conectado. Nenhuma delas depende do modelo que você usa. São propriedades de como o servidor aplica o acesso, e não do julgamento do agente.

Por que o escopo importa mais do que o modelo?

Um agente só consegue fazer o que as credenciais dele permitem, por mais capaz ou cuidadoso que seja o modelo por trás. É uma garantia do lado do servidor, sem graça de propósito, e não uma esperança sobre o comportamento do modelo. Pelo mesmo motivo, você limitaria a chave de API de qualquer outro serviço a exatamente o que ele precisa, e não a tudo em que ele teoricamente poderia tocar.

Acesso completo, somente leitura ou um projeto

Cada conta tem o próprio endpoint MCP e os próprios tokens, nunca um compartilhado ou global. No Pro e no Teams, um token pode ter o escopo ainda mais reduzido: somente leitura, para que um agente veja a fila e o contexto dos comentários, mas nunca altere nada, ou um único projeto, para que ele veja só as tarefas daquele projeto e nada do resto da sua conta. Comece com menos acesso do que você acha que precisa. Ampliar depois é fácil, enquanto reduzir depois do fato significa confiar em um agente que já teve um acesso mais amplo.

Revogar o acesso na hora

Regenerar ou revogar um token o invalida imediatamente, sem esperar um cache expirar em algum lugar. E, se você estiver se recuperando de algo de que não tem certeza, alterar ou redefinir a sua senha revoga de uma vez todas as credenciais de API da conta, incluindo os tokens MCP e os apps conectados. Assim, uma suspeita de comprometimento não deixa o acesso de agentes vivo em silêncio depois que você já trocou a senha.

A trava de aprovação como segundo controle

O escopo trata do que um agente pode ver e tocar. A trava de aprovação trata do que ele pode concluir sem perguntar. Uma tarefa marcada com aprovação automática pode ser fechada diretamente, o que é aceitável para trabalho reversível e de baixo risco. Todo o resto passa por propose_completion e fica aguardando aprovação até uma pessoa dar o aval, e só uma pessoa pode marcar uma tarefa com aprovação automática. Os dois mecanismos cobrem riscos diferentes: o escopo limita o raio de impacto, e a trava limita o que pode ser dado como encerrado sem supervisão.

Execuções auditáveis e limites

Cada sessão de um agente roda como uma execução registrada, com limite próprio de chamadas de ferramentas e de tempo. O check_budget diz quanto resta antes de o limite de uma sessão acabar, e, quando o limite definido para uma tarefa se esgota, o start_run é recusado de vez, em vez de deixar a sessão continuar com tempo emprestado. É uma terceira alavanca, independente: não tem a ver com acesso nem com o que é dado como encerrado, e sim com quanto uma única sessão pode fazer antes de ter que parar e voltar a consultar você.

Uma configuração inicial sensata

Comece com um agente somente leitura ou limitado a um projeto, deixe a maioria das tarefas sem aprovação automática e acompanhe algumas execuções antes de afrouxar qualquer coisa. Amplie o escopo do token, ou comece a marcar tarefas rotineiras com aprovação automática, depois de ver de fato o que o agente faz com o acesso que tem, e não antes. Nada disso é desconfiança. É a mesma postura que você teria ao integrar alguém recém-contratado a um sistema com consequências reais.