GitHub Copilot SDK: Prova de Conceito de Agente Governado

O GitHub moveu o Copilot SDK para disponibilidade geral em 2 de junho de 2026 e anunciou sandboxes em nuvem e locais para o GitHub Copilot em pré-visualização pública no mesmo dia. Essa combinação é mais importante do que outro título de "assistente de codificação AI": ela oferece às equipes de ferramentas de desenvolvedor um caminho credível para incorporar um runtime de agente enquanto separa o acesso às ferramentas, a política de aprovação, a identidade e o isolamento de execução.

Este artigo não é uma revisão prática do sandbox do Copilot. O Effloow Lab não se autenticou no GitHub Copilot, não criou uma sessão real do SDK, não executou o Copilot CLI e não iniciou um sandbox em nuvem. As evidências aqui são mais restritas e explícitas: pesquisa oficial de changelog/docs do GitHub, uma verificação do registro npm mostrando @github/copilot-sdk na versão mais recente 1.0.0, e um prompt de API da OpenAI salvo que gerou uma matriz de risco de implementação sintética para um runtime governado. O artefato do laboratório está salvo em data/lab-runs/github-copilot-sdk-sandboxes-agent-runtime-poc-2026.md.

Use isso como um modelo de PoC para decidir o que construir e o que verificar antes de permitir que um agente incorporado inspecione código, chame ferramentas MCP, execute comandos de shell ou mova a execução para um sandbox em nuvem.

O Que Você Vai Construir

O PoC alvo é um runtime de agente governado para um produto de ferramenta de desenvolvedor. O usuário abre um aplicativo web, aponta o agente para um repositório de exemplo e pede uma pequena tarefa de engenharia, como "inspecionar este repositório e resumir os riscos de migração." O runtime deve:

• criar uma sessão do Copilot SDK com uma configuração estável e auditável;
• expor apenas ferramentas MCP aprovadas;
• limitar o acesso ao sistema de arquivos a um espaço de trabalho temporário, como /tmp/agent-work;
• exigir aprovação humana antes de comandos de shell;
• tratar o conteúdo do repositório e das issues como entrada não confiável;
• opcionalmente iniciar uma sessão em nuvem apenas quando a política da organização permitir;
• registrar aprovações, negações, chamadas de ferramentas, falhas e decisões de política.

A anúncio do SDK do GitHub diz que o SDK GA fornece acesso programático ao runtime do agente Copilot para planejamento, invocação de ferramentas, edições de arquivos, streaming e sessões de múltiplas interações. A documentação do GitHub também mostra a configuração do SDK em TypeScript, Python, Go, .NET, Rust e Java. A verificação do npm neste fluxo de trabalho confirmou que @github/copilot-sdk existe com latest definido como 1.0.0.

A parte que falta não é "um agente pode responder a um prompt?" A parte que falta é se seu produto pode tornar o agente governável o suficiente para que um comprador confie.

Pré-requisitos

Você precisa de uma concessão do GitHub Copilot ou configuração BYOK que seja válida para o caminho do SDK que você escolher. A documentação de autenticação do GitHub descreve vários modos: um usuário do GitHub autenticado interativamente, tokens de usuário do aplicativo OAuth do GitHub, tokens baseados em ambiente e BYOK. Tokens de acesso pessoal clássicos ghp_ estão listados como não suportados na documentação de autenticação do SDK; não construa seu PoC em torno deles.

Para um scaffold em TypeScript, a documentação oficial de início rápido usa:

mkdir copilot-runtime-poc
cd copilot-runtime-poc
npm init -y --init-type module
npm install @github/copilot-sdk tsx

As evidências esperadas em nível de pacote desta execução do Effloow:

{
  "version": "1.0.0",
  "name": "@github/copilot-sdk",
  "dist-tags": {
    "latest": "1.0.0"
  }
}

O comportamento esperado em tempo de execução é [DADOS NÃO DISPONÍVEIS] até que você se autentique e execute o SDK em seu próprio ambiente. Essa distinção é importante. Uma instalação de pacote ou um scaffold baseado em documentação não prova que a política da sua organização, plano do Copilot, servidor MCP, configurações de sandbox ou concessão de sessão em nuvem funcionarão.

Passo 1: Defina o Plano de Controle

Comece com um documento de plano de controle antes de escrever o código do aplicativo. Para um PoC voltado para o comprador, essa é a diferença entre "incorporamos um agente" e "sabemos o que o agente pode fazer."

runtime:
  session_owner: authenticated_app_user
  default_execution: local
  cloud_execution: disabled_until_policy_allows
  repository_scope: sample_repository_only
tools:
  filesystem:
    type: mcp
    root: /tmp/agent-work
    access: read-write
  issue_reader:
    type: mcp
    access: read-only
  shell:
    enabled: approval_required
approval:
  shell_commands: human_required
  timeout_behavior: deny
logging:
  record_tool_calls: true
  record_approval_decisions: true
  redact_secrets: true

A saída esperada deste passo não é um agente em execução. É um contrato de controle pronto para aprovação. Se um fornecedor não pode explicar o escopo do repositório, o escopo das ferramentas, a identidade, as aprovações e os logs antes de demonstrar o agente, o PoC não está pronto para um comprador.

Passo 2: Crie a Sessão Mínima do SDK

A documentação de início rápido do GitHub mostra uma sessão mínima em TypeScript com CopilotClient, createSession e sendAndWait. Mantenha seu primeiro caminho de código simples:

import { CopilotClient } from "@github/copilot-sdk";

async function main() {
  const