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.

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