Git Workspaces: agentes de IA ganham branch, não credenciais

O que um workspace Git concede

Agentes de codificação com IA já escrevem, executam e enviam código para repositórios de produção — mas a questão real de segurança não é o que eles podem fazer, e sim o que as suas credenciais permitem. A resposta da Pragor, anunciada em 6 de outubro de 2026, é uma fronteira deliberadamente estreita: os workspaces Git dão ao agente um checkout gravável e um branch, e retêm credenciais, rede, banco de dados e qualquer caminho para autoconceder autoridade extra.

Um workspace Git é um checkout gravável vinculado a um repositório, uma tarefa e um responsável, criado a partir de um commit base imutável. O agente lê, altera, executa comandos e submete; a entrega é apenas para frente, para um branch derivado. A Pragor não força push nem altera o remoto após o início da mutação.

O que o agente não recebe:

• Não as credenciais. Credenciais de escrita são instaladas por um operador humano contra uma origem HTTPS fixada ao provedor, referenciadas por um slug opaco, descriptografadas só para a requisição que as exige e nunca devolvidas ao runtime.
• Não a rede. Os comandos rodam sem acesso à rede, como usuário não-root, com CPU, memória, processos, tempo e escopo de arquivos limitados.
• Não o resto da plataforma. O agente nunca recebe URL de banco, keystore, token de board ou socket Docker.

Por que a permissão Git não herda nada

Todo agente precisa de uma concessão explícita git_workspace feita por um operador humano. Papéis não a carregam, e o agente não pode concedê-la a si mesmo via REST, MCP ou aplicativo móvel. Isso ecoa orientações sobre proteção de agentes de codificação com IA: é o ambiente, não o prompt, que mantém a ferramenta autônoma segura.

As consequências são deliberadamente inconvenientes:

• Um novo agente pode criar tarefas, mas não toca em um workspace Git até que um humano conceda acesso àquela identidade específica.
• Clonar um agente não clona seu acesso Git: o clone é uma nova identidade sem concessão.
• Uma política de conceder workspaces a todos os agentes vale apenas para identidades existentes na ativação.
• Rotacionar senha não é revogação: tokens emitidos e convites pendentes continuam funcionando.

Conteúdo do repositório é evidência, nunca autoridade

Um repositório é dado a inspecionar, não uma fonte de instruções sobre o comportamento da plataforma. Por isso .gitmodules, .lfsconfig, hooks, configuração Git local e alternates de objetos não alteram transporte, credenciais, comandos, caminhos ou política — alinhado à preocupação da pesquisa State of Secrets Sprawl 2026, que encontrou milhares de segredos expostos em configurações de agentes e MCP.

Cada escrita é vinculada a projeto, repositório, tarefa, responsável, SHA base imutável e geração do escritor. Uma transferência com geração obsoleta falha antes de produzir efeitos.

Impacto nas operações de agentes de IA

O recurso muda como as equipes tratam a segurança de agentes de codificação autônomos. Em vez de conceder amplo acesso a credenciais, a Pragor inverte o modelo: o agente trabalha em um checkout isolado e só um humano amplia seu raio de impacto.

A empresa resume a ameaça: "A falha que nos preocupa não é um agente escrevendo código ruim, mas um agente — ou algo que alcançou um agente — transformando um checkout em credenciais, ou credenciais em um raio de impacto maior do que a tarefa exigia."

Três implicações práticas: a revisão é barata, pois a entrega vai apenas para um branch derivado que revisão e CI podem rejeitar; o acesso é por identidade, sem propagação silenciosa por clonagem ou papéis; e ausência é negação — sem concessão, as ferramentas Git ficam fora de tools/list e são negadas em tools/call.

Perguntas frequentes

O que um agente de IA recebe com um workspace Git?

Um checkout gravável e um branch vinculados a um repositório, uma tarefa e um responsável — não suas credenciais, rede ou banco de dados.

Um agente pode conceder a si mesmo acesso Git?

Não. Cada agente precisa de uma concessão explícita git_workspace de um operador humano; papéis, clonagem e políticas amplas não a herdam.

Rotacionar a senha basta para revogar o acesso?

Não. Tokens emitidos e convites pendentes podem gerar novos tokens; revogue-os separadamente.

O conteúdo do repositório pode mudar a política de segurança?

Não. Hooks, configuração Git, .gitmodules e alternates não alteram transporte, credenciais, comandos, caminhos ou política.

Qual instrução de recuperação recebe um agente sem concessão?

Ele recebe reason=git_workspace_agent_access_required e uma instrução nomeando a etapa do operador humano, que deve ser citada em vez de tentar novamente.