Chaves de agentes precisam de orçamentos de risco

O repositório shuriken-skills da Shuriken empacota instruções para Claude Code, Codex CLI, GitHub Copilot CLI, Gemini CLI, Cursor, OpenCode e agentes compatíveis com AGENTS.md.¹ O repositório também aponta esses agentes para uma plataforma em que chaves de agente podem ler dados de mercado, inspecionar carteiras, solicitar cotações e executar operações quando o usuário concede essa capacidade.²

A parte importante não é o trading. A parte importante é o padrão: agentes agora precisam de credenciais para ferramentas capazes de gerar efeitos externos reais. Uma chave de agente não deve se comportar como uma chave de API comum. Ela deve se comportar como um orçamento de risco.

Uma chave de agente é um objeto de autoridade delimitada. Ela deve dizer o que o agente pode fazer, o que não pode fazer, quanto risco pode criar, como operadores podem inspecionar suas ações e com que rapidez alguém pode pausar, rotacionar ou revogar essa chave. Instruções de prompt ajudam, mas os limites no servidor sustentam a fronteira.

Resumo

MCP e skills portáteis facilitam a conexão de agentes a sistemas externos.³⁴ Essa portabilidade aumenta o peso das credenciais. A documentação da Shuriken descreve o formato correto de controle para ferramentas perigosas: criar uma chave de agente, conceder apenas as permissões necessárias, aplicar limites no servidor, registrar atividade e revogar a chave quando a integração não precisar mais dela.²⁵⁶ Pesquisas recentes sobre privilégio mínimo apontam na mesma direção: skills podem executar ações que excedem o escopo mínimo de uma tarefa específica, então a permissão precisa se tornar sensível à tarefa, não ampla para o pacote inteiro.⁹

A lição vale fora do mercado financeiro. Qualquer ferramenta de agente que envia dinheiro, publica conteúdo, altera infraestrutura, manda mensagens para clientes ou toca dados privados precisa de uma chave com escopo e orçamento de risco. Esse orçamento fica abaixo do modelo e abaixo do arquivo de skill. O servidor deve rejeitar ações não autorizadas mesmo quando o agente pede com confiança.

Principais pontos

• Para quem constrói ferramentas de agente: projete credenciais como orçamentos de capacidade, não como bearer tokens de uso geral.
• Para equipes de segurança: separe escopos de leitura de escopos de escrita ou execução, depois aplique limites de gasto, taxa e objeto no lado de execução.
• Para equipes de produto: mostre registros de atividade e controles de revogação na UI principal, não em uma página de configurações escondida.
• Para quem constrói MCP: trate a distribuição de ferramentas e a autoridade de credenciais como planos diferentes. Skills podem ensinar. Chaves precisam limitar.
• Para operadores: comece em modo somente leitura, comprove o caminho de integração e só então adicione acesso de escrita quando o plano de resposta existir.

Skills distribuem instruções. Chaves distribuem autoridade.

O repositório shuriken-skills mostra o novo padrão de distribuição. Uma única árvore de código contém Markdown de skills, manifestos de plugin para Claude e Codex, um manifesto de plugin para Cursor, um arquivo de extensão para Gemini, um plugin para OpenCode, um crate Rust e um caminho alternativo via AGENTS.md.¹⁷

Esse empacotamento importa porque instruções de agente agora viajam entre clientes. Um fornecedor pode ensinar Codex, Claude Code, Cursor, Gemini e outras ferramentas a integrar com a mesma API. A documentação de MCP descreve skills de agente como conjuntos portáteis de instruções que dão conhecimento de domínio a assistentes de código, incluindo decisões de design sobre modelo de implantação, fluxos de autenticação e padrões de ferramentas.⁴ Escrevi sobre o lado da distribuição em Skills de agentes precisam de gerenciadores de pacotes; o lado da segurança começa quando esses pacotes pedem autoridade real.

Instruções portáteis resolvem um problema e criam outro. Elas ajudam um agente a aprender o caminho certo de integração. Elas não tornam segura a ação resultante. Uma skill pode dizer ao modelo para usar privilégio mínimo. Um prompt pode dizer “tenha cuidado”. Um README pode explicar escopos recomendados. Nenhum desses controles impede uma requisição autenticada depois que o modelo decide enviá-la.

Essa tensão corresponde ao problema mais amplo de MCP em Servidores MCP são a nova superfície de ataque: o acesso a ferramentas expande a superfície de ação mais rápido do que velhos hábitos de aprovação conseguem acompanhar. Skills de agentes tornam portátil o caminho de instrução. O sistema de chaves precisa manter estreito o caminho de autoridade.

