swamp.club access tokens currently appear to have a broad account-level scope. This makes it hard to use tokens safely in automation/CI because a token intended only for extension publishing may also be able to perform unrelated sensitive actions.

Desired capability

When creating an access token, allow selecting fine-grained permissions/scopes. For example, I want to create a token that can publish extensions, but cannot:

change my user profile
yank/unyank/hide extensions
link or unlink accounts
perform other account-management actions

Proposed solution

Add scoped access tokens with explicit capabilities, such as:

extensions:publish
extensions:yank
extensions:unyank
extensions:hide
profile:write
accounts:link

The token creation UI/API/CLI should let users choose the minimal required permissions, and the registry/API should enforce those scopes on every authenticated action.

Why this matters

This would follow least-privilege principles and make it safer to store swamp.club tokens in CI/CD systems, especially for publishing extensions, without granting broad account control.

02Bog Flow

Shipped

7/24/2026, 12:35:35 AM

Click a lifecycle step above to view its details.

03Sludge Pulse

stack72 assigned stack727/14/2026, 6:19:19 PM

stack72 commented 7/24/2026, 12:34:40 AM

Shipped: fine-grained scopes for collective API tokens

This has been implemented across 8 PRs spanning both the swamp-club web app and the swamp CLI.

What was built

Scope system:

22 scopes across 10 resource categories: extensions (push, promote, read, wildcard), lab, profile, collective, billing, feed, notifications, oauth, serve, datastore, and vault
Wildcard expansion — extensions:* grants all fine-grained extension scopes
Legacy token detection — existing tokens default to extensions:* and show a "LEGACY — ROTATE" warning badge in the UI

Enforcement:

Server-side requireScope() guard on all collective-token-accessible routes (push, confirm, promote, search)
Clear 403 messages naming the missing scope
Infrastructure scopes (serve:*, datastore:*, vault:*) enforced at CLI command level for team features

Token creation:

Web UI scope selector at /o/[slug]/settings with grouped checkboxes (Extensions + Infrastructure)
API accepts optional scopes parameter on POST /api/v1/collectives/[slug]/api-tokens
CLI command: swamp auth token create --collective <slug> --scopes extensions:push,serve:*

CLI support:

Full collective token support — swamp auth whoami shows scopes, swamp extension push works with collective tokens
Scope-aware error messages on 403s

Introspection:

GET /api/whoami returns scopes for collective tokens
swamp auth whoami displays granted scopes

What this enables

CI pipelines can now create a token with only extensions:push and nothing else. That token can publish extensions but cannot promote, search private extensions, or perform any infrastructure operations. This is the least-privilege model requested in the issue.

Infrastructure tokens (serve:*, datastore:*, vault:*) authenticate team services with swamp-club.com, gating swamp serve, remote datastore setup, and non-local vault creation behind collective membership.

Remaining

#1374 — one explanation doc page still argues against fine-grained scopes and needs rewriting
#1375 — end-to-end UAT checklist
Personal API key scopes are a separate future track (different implementation path via BetterAuth)

stack72 commented 7/24/2026, 12:36:40 AM

Thanks @evrardjp for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

First-class scheduled garbage collection policy per datastore namespace

Fine-grained scopes for swamp.club access tokens

Bundled extension model cannot deserialize AWS SDK S3 XML that works in direct Deno

Email invitation is not linked to account created from invite URL

Guide agents to inspect reports after failed model and workflow runs

Add a 'my collective extensions' filter to extensions page

Regression: swamp update syncs global skills to unconfigured agent directories

swamp serve crashes with JavaScript heap OOM while running scheduled workflows

swamp serve startup/shutdown is very slow on large repo and lacks diagnostics

swamp serve should survive bad extension failures

[@adam/cfgmgmt] SSH helper can crash swamp serve via unhandled finally() rejection

Allow swamp clients to send custom headers when connecting to swamp serve

MethodContext docs/comments mention context.putSecret but runtime exposes vaultService.put

install.sh still points users to systeminit/swamp

Support user systemd units for 'swamp serve daemon enable'

Support installing swamp via mise GitHub backend

Allow changing an existing issue to security/confidential after submission

Allow dynamic object expressions for workflow task inputs/globalArgs

Login success still shows login tip

Support confidential visibility for non-security issues

swamp update syncs global skills to default agent directories instead of configured custom Pi skillsDir

Badge for activity on other people's issues

doctor extensions reports source-mounted bundles as unreferenced after repair

Agent setup suggests repo init in already initialized repos

repo upgrade reports success but extension commands still warn about pending migration

model evaluate is slow resolving data.latest expressions in large datastores

Add SSH host public key collection for host certificate workflows

Extension detail page shows deno doc module-not-found failure for published extension

Resolve dynamic workflow task targets inside forEach

Can't click on repository from swamp extension search.

swamp serve does not open the UI

Add deprecate/yank/unyank actions for own extensions on the web interface

swamp update --setup-auto does not work with bluefin44 (crontab not found, should

Terminal rendering breaks at large font sizes

Relationships

#960 Fine-grained scopes for swamp.club access tokens

Problem