Entregue a um agente uma credencial com escopo

Esta é a metade de credenciais do Controle de Mudanças Seguro para Agentes: como cunhar uma chave que um agente possa portar com segurança e entregá-la sem vazar uma mais forte. A metade de imposição — orçamentos, faixas, análise de risco, política de promoção — é Guardrails. Disponível hoje.

Uma credencial segura para agentes é uma chave de API Kisenon com três limites — capacidade, escopo e expiração — entregue ao agente em um ambiente limpo. A regra em uma linha: dê escopo à credencial do agente e não deixe uma mais forte onde o agente possa alcançá-la.

1. Provisione uma credencial de agente com escopo

Cunhe uma chave de API com todas as três dimensões definidas:

• capability = agent — pode operar sandboxes, mas keon connection-string main (e toda rota de main gravável) retorna 403. O agente pode propor mudanças; ele nunca porta uma credencial que grava em produção.
• scope = project — confinada a um único projeto. Um vazamento não pode alcançar seus outros projetos.
• expires_at (curto) — um raio de destruição limitado em caso de vazamento. Dias, não para sempre.

Cunhe-a no console — Configurações → Chaves de API em kisenon.com — com Capacidade = agent, Escopo = um projeto e Expira definido. As chaves de API são cunhadas a partir de uma sessão de navegador autenticada; uma chave de CLI simples não pode cunhar outra chave. Usar a chave em uma rota de main gravável retorna exatamente:

agent-scoped API keys cannot retrieve data-plane credentials or perform
branch-admin role/database operations; use the sandbox flow

2. Entregue-a ao agente corretamente

Dê ao agente sua chave com escopo como sua única credencial, em um shell ou contêiner limpo:

export KEON_API_KEY=nsk_<agent-key>   # the scoped agent key, and ONLY this
unset DATABASE_URL                    # no full connection string in the env
# also: no personal `keon login` session (no ~/.config/keon/credentials.json),
# no ~/.pgpass, no admin DATABASE_URL reachable from the agent's process.

Regra em duas partes, ambas obrigatórias:

• Dê escopo à credencial que você entrega ao agente (passo 1).
• Remova as mais fortes que ele poderia, de outro modo, captar — um DATABASE_URL completo, um ~/.pgpass ou uma sessão keon autenticada no mesmo shell.

3. O laço seguro

O agente propõe; um humano — ou sua própria promoção limitada — dispõe:

keon sandbox run \
  --migrate "alembic upgrade head" \
  --verify  "pytest tests/db"

keon sandbox run bifurca a branch, cunha um token de agente de vida curta em um home isolado e injeta a URL com escopo da bifurcação como DATABASE_URL para seu comando — de modo que até um comando que tente keon connection-string main dentro do sandbox esbarra na chave do agente e recebe 403. Revise o diff capturado e então promova conforme o promote_mode do projeto:

Ative a revisão humana com keon projects update --promote-mode human.

O que isto é (e o que não é)

• Uma proteção para um agente cooperativo, não uma prisão para código hostil. Dar escopo à credencial limita o que você entrega ao agente; não contém um subprocesso que já tem acesso ao sistema de arquivos ou à rede do host. A contenção real — um ambiente higienizado, sem acesso às credenciais do host, saída limitada ao endpoint do sandbox — é uma camada separada. Adicione-a também quando o código do agente não for confiável.
• cp é o único que grava em main. A promoção reexecuta as instruções capturadas no lado do servidor; o agente nunca porta uma credencial com gravação em main.

Quebra de vidro

Não há um interruptor especial de "quebra de vidro", por design. O caminho direto de gravação em main é apenas uma credencial read_write normal portada por um humano (keon connection-string main, ou o console) — deliberadamente inalcançável a partir da chave do agente. Para um caminho de incidente auditado, um operador usa sua própria sessão read_write; cada promote e approve é atribuído no lado do servidor.