É por isso que credenciais precisam de um design próprio. O arquivo de skill vive no plano de instrução. A chave de agente vive no plano de autoridade. Misturar esses planos cria um sistema frágil: o mesmo texto que ensina o agente o que fazer também tenta impedir que ele faça demais.

A fronteira pertence ao servidor.

O padrão da Shuriken é um orçamento de risco

A documentação do Agent Kit da Shuriken descreve a chave de agente como o objeto que controla o que uma ferramenta de IA pode fazer, desde ler preços de tokens até executar operações, com limites aplicados no servidor antes que o agente comece a agir.⁵ A página de permissões nomeia seis categorias de permissão e afirma que chamadas fora do escopo concedido falham com erro de autorização.⁶

Esse enquadramento também evita um erro comum em demonstrações públicas de agentes: tratar código aberto, instruções visíveis ou um manifesto de plugin legível como a fronteira. A abertura pode ajudar na revisão, mas código aberto não é uma fronteira de segurança. A fronteira vive onde ações não autorizadas falham.

Esse padrão tem cinco partes:

Esse é o formato certo para ferramentas de agente de alto risco. O design não depende de o modelo se tornar sábio. O design assume que o modelo pode estar errado, confiante demais, comprometido por entrada externa ou simplesmente receber uma instrução ruim. O servidor ainda aplica a chave.

Eu copiaria o padrão de controle, não o domínio. Uma chave de implantação, uma chave de publicação, uma chave de mensagens para clientes, uma chave de reembolso no Stripe e uma chave de trading precisam todas da mesma pergunta: qual é o dano máximo que esta chave pode criar antes que um humano perceba?

Limites no servidor vencem promessas de prompt

A documentação do OpenAI Agents SDK apresenta guardrails como verificações que podem rodar ao redor de um agente, incluindo guardrails de entrada e saída com tripwires.⁸ Guardrails ajudam porque capturam riscos antes ou depois da execução do modelo. Ainda assim, ocupam uma camada diferente da autoridade de credenciais.

Um guardrail de saída pode sinalizar uma ação proposta ruim. Um limite de chave no servidor pode rejeitar a ação mesmo se o guardrail não perceber. Essa distinção importa quando a ação sai do texto.

Considere uma ferramenta que pode publicar um post, enviar um email, alterar um registro DNS, fazer merge de um pull request ou executar uma operação. Uma regra de prompt pode dizer “peça antes”. Um guardrail pode procurar texto de alto risco. Uma chave no servidor pode aplicar o limite real:

A regra de prompt pode falhar em silêncio. A fronteira no nível da chave cria uma rejeição observável. Essa rejeição vira evidência. O agente tentou exceder o escopo. O servidor recusou. O operador pode inspecionar a requisição com falha e decidir se a integração precisa de uma nova chave, um fluxo de trabalho mais estreito ou uma etapa de aprovação humana.

É a mesma lógica por trás de A barreira da evidência: confiança deve vir de prova observável, não de confiança declarada. Uma resposta final dizendo “fiquei dentro dos limites” vale menos do que um log do servidor mostrando qual limite foi acionado.

Isso também transforma a resposta final em algo mais próximo de um pacote de revisão. Pacotes de revisão são a nova resposta final argumenta que trabalho sério com agentes precisa de artefatos de evidência. Rejeições de credenciais, registros de atividade e mudanças em chaves com escopo são a versão de segurança desse artefato.

O formato mínimo para credenciais de agentes

Qualquer credencial de agente que possa afetar o mundo externo deve carregar seis propriedades.

As skills da Shuriken dizem a mesma coisa em linguagem de integração: crie uma chave por integração, conceda escopo mínimo, mantenha chaves em segredo, rotacione após suspeita de comprometimento e revogue integrações aposentadas.⁷ A skill de escopo deles também separa escopos de leitura de escopos de trading e alerta contra chaves amplas “só por garantia”.⁷

O vocabulário de pesquisa está alcançando o padrão de produto. O artigo SkillScope descreve excesso de privilégio como algo condicionado à tarefa: a mesma ação de uma skill pode ser válida para um pedido de usuário e excessiva para outro.⁹ Os autores relatam 7.039 skills com comportamentos de excesso de privilégio validados e uma redução de 88,56% nas instâncias acionadas de ações com excesso de privilégio após restringir privilégios por meio do framework deles.⁹ Você não precisa copiar esse mecanismo exato para aceitar a lição de produto. Credenciais de agentes devem refletir o trabalho atual, não o maior trabalho possível que a ferramenta consegue imaginar.

