Workspaces for organising threat models

Workspaces organise your threat models by project, team, or repository. Each workspace has its own members, access controls, and threat model history.

​

Workspace types

When creating a workspace, choose the type that matches your workflow:

​

Agent Workspace

Run threat modeling locally with your coding agent via MCP. Analyse any repository and upload results to Oplane. Best for developers running threat models from their IDE (Cursor, GitHub Copilot, Claude Code, etc.).

​

Managed Workspace

Let Oplane model threats in the cloud and continuously analyse changes across pull requests. Tied to a specific Git repository for automated PR/MR reviews.

​

Creating a workspace

​

Agent Workspace

To create an Agent Workspace, click + Workspace in the top right corner and select Agent Workspace:

1. Enter a name for the workspace (e.g. your project name)
2. Add an optional description
3. Configure access — add team members by name or email
4. Set general access (restricted or open to the organisation)
5. Click Create

​

Managed Workspace

To create a Managed Workspace, select Managed Workspace and link it to a Git repository:

1. Select your organisation from the dropdown
2. Search for and select the repository you want to connect
3. Click Create

​

Namespace claims

A namespace is a GitHub organisation or user account, or a GitLab group. An Oplane organisation can claim a namespace so that only its workspaces can subscribe to repositories under it. This gives customers a clean ownership boundary when multiple Oplane organisations touch the same Git provider tenant. What you’ll see when a namespace is claimed by a different Oplane organisation than your own:

• Repository picker — the namespace is greyed out and cannot be selected when creating a Managed Workspace.
• Subscribe or reactivate — attempting to link a repository under that namespace is blocked.
• Existing subscriptions — if a namespace you were already using gets claimed by a different organisation, your Managed Workspaces subscribed to its repositories are deactivated. No threat model data is deleted; workspaces, threat models, and requirements are preserved and become read-only until the claim situation is resolved.

Once a namespace is claimed, runtime access to its repositories is decided by membership of the claiming organisation rather than the per-user Git OAuth check. This means PR and MR reviews keep working for the whole workspace even if the user who originally connected the repository leaves or loses personal access. Subscriptions in a namespace claimed by their own workspace’s organisation are also protected from automatic deactivation on access loss. If the user who connected a repository unlinks their GitHub identity, loses provider access, or their token expires, the subscription row is preserved and coverage resumes once anyone in the claiming organisation re-authenticates. Individual runs may still be skipped while the underlying token is unhealthy.

​

Check failure threshold

Each Managed Workspace has an opt-in check failure threshold that controls when the Oplane Security Review check reports Fail. Pick a severity threshold in workspace settings — when combined with your CI pipeline’s branch protection rules, this acts as a merge gate to prevent unresolved requirements at the level of your choosing from slipping through. See Check failure threshold for the full setup.

​

Managing workspaces

From the Workspaces page you can:

• Star workspaces to pin them at the top of your list
• Search across all workspaces by name
• Switch views between grid and list layout
• Filter by starred workspaces only

Each workspace card shows the workspace type, number of threat models, and member count at a glance.