LAMP: Least-Authority Module Protocol

1O problema: permissão sobre texto

Quando um agente recebe um shell, a concessão é uma comparação de texto — esta linha de comando parece segura. Mas texto não delimita efeitos: o mesmo binário lê e destrói, a credencial viaja com a invocação, e cada comando novo é uma negociação nova. O resultado é conceder demais (uma aprovação ampla) ou atrito (uma confirmação por linha), e em ambos os casos o registro do que foi de fato alcançado é reconstruído dos logs depois do fato, se tanto.

A unidade correta de permissão não é o comando, e sim a capacidade: quais hosts, quais caminhos, quais binários, quais bancos de dados — como efeitos, aplicados abaixo do programa, não prometidos por ele.

2O protocolo: três partes, quatro verbos

LAMP não é um protocolo de fio; é um protocolo de autoridade — um acordo sobre como a capacidade é declarada, concedida, estreitada e registrada. Três partes participam, e nenhuma precisa confiar nas outras duas:

• O autor
  declara. O manifesto fixa o teto da lamp — cada família de efeito que ela poderá tocar (net, file, exec, db…), delimitada por padrão.
• O operador
  concede — uma vez. Um teto de projeto e um teto de sessão, escritos por um humano, delimitam tudo o que roda. Habilitar uma lamp é um ato humano, nunca uma ferramenta que um agente possa chamar.
• O runtime
  faz cumprir e audita. O programa roda sob a interseção dos três tetos. Cada checagem — concedida ou negada — volta como dados estruturados e é acrescentada ao registro.

3O invariante

Tudo se reduz a uma desigualdade, verificada em tempo de execução pela camada abaixo do programa:

o que roda ⊆ o que o código pede ∩ o que cada teto permite

A interseção é o único operador de composição. Uma lamp pode estreitar o que recebeu e nunca pode ampliá-lo; uma dependência roda sob o teto efetivo do pai, então a composição não pode escalar privilégios. Execução sem limite (exec sem binário nomeado) é recusada no carregamento, sem condições — o buraco nunca foi a execução, foi a execução sem nada a delimitá-la.

• exec=gitconcedido
• env=LAMP_*concedido
• stdoutconcedido
• secret("*")negado
• net(collector…)negado
• file.read("/*")negado

4A unidade: uma lamp

Uma lamp é uma pasta — pequena o bastante para ser lida inteira antes de executar qualquer coisa:

O mesmo manifesto serve o humano e o agente — lamp run git log em um terminal e lamp_git_log() atrás de uma ferramenta chegam ao mesmo contrato. Não há uma implementação de CLI e outra de agente para divergirem: a lamp é a fonte da verdade.

5Inspeção antes da execução

Como o teto é texto no manifesto e os pedidos são texto no código, a promessa de uma lamp pode ser verificada antes de habilitá-la — um lint sobre famílias, deixando o casamento de padrões para o runtime, que é quem decide de fato:

Confiar, sob LAMP, nunca significa “confio neste desenvolvedor”. Significa “entendo o que esta lamp pode alcançar, e o runtime vai sustentar esse limite” — mesmo que o código seja malicioso, o modelo esteja confuso ou a lamp tenha um bug.

6Distribuição

Uma lamp é distribuída como arquivos, não como um ecossistema: o manifesto os lista, o instalador os busca um a um de um host git comum, hasheia cada um e registra o resultado. Tags do git dão as versões (lamp pull owner/repo@v1.2.0); um registro — quando existir — é uma vitrine sobre os mesmos bytes, cujo trabalho é responder à pergunta do LAMP e não à do gerenciador de pacotes: não “de onde baixo isto?” mas “que autoridade estou concedendo a esta máquina ou agente?”. No longo prazo a identidade passa a ser endereçada por conteúdo (sha256:…) para builds reproduzíveis e travávéis. A identidade é o endereço: o nome de uma lamp deve ser igual ao repositório — ou à pasta — onde vive, e o owner na frente de cada nome é a garantia do host, não uma alegação em um arquivo.

7Relação com as camadas existentes

8Implementação de referência

O CLI de referência, lamp, são três arquivos Synsema compilados em um único binário estático. Implementa pull/update com hash por arquivo, o linter de promessas, a interseção de tetos, enable/disable como ato humano, um servidor MCP por stdio, avaliação ad-hoc sob o teto de sessão, e um audit apenas-de-acréscimo de cada checagem. Seis lamps de referência — shell, git, npm-deps, skills, sql, http — exercitam o contrato; uma lamp hostil exercita as recusas. Cada afirmação deste paper é um teste na implementação.