LAMP: Least-Authority Module Protocol

1The problem: permission over text

When an agent is handed a shell, the grant is a string match — this command line looks safe. But text does not bound effects: the same binary reads and destroys, the credential travels with the invocation, and every new command is a new negotiation. The result is either over-granting (one broad approval) or friction (a prompt per line), and in both cases the record of what was actually reached is reconstructed from logs after the fact, if at all.

The correct unit of permission is not the command but the capability: which hosts, which paths, which binaries, which databases — as effects, enforced below the program, not promised by it.

2The protocol: three parties, four verbs

LAMP is not a wire protocol; it is an authority protocol — an agreement about how capability is declared, granted, narrowed and recorded. Three parties participate, and none of them has to trust the other two:

• The author
  declares. The manifest states the lamp's ceiling — every family of effect it may ever touch (net, file, exec, db…), scoped by pattern.
• The operator
  grants — once. A project ceiling and a session ceiling, written by a human, bound everything that runs. Enabling a lamp is a human act, never a tool an agent can call.
• The runtime
  enforces and audits. The program runs under the intersection of all three ceilings. Every check — granted or denied — returns as structured data and is appended to the record.

3The invariant

Everything reduces to one inequality, checked at run time by the layer below the program:

what runs ⊆ what the code asks ∩ what each ceiling allows

Intersection is the only composition operator. A lamp can narrow what it was given and can never widen it; a dependency runs under its parent's effective ceiling, so composition cannot escalate privilege. Unbounded execution (exec with no named binary) is refused at load, unconditionally — the hole was never execution, it was execution with nothing bounding it.

• exec=gitgranted
• env=LAMP_*granted
• stdoutgranted
• secret("*")refused
• net(collector…)refused
• file.read("/*")refused

4The unit: a lamp

A lamp is a folder — small enough to read whole before running any of it:

The same manifest serves the human and the agent — lamp run git log at a terminal and lamp_git_log() behind a tool call reach the same contract. There is no separate CLI implementation and agent implementation to drift apart: the lamp is the source of truth.

5Inspection before execution

Because the ceiling is text in the manifest and the requests are text in the source, a lamp's promise can be checked before it is ever enabled — a lint over families, with pattern matching left to the runtime, which is the thing that actually decides:

Trust, under LAMP, never means “I trust this developer.” It means “I understand what this lamp can reach, and the runtime will hold that boundary” — even if the source is malicious, the model is confused, or the lamp has a bug.

6Distribution

A lamp is distributed as files, not as an ecosystem: the manifest lists them, the installer fetches them one by one from a plain git host, hashes each, and records the result. Git tags give versions (lamp pull owner/repo@v1.2.0); a registry — when it exists — is a storefront over the same bytes, whose job is to answer the LAMP question rather than the package-manager question: not “where do I get this?” but “what authority am I granting to this machine or agent?” Long-term, identity becomes content-addressed (sha256:…) so builds are reproducible and lockable. Identity is the address: a lamp's name must equal the repo — or the folder — it lives in, and the owner in front of every name is the host's guarantee, not a claim in a file.

7Relation to existing layers

8Reference implementation

The reference CLI, lamp, is three Synsema files compiled to a single static binary. It implements pull/update with per-file hashing, the promise linter, ceiling intersection, enable/disable as the human act, an MCP stdio server, ad-hoc evaluation under the session ceiling, and an append-only audit of every check. Six reference lamps — shell, git, npm-deps, skills, sql, http — exercise the contract; a hostile lamp exercises the refusals. Each claim in this paper is a test in the implementation.