O que o agente escreve

“Essa coisa pode mexer na minha infraestrutura?”

Não. O RootPilot é read-only por construção, com exatamente cinco exceções — e nenhuma delas toca a sua infraestrutura. As cinco escrevem em sistemas de registro: ticket, chat e issue, que é onde um incidente é anotado e comunicado.

As cinco

Ferramenta	Onde escreve	Operação executada
create_incident_ticket	Jira	tickets.createIssue
update_jira_issue	Jira	tickets.transitionIssue, tickets.addComment
post_slack_message	Slack	chat.postMessage
create_slack_channel	Slack	chat.createChannel
create_github_issue	GitHub	tickets.createGithubIssue

O critério, e o que ele deixa de fora

A lista não é arbitrária e não é histórica. Uma escrita entra quando é registro reversível, no lugar onde o seu time já trabalha: ela afirma que algo merece atenção, não altera o que roda em produção, e desfazê-la custa um clique e deixa rastro. A issue do GitHub passa nesse teste pelo mesmo motivo que o ticket do Jira — vários times usam uma onde outros usam o outro.

Pull request não passa, e a recusa é deliberada. Uma PR propõe código, e o valor de propor código está em alguém aceitá-lo — então o modo de falha não é “abriram uma PR à toa”, é alguém mergear um diff escrito sobre uma causa que o agente inferiu. O contra-argumento óbvio (“PR passa por review humano”) é fraco por uma razão que nós medimos: numa leva de cinco achados do nosso próprio loop de melhoria, o sintoma estava certo nos cinco e o mecanismo proposto errado em quatro. Review de PR é gate contra código ruim, não contra causa errada.

AWS, GCP, Magalu e Datadog seguem fora, e agora por um motivo dito em vez de herdado: aquilo é infraestrutura, não registro.

A escrita no GitHub é opcional, e quem decide é a credencial

Se o token que você deu ao Agent não tem escopo de escrita, a operação falha na sua infraestrutura e a ferramenta some da superfície — o agente não a vê e não pode chamá-la. Não há flag para desligar porque não é preciso: o interruptor é o escopo do token, que já está na sua mão. É o mesmo desenho de todo connector que você não configura.

Nada em AWS, GCP, Magalu, Datadog, Argo CD, GitHub ou banco de dados

Não é configuração que alguém possa afrouxar. A garantia é o catálogo: não existe operação de escrita para esses serviços — são seis no total, e as seis são de Jira, Slack e issue do GitHub —, e o Agent, dentro da sua infra, recusa qualquer operação que não esteja no catálogo. E a conta é travada por teste: o CI enumera as operações de escrita e falha, nomeando a que apareceu, se elas deixarem de ser exatamente estas seis ou se alguma sair de ticket, chat ou issue — e o mesmo vale, do outro lado, para estas cinco ferramentas. Alguns connectors carregam ainda uma camada a mais: um teste que lê o próprio fonte do connector e falha se um verbo de escrita aparecer (hoje: Magalu, Vercel e Argo CD). No Argo CD essa camada vai além do verbo: como a API dele sincroniza, faz rollback e deleta application, o teste também recusa os caminhos dessas ações e o parâmetro refresh, que é uma leitura com efeito de escrita — ela força reconciliação no seu cluster. O rollback é lido; nunca disparado. Ver Modelo de segurança.

O escopo dessa garantia merece ser dito com precisão, porque é o tipo de frase que um time de segurança vai conferir: o token que o Agent segura não consegue escrever nas suas fontes. Isso não é o mesmo que dizer que nada em nenhum lugar escreve — se o produto abrir um pull request para você, isso acontece por outro caminho, fora do Agent e com outra credencial. O que esta página garante é o que passa pela superfície de agente e pelo Agent que roda na sua infra.

O gate confirmed, em duas camadas

Toda escrita exige confirmação explícita, e a confirmação é verificada duas vezes, em lados diferentes da fronteira.

Camada 1 — control-plane. A ferramenta recebe um parâmetro confirmed. Com confirmed: false (o default), ela devolve um preview e não toca em nada: o canal, o texto, o ticket que seria criado. Só confirmed: true executa.

Camada 2 — o seu Agent. A confirmação viaja no protocolo, junto da chamada. O Agent que roda na sua infra recusa executar qualquer operação marcada como escrita no catálogo se a confirmação não estiver lá, respondendo op_not_authorized.

A segunda camada existe para não depender da primeira

A camada 1 é nossa: você teria que confiar que a respeitamos. A camada 2 roda dentro da sua infraestrutura, no mesmo ponto que já recusa qualquer operação fora do catálogo. Um control-plane comprometido, com bug ou de versão errada não contorna a segunda.

