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.

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 →Giga-Swamp