Como é que o controlo de acesso baseado em capacidades limita as permissões das ferramentas dos agentes?
O controlo de acesso baseado em capacidades limita um agente ao transformar a autoridade numa capacidade explícita e vinculada a um recurso, em vez de uma permissão implícita herdada por cada chamada de ferramenta.
Num servidor doméstico, isso pode permitir que um agente inspecione um destino de cópia de segurança, outro reinicie um serviço específico e um terceiro leia uma pasta de fotografias, sem partilharem uma credencial principal.
Uma capacidade vincula a autoridade a um recurso específico
O controlo de acesso baseado em capacidades representa a autoridade como um token ou uma referência que identifica um objeto e inclui os direitos disponíveis sobre esse objeto.
O seL4 descreve uma capacidade como um token impossível de falsificar que concede permissão para aceder a uma entidade ou objeto. A posse faz parte do mecanismo de autorização. O seL4 representa a autoridade através de capacidades que referenciam objetos específicos do kernel, fornecendo um exemplo concreto de autoridade vinculada a recursos no modelo de capacidades do seL4.
Para um agente de IA doméstico, uma ferramenta de cópia de segurança pode receber autoridade para um único repositório, em vez de acesso implícito a todo o sistema de ficheiros. Conhecer apenas um caminho não concede permissão.
A posse substitui a autoridade implícita por delegação explícita
Os ambientes tradicionais expõem frequentemente autoridade implícita através das credenciais dos processos ou de tokens de API abrangentes.
Os sistemas de capacidades tornam a autoridade explícita nas referências que um componente realmente possui.
O capDL do seL4 descreve que partes de um sistema possuem capacidades para outras partes. Essas distribuições definem limites de controlo de acesso. O Wasmtime descreve o isolamento orientado por capacidades para recursos WASI, ilustrando como a posse explícita pode substituir o acesso implícito abrangente no modelo de segurança baseado em capacidades do Wasmtime.
Assim, um subagente de organização de fotografias pode receber acesso de leitura a uma pasta de importação e acesso de escrita à área de preparação, sem obter autoridade para eliminar itens do arquivo.
Os direitos podem ser mais restritos do que o recurso
Uma capacidade pode incluir direitos que limitam as operações disponíveis no objeto referenciado.
Dois agentes podem possuir capacidades para o mesmo objeto com diferentes níveis de autoridade.
O seL4 explica que uma capacidade encapsula uma referência a um objeto, juntamente com direitos de acesso que controlam as operações permitidas. A Bytecode Alliance descreveu a WASI com base na segurança baseada em capacidades, apoiando a ideia de que os direitos concedidos podem ser mais restritos do que o próprio recurso do anfitrião em segurança WASI baseada em capacidades.
Um fluxo de monitorização pode ter autoridade para ler o estado, enquanto um fluxo de manutenção tem autoridade para reiniciar. O serviço é o mesmo; as operações disponíveis não são.
A delegação pode entregar uma capacidade mais limitada a uma subtarefa
Os sistemas de capacidades adequam-se à decomposição de agentes porque a autoridade pode ser transmitida juntamente com o trabalho. Um agente principal pode delegar apenas o que um auxiliar precisa, em vez de encaminhar uma credencial principal.
O Cap'n Proto trata as referências RPC como referências que também transmitem autoridade para chamar um objeto. Passar a referência passa uma capacidade específica. O RPC do Cap’n Proto trata as referências a objetos como capacidades que podem ser transmitidas a outros componentes, constituindo um modelo útil de autoridade delegada em capacidades de objetos do Cap’n Proto.
Um auxiliar a quem foi pedido que inspecione um diretório de registos pode receber uma capacidade de leitura apenas para esse diretório. O seu pedido pode mencionar outros recursos, mas a autoridade não pode expandir-se com base nesse pedido.
Os mecanismos de capacidades e o âmbito das ferramentas são camadas diferentes
O âmbito das ferramentas é uma escolha de política sobre o grau de restrição que deve ter uma ação do agente.
O controlo de acesso baseado em capacidades é um mecanismo de execução para representar e impor essa autoridade.
A análise do âmbito das ferramentas dos agentes de IA domésticos da ZimaSpace explica por que motivo o âmbito da ação, do recurso, dos argumentos e das credenciais deve ser reduzido à medida que a autonomia aumenta. O trabalho atual no âmbito de um rascunho do IETF sobre tokens de agentes com autoridade reduzível explora a autoridade delegada que pode ser limitada para agentes a jusante, ilustrando o limite da delegação no rascunho sobre tokens de agentes com autoridade reduzível.
A aplicação de capacidades continua a ser importante quando a lógica do agente falha. A análise dos ciclos repetidos de chamadas de ferramentas da ZimaSpace mostra por que motivo as falhas comportamentais e os limites de autoridade devem ser tratados separadamente.
A revogação e as APIs antigas continuam a ser limites de implementação
Os sistemas práticos continuam a precisar de formas de revogar autoridades perdidas, fazer expirar o acesso temporário e interligar serviços que apenas compreendem utilizadores, funções ou tokens portadores.
O seL4 expõe operações de derivação e eliminação de capacidades, mas o comportamento da revogação depende da arquitetura envolvente. O projeto cap-std expõe recursos externos como valores de capacidade, em vez de globais implícitas, mostrando também que as APIs antigas e a revogação continuam a ser preocupações de engenharia distintas nas APIs baseadas em capacidades do cap-std.
Um invólucro de capacidades em torno de uma API de NAS só é tão forte quanto o gateway que está por trás dele. Se cada pedido utilizar, em última instância, um token de administrador sem restrições, a granularidade aparente pode desaparecer abaixo desse limite.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Estado em tempo de execução vs. estado persistente no Home Assistant: o que tem de sobreviver ao reinício?
O Home Assistant não persiste todos os valores em tempo real; a configuração, os registos, os estados restaurados selecionados, o histórico e os dados...
Como é que o Home Assistant autentica sessões locais e remotas?
As sessões locais e remotas do Home Assistant utilizam o mesmo modelo de identidade do lado do servidor; o acesso remoto altera a rota...
Porque é que as consultas ao histórico do Home Assistant podem ficar mais lentas à medida que os dados do Recorder aumentam?
O crescimento do gravador pode aumentar o custo das consultas do Histórico quando o intervalo solicitado abrange mais linhas, as falhas de cache aumentam...
