As permissões explícitas tornam os agentes domésticos mais seguros, convertendo uma decisão incerta do modelo numa verificação de autorização separada e determinística antes de uma ferramenta poder atuar.
Um agente doméstico pode ler calendários, mudar o nome de ficheiros, controlar fechaduras, enviar mensagens ou executar comandos. O modelo pode propor estas ações, mas a sua confiança não lhe concede autoridade. Uma camada de políticas avalia o utilizador, a ferramenta, o recurso, os argumentos e o risco no momento da execução, permitindo leituras normais e exigindo aprovação recente para operações destrutivas, irreversíveis ou sensíveis em termos de privacidade.
Uma Chamada de Ferramenta é uma Proposta, Não uma Permissão
O modelo produz uma intenção estruturada, como “eliminar o ficheiro X” ou “destrancar a porta Y”. A autorização avalia se esse sujeito específico pode executar essa ação sobre esse objeto nas condições atuais. Separar estas etapas impede que texto persuasivo, instruções obtidas através de pesquisa ou um erro de planeamento se transformem em autoridade.
As orientações sobre acesso ao âmbito da tarefa definem o acesso do agente em torno dos recursos e ações necessários para a tarefa atual, e não de todas as capacidades que o agente poderá vir a utilizar. As credenciais limitadas à tarefa reduzem os danos possíveis de uma chamada incorreta ou manipulada.
A diferença observável é um percurso de negação. Um agente seguro deve conseguir explicar que uma ação foi proposta, mas bloqueada, sem improvisar outra ferramenta nem alargar silenciosamente o âmbito para concluir o objetivo. Essa distinção altera a decisão doméstica resultante.
Regras Explícitas Tornam as Condições de Risco Testáveis
Uma política pode corresponder à classe de ação, ao destino, à hora, ao montante, à sensibilidade dos dados e à reversibilidade. Ler um termóstato pode ser automático; alterar o seu horário pode exigir a confirmação do proprietário; destrancar uma porta exterior pode exigir a presença de alguém e uma confirmação recente. Assim, a mesma ferramenta recebe decisões diferentes consoante os argumentos.
Uma análise sobre aplicação de políticas em várias camadas recomenda controlos ao nível do pedido, do plugin, do conector, da identidade e da rede. Várias camadas são importantes porque uma permissão da aplicação pode limitar a chamada à API, enquanto a política de rede bloqueia um destino inesperado.
A explicitação também melhora a auditoria. Os registos podem incluir a ação solicitada, a regra avaliada, a identidade que aprovou, os argumentos finais e o resultado. “O modelo decidiu” passa a ser uma decisão de política reproduzível que uma família pode inspecionar e rever. Esta fronteira continua visível durante uma análise posterior das provas.
Quando os Pedidos de Permissão se Tornam Teatro de Segurança
A aprovação é fraca quando os pedidos são constantes, vagos ou apresentados depois de os detalhes importantes terem sido ocultados. Os utilizadores habituam-se a clicar em permitir, enquanto um agente pode agrupar uma operação segura com outra sensível e sem relação. Os tokens persistentes e abrangentes também contornam a aparente segurança dos pedidos por ação.
A análise jurídica dos agentes autónomos salienta controlos baseados no menor privilégio, o registo de atividades, listas de ferramentas aprovadas e supervisão humana antes do processamento sensível. Uma caixa de diálogo de confirmação não pode compensar credenciais que já permitam acesso irrestrito em segundo plano. Esta dependência deve, por isso, ser medida separadamente na prática.
A fronteira é clara: a aprovação só ajuda quando é específica, atempada e aplicável abaixo do modelo. Se a recusa não impedir a execução, ou se o utilizador não conseguir ver o alvo e a consequência, a interface regista consentimento sem proporcionar controlo.
Execute uma Matriz de Fronteiras de Permissões
Defina quatro ações de teste para uma ferramenta: leitura permitida, escrita permitida, ação destrutiva que exige aprovação e transferência externa proibida. Execute cada uma com argumentos válidos e, em seguida, repita-a com uma alteração no caminho, no destinatário ou no montante que deva atravessar a fronteira da política.
Mantenha os resultados num registo imutável, aplicando a abordagem de verificação descrita para ações de ferramentas verificadas. O registo deve mostrar a proposta, a decisão da política, a aprovação, se aplicável, os argumentos executados, o resultado da ferramenta e se o agente verificou esse resultado.
Considere aprovado apenas se as ações permitidas forem concluídas com êxito, as ações negadas não produzirem efeitos secundários, as aprovações ficarem associadas aos argumentos apresentados e as credenciais reutilizadas não conseguirem contornar uma negação posterior. Repita a matriz sempre que as ferramentas, as identidades ou os papéis domésticos forem alterados.
Centro de Tecnologia e IA
Mais para Ler

Embeddings multilingues: como um único espaço vetorial liga documentos domésticos em diferentes idiomas
Veja como os embeddings alinhados ligam documentos entre idiomas, por que a qualidade da recuperação varia e como testar localmente a cobertura de evidências...

Conflitos na memória do agente: por que motivo correções recentes podem perder para factos antigos repetidos
Saiba como memórias antigas duplicadas se sobrepõem às correções, onde as regras de recência falham e como testar a substituição num armazenamento privado de...

Reclassificação da pesquisa privada: como um segundo modelo altera a ordem final das evidências
Veja por que razão a semelhança da primeira fase e a relevância da segunda fase divergem, quando a reordenação melhora o RAG privado e...

