Skip to main content

REAL-WORLD SCENARIOS

These scenarios use a three-team setup — platform-eng, development, and marketing — to show common authorization patterns. Each scenario is a self-contained recipe.

Team isolation

Give each team access to their own namespace and deny access to others.

Create groups and assign members:

swamp access group create platform-eng --server wss://swamp.example.com
swamp access group add-member platform-eng user:paul --server wss://swamp.example.com

swamp access group create development --server wss://swamp.example.com
swamp access group add-member development user:sarah --server wss://swamp.example.com

swamp access group create marketing --server wss://swamp.example.com
swamp access group add-member marketing user:adam --server wss://swamp.example.com

Grant each group scoped access:

swamp access grant create --subject group:platform-eng \
  --allow run,read,write --on 'workflow:@infra/*' --server wss://swamp.example.com

swamp access grant create --subject group:development \
  --allow run,read,write --on 'workflow:@dev/*' --server wss://swamp.example.com

swamp access grant create --subject group:marketing \
  --allow run,read --on 'model:@marketing/*' --server wss://swamp.example.com

Reload to apply:

swamp access reload --server wss://swamp.example.com

Environment separation with CEL conditions

Allow a team to run workflows in staging but not production:

swamp access grant create --subject group:development \
  --allow run --on 'workflow:@acme/*' \
  --when 'tags.env == "staging"' --server wss://swamp.example.com

Grant production access only to platform-eng:

swamp access grant create --subject group:platform-eng \
  --allow run --on 'workflow:@acme/*' \
  --when 'tags.env == "production"' --server wss://swamp.example.com

Deny overrides for compliance

A broad allow grant can be overridden with a targeted deny. To lock down sensitive data across all teams:

swamp access grant create --subject group:development \
  --allow read --on 'data:*' --server wss://swamp.example.com

swamp access grant create --subject group:development \
  --deny read --on 'data:@acme/secrets-*' --server wss://swamp.example.com

Deny always wins — even though the first grant allows reading all data, the second grant blocks @acme/secrets-* specifically.

Temporary individual access

Grant a single user temporary access for a specific task:

swamp access grant create --subject user:adam --allow run \
  --on 'workflow:@infra/deploy' --server wss://swamp.example.com
swamp access reload --server wss://swamp.example.com

When the task is done, revoke the grant:

swamp access grant list --server wss://swamp.example.com
# Find the grant ID for user:adam on workflow:@infra/deploy
swamp access grant revoke <grant-id> --server wss://swamp.example.com
swamp access reload --server wss://swamp.example.com

Admin delegation

Delegate admin capabilities to a team lead by granting admin on access:*:

swamp access grant create --subject user:sarah --allow admin \
  --on 'access:*' --server wss://swamp.example.com

Admin on access:* implies all actions on all resources — this is the superuser grant. Use it for team leads who need to manage grants and tokens for their team.

Restricting dangerous model types

Lock down command/shell so only admins can create or run shell models:

swamp serve --auth-mode token \
  --admins 'user:paul' \
  --restricted-model-types 'command/shell' \
  --cert-file cert.pem --key-file key.pem \
  --host 0.0.0.0

Non-admin users with run on model:* can still run other model types normally but are denied command/shell:

Access denied: user:sarah does not have 'admin' on access:*

To restrict multiple types, pass a comma-separated list:

--restricted-model-types 'command/shell,custom/dangerous'

Restricting server commands

Lock down administrative server commands so only admins can execute them:

swamp serve --auth-mode token \
  --admins 'user:paul' \
  --restricted-commands 'datastore.namespace.list,extension.install' \
  --cert-file cert.pem --key-file key.pem \
  --host 0.0.0.0

Non-admin users with grants on the relevant resources can still perform other operations but are denied the restricted commands:

Access denied: user:sarah does not have 'admin' on access:extension.install

To restrict both model types and commands together:

swamp serve --auth-mode token \
  --admins 'user:paul' \
  --restricted-model-types 'command/shell' \
  --restricted-commands 'datastore.namespace.list,extension.install' \
  --cert-file cert.pem --key-file key.pem \
  --host 0.0.0.0

Use --restricted-model-types when you want to control which models can be created or run. Use --restricted-commands when you want to control which server operations are available to non-admin users.

Separation of duties for workflow approval

Prevent runners from approving their own workflow gates by splitting run and approve across two groups. The run action implicitly permits approve, so runners need an explicit deny on approve to enforce the split.

Give developers permission to start deploy workflows but block them from approving:

swamp access grant create --subject group:development \
  --allow run --on 'workflow:@acme/deploy-*' --server wss://swamp.example.com

swamp access grant create --subject group:development \
  --deny approve --on 'workflow:@acme/deploy-*' --server wss://swamp.example.com

Give release managers permission to approve gates but not start runs:

swamp access grant create --subject group:platform-eng \
  --allow approve --on 'workflow:@acme/deploy-*' --server wss://swamp.example.com

Reload to apply:

swamp access reload --server wss://swamp.example.com

With these grants, a developer starts a deploy workflow and it suspends at the manual_approval gate. The developer cannot approve it — a release manager reviews and either approves or rejects, then anyone with run can resume the workflow to continue execution.

To manage the same grants as version-controlled files, see Manage Grants with Files.

User offboarding

When a user leaves, revoke their token and all their grants:

# Revoke the token (immediate — no reload needed)
swamp access token revoke sarah-token --server wss://swamp.example.com

# List and revoke all grants for the user
swamp access grant list --server wss://swamp.example.com
# Revoke each grant for user:sarah
swamp access grant revoke <grant-id> --server wss://swamp.example.com

# Remove from all groups
swamp access group remove-member development user:sarah \
  --server wss://swamp.example.com

# Reload to apply grant and group changes
swamp access reload --server wss://swamp.example.com
← PreviousRun Commands on a Remote ServerNext →Run as a System Daemon