Per-Environment Member Access

Quave ONE allows account admins to control which environments each member can see and interact with. This is useful for teams with many apps and environments where you want to limit what each member can access — for example, preventing a developer on one project from accidentally modifying environments belonging to another.

Enabling the Feature

1. Go to your account Members page
2. Under Access Control, toggle Enable per-environment member access
3. The feature is now active for this account

info

Enabling this feature does not immediately restrict anyone. All existing members retain full access to every environment until an admin explicitly configures their access.

tip

Disabling the feature does not erase saved restrictions. If you toggle it off, all members regain full access immediately. If you toggle it back on, the previous restrictions are restored automatically.

How It Works

• Full Access (default): Members can see and interact with all environments in the account. This remains the default until an admin restricts access on invite, on a pending invitation, or on an existing member.
• Restricted Access: When an admin assigns specific environments to a member or invitation, that person can only see and interact with those environments. Apps that have no accessible environments are hidden entirely.

New Environments

When a member with restricted access creates a new environment, it is automatically added to their access list. Other restricted members will not see the new environment until an admin assigns it to them. Members with full access always see everything.

Managing Environment Access

1. Go to your account Members page
2. Invite a member, or open an existing member / pending invitation
3. Choose roles as usual
4. If per-environment access is enabled:
   • On Invite members, uncheck Full Access and select environments before sending the invitation
   • On a member or pending invitation row, click Envs and save the same picker
5. Changes take effect immediately for existing members across the UI, API, CLI, and MCP tools. For pending invitations, the restriction is stored on the invite and applied when the person joins — they never start with access to every environment.

The environment picker is the same control in all three places: invite, pending invitation, and existing member.

note

Admins always see all environments in the access modal, even if their own access is restricted. This ensures admins can grant access to any environment when managing other members.

Access Enforcement

When this feature is enabled, environment-level access is enforced across all surfaces:

Surface	Behavior
Dashboard	Only accessible apps and environments are shown
Direct URL	Navigating to a restricted environment's URL shows a "not found" page — no data is leaked
REST API	GET /apps and GET /app-envs return only accessible items; per-environment operations return 403 for restricted environments
MCP Tools	Filtered automatically since MCP tools use the REST API
CLI	Same filtering and permission checks as the REST API

All environment-specific operations — deploys, config changes, scaling, logs, metrics, etc. — are gated by this access check.

Managing Access via API

You can also read and update member environment access programmatically:

• Read access: GET /api/public/v1/member/env-access?accountId=...&membershipId=...
• Update access: PATCH /api/public/v1/member/env-access with body { accountId, membershipId, allowedAppEnvIds }

Both endpoints require the Manage Members permission. Pass an empty array (or omit allowedAppEnvIds) to grant full access.

Roles Required

• Admin or members with Manage Members permission can enable the feature and configure access for other members
• The access configuration uses the same Members page where roles are managed

tip

For a broader overview of roles and what each one grants, see User Roles.

For another account-level control available under Members → Access Control, see Session Inactivity Timeout.