Entregar a um agente uma credencial delimitada

Esta é a metade de credenciais dos sandboxes de agentes de IA: como cunhar uma chave que um agente pode segurar com segurança e como entregá-la sem vazar uma mais forte. Disponível hoje.

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

1. Provisionar uma credencial de agente delimitada

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

• capability = agent — pode operar sandboxes, mas keon connection-string main (e toda rota com escrita em main) retorna 403. O agente pode propor mudanças; ele nunca segura uma credencial que escreve em produção.
• scope = project — confinada a um único projeto. Um vazamento não pode alcançar os seus outros projetos.
• expires_at (curto) — um raio de impacto 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ção definida. 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 com escrita em main retorna exatamente:

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

2. Entregá-la ao agente corretamente

Dê ao agente sua chave delimitada 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:

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

3. O laço seguro

O agente propõe; um humano — ou seu próprio promote delimitado — decide:

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

keon sandbox run bifurca o branch, cunha um token de agente efêmero em um home isolado e injeta a URL delimitada da bifurcação como DATABASE_URL para o 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 cadeia para código hostil. Delimitar a 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 escreve em main. A promoção reexecuta as instruções capturadas no lado do servidor; o agente nunca segura uma credencial com escrita em main.

Quebra de vidro

Não há um botão especial de "quebra de vidro", por design. O caminho direto com escrita em main é apenas uma credencial read_write normal nas mãos de 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.