Quem pode

Duas verificações independentes, ambas antes de qualquer efeito:

• A permissão mcp:write — de owner e admin. Um token cujo dono é member não escreve; um token sem dono (CLI, ou legado) não escreve nunca. É esta que é fail-closed: usuário inativo, papel que não resolve, erro de consulta — tudo isso nega a escrita em vez de liberá-la.
• O escopo do token — um token read bloqueia escrita mesmo se o dono for owner. É uma restrição por cima da primeira, não uma segunda chance: ela só sabe bloquear.

A matriz completa está em Tokens MCP. Nenhuma das duas verificações chega a tocar a sua infra: a recusa acontece no control-plane, antes de a chamada existir.

Audit com atribuição

Toda escrita confirmada vira registro na trilha de auditoria da sua organização, com o actor_id da pessoa dona do token — não “o agente”. É o que torna a autonomia auditável em vez de anônima, e é visível em Governança.

O registro tem duas fases, e a ordem é deliberada:

1. Antes do efeito grava-se a intenção, e isso é fail-closed: se não for possível registrar, a escrita não acontece. A política exige trilha para toda escrita confirmada, e uma escrita sem trilha seria pior do que uma escrita que falhou.
2. Depois do efeito grava-se o resultado — sucesso ou falha — e esse é best-effort: o efeito já ocorreu, e uma falha de registro aqui não pode desfazê-lo.

O que vai para a trilha é metadado: a ação, o alvo, o tamanho do texto, se houve redação. Não o conteúdo bruto.

Redação do texto que o modelo compõe

A redação de PII canônica acontece na borda do Agent, antes de qualquer dado sair da sua infra (ver Redação de PII). Mas o texto de uma mensagem no Slack é composto pelo modelo — ele não veio de lá, então não passou por lá.

Por isso há uma segunda passada, de alta confiança, sobre o texto que a ferramenta vai enviar: ARN, endereço de e-mail e chave de acesso da AWS são mascarados antes do envio. O preview mostra o texto já redigido — o que você aprova é o que sai —, e a trilha registra que houve redação.

O que ela deliberadamente não mascara: IP, UUID e hash de commit. São a evidência que torna a mensagem útil durante um incidente, e mascará-los transformaria o registro num texto que ninguém consegue usar.

As duas escritas automáticas

Existem exatamente duas situações em que o RootPilot escreve sem alguém pedir na hora, e um cliente que descobre isso sozinho tem razão em desconfiar. Então:

Quando	O que faz
A saúde das integrações da sua frota muda (ou um Agent novo conecta)	Posta uma linha no Slack dizendo o novo estado
Uma investigação automática de incidente conclui	Posta o diagnóstico no Slack

As duas usam post_slack_message com a confirmação já dada, e as duas têm o mesmo limite duro: elas só reportam. Nunca uma ação corretiva, nunca uma mudança em sistema seu. Postar o resultado de uma leitura é a fronteira, e ela não se move.

O limite não é intenção, e cada uma o sustenta de um jeito: a investigação automática recebe a lista de ferramentas sem nenhuma das cinco de escrita — o modelo que a conduz não tem como pedi-las —, e o aviso de saúde de frota não fala com o seu ambiente de forma alguma: a única saída dele é um texto para um canal.

As duas também são desligadas por padrão e só acontecem com três coisas simultaneamente verdadeiras: o recurso ligado no processo, um canal do Slack configurado, e — no caso da saúde de frota — a sua organização tendo optado por recebê-la. Ambas viram registro na trilha, marcadas com a origem própria (não como escrita de agente), então dá para separar o que uma pessoa pediu do que o sistema reportou.

Onde você desliga

Quatro caminhos, do mais fino ao mais grosso:

1. Emita tokens read. Bloqueia escrita mesmo para quem é owner, e é o default do formulário.
2. Não conceda mcp:write. Sem owner/admin, nenhum token escreve.
3. Não configure Jira/Slack no Agent. Sem connector servindo essas operações, as ferramentas nem aparecem para o modelo.
4. Negue por política. A denylist de tools recusa as operações dentro da sua infra, independentemente do que o control-plane peça.

Os dois primeiros são controles nossos; os dois últimos rodam do seu lado da fronteira. Se a sua avaliação de risco exige uma garantia que não dependa de nós, é o terceiro ou o quarto.

O que esta página não cobre

• A leitura — O que o agente lê.
• Como o token é emitido e escopado — Tokens MCP.
• As cinco operações de escrita no catálogo, e o enforcement dentro do Agent — Modelo de segurança.