Essa orientação deve virar design normal de produtos com agentes. Chaves de API amplas faziam sentido quando um serviço de backend possuía um caminho de código estreito. Agentes não se comportam como um caminho de código estreito. Eles planejam, tentam de novo, compõem ferramentas, resumem falhas, chamam scripts auxiliares e respondem a entradas externas. A credencial deve assumir mais variação de comportamento do que um token de serviço comum.

Essa variação é o motivo pelo qual Busca de código por agentes tem um problema de orçamento de tokens importa até em um artigo sobre credenciais. Agentes muitas vezes decidem com contexto parcial. Uma chave estreita dá ao sistema uma segunda chance quando a janela de contexto perde o detalhe perigoso.

O que não copiar

Não copie o otimismo de marketing.

A documentação pública da Shuriken usa linguagem forte sobre agentes agindo enquanto usuários estão ausentes e capturando oportunidades.² Essa formulação pode fazer sentido para o produto deles. Ela não deve virar a postura padrão de segurança para ferramentas de agente que criam efeitos externos.

Para ações de alto risco, “enquanto você está ausente” precisa ter um sentido operacional mais estreito:

• o agente pode coletar informações enquanto o usuário está ausente;
• o agente pode preparar um rascunho de ação enquanto o usuário está ausente;
• o agente só pode executar dentro de um orçamento pequeno, explícito e aplicado pelo servidor;
• o operador pode inspecionar todas as ações depois;
• o operador pode pausar ou revogar a chave imediatamente.

Essa é a diferença entre autonomia e abdicação. O usuário pode delegar ação. O sistema não pode delegar responsabilidade.

O mesmo cuidado vale para skills e manifestos de plugin. Um repositório pode oferecer suporte a todos os clientes de agente e ainda merecer um padrão conservador. O .codex-plugin/plugin.json que inspecionei lista capacidade de leitura nos metadados da interface, enquanto a documentação explica que trading exige permissões e limites habilitados explicitamente.⁷ Essa é a direção certa: a distribuição pode ser ampla enquanto a autoridade começa estreita.

A regra de decisão

Quando uma nova integração de agente pedir uma credencial, classifique a chave antes de emiti-la.

Essa tabela dá ao agente um caminho utilizável sem fingir que o próprio modelo sustenta a fronteira. O fluxo de trabalho ainda pode melhorar. A chave impede que a melhoria vire autoridade sem limites. Rastreamentos de execução de agentes são o contrato do ambiente de execução defende o mesmo ponto pelo lado da auditoria: se o sistema não consegue mostrar o que aconteceu, não consegue provar que o agente agiu dentro do contrato pretendido.

Escrevi sobre a mesma divisão em Segurança de isolamento para agentes é uma sugestão: um modelo pode operar inteiramente dentro das permissões concedidas e ainda criar um resultado inseguro. Chaves de agentes precisam de orçamentos de risco porque permissão não é a mesma coisa que segurança.

FAQ

Chaves de agentes são apenas chaves de API com outro nome?

Não. Uma chave de API comum muitas vezes concede acesso amplo a um serviço. Uma chave de agente deve conceder um conjunto limitado de capacidades para uma integração, com limites no servidor, registros de atividade e revogação que não afete a sessão principal do usuário.

Por que a aplicação no servidor importa?

O servidor vê a requisição final. Uma instrução de modelo, um arquivo de skill ou um guardrail pode deixar passar uma ação ruim. Uma verificação de permissão no servidor pode rejeitar a requisição quando a chave não tem o escopo necessário ou excede um limite configurado.⁶

Todo agente deve começar somente leitura?

Sim, quando a ferramenta tem efeitos externos relevantes. Comece com acesso somente leitura, verifique o caminho de integração e só então adicione permissões de escrita ou execução, depois que a equipe souber quais logs, limites, aprovações e etapas de rollback existem.

MCP torna credenciais de agentes mais arriscadas?

MCP facilita conectar ferramentas externas entre clientes.³ Essa conveniência aumenta a importância do design de credenciais. Acesso portátil a ferramentas deve vir com chaves estreitas, não com confiança mais ampla.

O que as equipes devem copiar da Shuriken?

Copie a separação entre distribuição de instruções e autoridade no servidor: skills portáteis podem ensinar a integração, enquanto chaves com escopo, limites, logs e revogação restringem a ação. Não copie comportamento de trading específico do domínio a menos que os controles de produto, legais e operacionais justifiquem isso.

Referências