Modelo de segurança

O RootPilot pede acesso de leitura privilegiado à sua stack inteira. Para uma ferramenta assim, transparência é requisito, não cortesia, e é por isso que esta metade é aberta. O que segue é o que o código de fato garante, e onde.

As invariantes

Zero custódia de credencial

As suas credenciais nunca são custodiadas fora da sua infraestrutura. O runner as lê do seu secret manager no boot e as mantém apenas em memória: nunca em disco, nunca na imagem, nunca no control-plane.

Redação de PII num único ponto

A redação acontece na borda do runner, antes de qualquer resultado cruzar a fronteira. Um ponto de aplicação, não vários. Ver Redação de PII.

Read-only na camada de connector

Com as cinco exceções listadas abaixo, e nenhuma outra.

O enforcement point

O control-plane pede o quê. O runner decide se pode. A decisão mora num único lugar, apps/runner/src/enforcement.ts, e faz três coisas:

1. Allowlist de catálogo. Só operações do catálogo versionado. Qualquer coisa fora dele é recusada, independentemente do que o control-plane peça.
2. Argumentos estritos. Validados contra o inputSchema da operação, em modo estrito.
3. Deadline. Aplicado por operação (RUNNER_INVOKE_DEADLINE_MS, default 30 s).

Que a decisão viva do lado do runner é o ponto: um control-plane comprometido não consegue pedir uma operação que o catálogo não tem.

As cinco operações de escrita

O catálogo é read-only exceto por cinco operações, todas de ticket e chat:

Operação	Serviço
tickets.createIssue	Jira
tickets.addComment	Jira
tickets.transitionIssue	Jira
chat.postMessage	Slack
chat.createChannel	Slack

AWS, Datadog, GitHub e todo o resto permanecem estritamente read-only.

O escopo desta garantia é o runner

“Read-only” aqui significa: as credenciais que você entrega ao runner só executam leitura. O connector do GitHub, por exemplo, não tem uma única chamada mutante: nem HTTP POST/PUT/PATCH, nem mutation GraphQL; a única operação de pull request no catálogo é deploys.findPullRequestsForCommit, que apenas descobre qual PR mergeou num commit.

Isso não é o mesmo que dizer que nada no RootPilot escreve no seu GitHub. Se o produto abre um pull request para você, isso acontece por outro caminho, fora deste repositório e fora do runner, com uma credencial que não é a que você montou aqui. O que esta página garante é o escopo do edge: o token que o runner segura não consegue escrever.

O gate humano, em duas camadas

A confirmação humana é defesa em profundidade, aplicada dos dois lados:

• Control-plane: o gate de confirmed e o preview vivem na ferramenta de escrita.
• Runner: independentemente disso, o runner exige confirmed: true na invocação para executar qualquer operação marcada como write no catálogo. Sem isso, responde op_not_authorized.

O segundo existe justamente para não depender do primeiro. É um gate no nível do wire.

SQL e agregação read-only

Três operações aceitam consulta livre: agregação de MongoDB, Athena e CloudTrail Lake. Elas entraram com validação de segurança de escrita no handler, não por confiança:

• Pipelines de agregação com $out ou $merge são rejeitados.
• SQL com DDL ou DML é rejeitado.

Isolamento de connector

O ConnectorRuntime sustenta quatro garantias. Vale ser preciso sobre onde cada uma é aplicada e onde é apenas declarada:

Garantia	native	sidecar
Secret escopado por connector	aplicada	aplicada
Allowlist de egress	declaratória	aplicada
Conformância com o contrato	aplicada (no teste)	aplicada
Redação por campo declarado	aplicada	aplicada

A allowlist de egress não cobre connectors nativos

Os connectors nativos embrulham SDKs de terceiros que fazem HTTP por conta própria, fora do alcance do runtime. As declarações de egress nos manifests documentam a intenção, mas não a aplicam.

Se você precisa de garantia de egress, aplique-a onde ela é real: no seu security group, na sua NetworkPolicy, no seu proxy de saída. A mediação real dentro do produto é propriedade do mecanismo sidecar.

Superfície de rede

O runner é cliente de saída, e só. Não escuta em porta nenhuma, não expõe endpoint de health, não precisa de nada aberto no seu firewall para entrada. O túnel é WSS reverso com mTLS, e o certificado vem de um enrollment cuja identidade é provada pela plataforma.

O que fica de fora deste repositório

A inteligência de diagnóstico é fechada e vive no control-plane. Isso é relevante para a sua avaliação de risco de duas formas:

• A favor: tudo que toca as suas credenciais está aqui, auditável. O executor é a superfície que importa para segurança, e ela é aberta.
• Contra: você não pode auditar o que o control-plane faz com os resultados já redigidos que recebe.

É honesto dizer as duas.

Auditar por conta própria

Alguns pontos de partida úteis, se você for revisar o código:

Pergunta	Onde olhar
O que pode ser executado?	packages/protocol, o catálogo versionado.
O que é recusado, e como?	apps/runner/src/enforcement.ts.
O que é redigido?	apps/runner/src/redact/ e packages/core-edge/src/policy/.
Como a identidade é provada?	apps/runner/src/enroll/attestation.ts.
Que credencial cada connector pede?	apps/runner/src/connectors/manifests/real.ts.