Relationships
#4008 access can-i: evaluate a local grants file without --server
Opened by mtaylor · 10/27/2026
What
Let swamp access can-i evaluate a local grants file without --server. For example:
swamp access can-i --action run --on model:esqa --method provisionDevices \
--as user:agent --grants-file .swamp/agent-grants.yaml --jsonIt would return allow or deny, plus the grant that decided it. A local run would still not be enforced. This is only an evaluation.
Why
The grant model already expresses what an AI coding agent may do: deny first, per-method methods: lists, CEL conditions on model name, tags, type and method, workflow vault caps, and approve for workflow approval steps. But a local swamp run without --server isn't subject to grants, and that's where agents run swamp.
Today the only way to apply grants to an agent is to route its work through a swamp serve. A command that evaluates grants offline would let a Claude Code PreToolUse hook ask swamp for each swamp model method run and swamp workflow run. The hook would map deny to a block and allow to a pass, and could ask the human for anything with no matching grant. The agent's policy would then live in swamp's own grant format, reviewed in the repo, not in a separate allow-list in each tool's settings.
Notes
- The hook would need the same subject resolution and condition evaluation that serve uses, so the answers match what serve would decide.
- A JSON result with the grant that decided it would let the hook explain its decision to the user.
Open
No activity in this phase yet.
jayr commented 11/1/2026, 2:16:26 PM
+1. We run this pattern today and would use the feature right away.
Our Claude Code agents run swamp locally against a shared datastore. A PreToolUse hook stops them from approve/reject on approval gates, because those decisions belong to a person. That hook is a hand-written allow-list. It repeats policy our serve grants already express, and the two can drift apart.
With can-i --grants-file the hook could ask swamp directly, using the same grants file our serve loads. One allow/deny policy would then cover both the agents and serve, reviewed in the repo.
Asks:
- Resolve subjects the same way serve does, including
collective:<slug>, so a local answer matches what serve would decide. - Return the deciding grant in
--json, as proposed, plus a distinct result for "no grant matched". The hook would then ask the human instead of failing closed.
Sign in to post a ripple.