O que é um token de capacidade e como limita um agente de IA doméstico?
Um token de capacidade concede autoridade baseada na posse sobre um recurso e uma operação específicos, limitando um agente ao retirar-lhe todas as capacidades que não lhe foram atribuídas.
Um agente doméstico pode precisar de ler um calendário, ligar ou desligar as luzes de uma divisão ou carregar uma cópia de segurança escolhida, sem receber uma credencial de administrador permanente. Um token de capacidade pode associar recurso, ação, expiração, orçamento e contexto numa concessão verificável. O gateway de ferramentas verifica essa concessão em cada chamada, pelo que apenas o texto do prompt não pode ampliar a autoridade do agente.
O Token Combina uma Referência a um Objeto com Autoridade
Uma capacidade identifica ou resolve um objeto protegido e transmite as operações permitidas a quem a possui legitimamente. Ao contrário de uma chave de API abrangente seguida de uma consulta interna a uma ACL, a própria concessão é deliberadamente restrita e impossível de falsificar.
A investigação sobre capacidades de objetos descreve o modelo de capacidades de objetos como uma forma de codificar direitos de acesso em objetos individuais para restringir as interações. Os descritores de ficheiros são um exemplo local familiar: autorizam o acesso a um objeto já aberto sem conceder autoridade arbitrária para nomear elementos do sistema de ficheiros.
Uma capacidade pode coexistir com identidade e política. A identidade responde a quem está envolvido; a capacidade responde a qual autoridade concreta foi delegada para esta operação. Esta distinção continua visível durante os testes domésticos posteriores.
A Atenuação Restringe a Delegação sem a Ampliar
Um serviço principal pode derivar um token filho restrito a um caminho mais pequeno, a um método apenas de leitura, a uma expiração mais curta, a um orçamento inferior ou a um contexto de pedido específico. O filho pode delegar menos autoridade, mas não pode remover restrições nem criar direitos mais amplos.
Os Macaroons introduzem uma autorização atenuada que suporta restrições contextuais e delegação descentralizada. A verificação confirma a cadeia de assinaturas e todas as restrições antes de o servidor de recursos aceitar um pedido. O resultado intermédio tem de continuar a ser inspecionável antes de a automatização prosseguir.
Isto é útil para agentes porque um planeador pode receber uma capacidade de sessão e transmitir um derivado específico da tarefa a um subprocesso de uma ferramenta. O subprocesso nunca precisa da credencial raiz no seu prompt ou ambiente. Essa fronteira deve ser medida separadamente em condições de funcionamento realistas.
A Posse, a Delegação e a Revogação Continuam a Ser Fronteiras de Segurança
Qualquer pessoa que roube uma capacidade de portador pode utilizá-la até à expiração ou revogação. Os tokens precisam de transporte e armazenamento protegidos, de uma vinculação ao público ou ao canal quando apropriado, de períodos de validade curtos e de identificadores de auditoria. A consequência prática surge quando várias fontes competem por um contexto limitado.
Uma análise da segurança baseada em capacidades explica a distinção entre autoridade baseada em capacidades e controlos centrados na identidade. O modelo reduz a autoridade ambiente, mas não avalia se a ação solicitada por um agente reflete a verdadeira intenção do utilizador. Esta dependência deve permanecer explícita na interface final.
A fronteira de falha é um token demasiado abrangente, reutilizável ou divulgado. As verificações de capacidades não podem impedir uma utilização prejudicial que esteja abrangida pela concessão, pelo que as ações consequenciais continuam a precisar de validação do destino, aprovação, limites de frequência e revogação observável. O resultado deve, por isso, ser verificado face às evidências originais.
Faça o Inventário da Autoridade por Token, Ferramenta e Pedido
Para cada chamada de ferramenta, registe o emissor, o sujeito ou titular, o público, o recurso, a operação, o âmbito do caminho, o orçamento, a expiração, a cadeia de delegação, as restrições, o identificador de revogação, o requisito de aprovação e o ID de auditoria. Esta distinção continua visível durante os testes domésticos posteriores.
Compare a concessão com a segurança baseada em capacidades. Teste a travessia de caminhos, a alteração do ID do dispositivo, a substituição do método, a repetição, um token expirado, um token filho roubado, um verificador offline, um principal revogado e um pedido permitido mas de elevado impacto. O resultado intermédio tem de continuar a ser inspecionável antes de a automatização prosseguir.
Prossiga apenas quando cada ferramenta receber a concessão mínima e não puder ampliá-la. Considere o sucesso da capacidade como autorização, não como prova da intenção do utilizador, da segurança semântica ou da correção do resultado da ferramenta. Essa fronteira deve ser medida separadamente em condições de funcionamento realistas.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Um LLM local pode retomar a geração depois de o seu processo reiniciar?
Uma explicação da retoma da geração de LLM baseada primeiro no mecanismo, das suas concessões em termos de recursos partilhados, de três perguntas frequentes...
Pode um servidor doméstico executar embeddings e transcodificação de vídeo na mesma GPU integrada?
Uma explicação baseada primeiro no mecanismo dos embeddings partilhados da iGPU e da transcodificação, das suas cedências em termos de recursos partilhados, três perguntas...
Como é que o tempo de vida do token de acesso afeta a segurança e o atrito no agregado familiar?
Uma explicação baseada primeiro no mecanismo da duração dos tokens de acesso, os compromissos relativos aos recursos partilhados, três perguntas frequentes sobre a propagação...
