Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLIPublic
Assigneesstack72

Relationships

#1994 Add method-level scoping to grants

Opened by stack72 · 9/3/2026· Shipped 9/4/2026

Problem

Grants currently scope access at the action level (run, read, write, admin) and resource level (model:@acme/my-model), but there is no way to restrict which methods a principal can invoke on a model. If you grant someone run on a model, they can run every method — create, read, update, delete, and any custom methods the model type defines.

This is too coarse for many real-world access patterns. For example, you may want to allow a monitoring user to run read and list methods on a model but not create or destroy.

Proposed Solution

Add an optional methods field to the grant schema:

- subject: "user:monitor-bot"
  effect: allow
  actions: [run]
  resource: "model:@acme/my-model"
  methods: [read, list]

When methods is omitted or empty, the grant applies to all methods (backward compatible). When present, the grant only matches requests for the listed method names.

Implementation scope

  1. Grant schema — add methods: z.array(z.string()).optional() to GrantSchema in src/domain/models/access/grant_model.ts
  2. Grant file persistence — update grant_file.ts to serialize/deserialize the new field
  3. Decision service — add a grantMatchesMethods filter in access_decision_service.ts / grant_based_access_decision_service.ts alongside the existing action and resource matchers
  4. AccessResource type — add an optional method?: string field so the authorization path can carry the method name
  5. Model handlers — pass payload.methodName into the AccessResource at the authorizeOrReject call sites in model_handlers.ts (two call sites: single and batch)
  6. Policy snapshot — update policy_snapshot.ts to include the new field
  7. CEL environment — also add methodName to the model resource fields in grant_condition_environment.ts so CEL conditions can reference it for compound expressions
  8. CLI — update swamp grant commands to accept the methods field

What this does NOT affect

  • Workflow execution — workflow steps bypass per-model authorization by design, so method-level grants only apply to direct [HOST-1] serve calls
  • Existing grants — the field is optional; undefined means "all methods", so no migration needed

Alternatives Considered

  • CEL-only approach — add methodName as a CEL condition variable without a schema field. Lighter (~5 lines) but less discoverable, no validation at grant creation time, verbose for simple cases. Could be done as a complementary addition.
  • Action subtypes (run:read, run:create) — breaks the universal four-action model and makes the Action enum unbounded. Ruled out.
02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 7 MOREREVIEW+ 15 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

9/4/2026, 3:50:43 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack729/3/2026, 10:47:37 PM

Sign in to post a ripple.