Skip to main content
Workspaces organise your threat models by project, team, or repository. Each workspace has its own members, access controls, and threat model history.
Oplane Workspaces overview

Creating a workspace

Click + Workspace in the top right corner to open the New Workspace page. Every workspace is created through the same flow:
  1. Name and description — Enter a name (e.g. your project name) and an optional description.
  2. Sources — Optionally connect a Git repository. Leave this section empty to run threat modeling locally with your coding agent via MCP.
  3. Access — Add team members by name or email and set general access (restricted or open to the organisation).
  4. Click Create.

Connecting a repository

Select a repository under Sources to create a repo-connected workspace. Oplane models threats in the cloud and continuously analyses changes across the repository’s pull requests. When adding a repository you can also toggle Analyse Pull Requests. If disabled, you can still trigger reviews by mentioning @oplane in a PR comment. The workspace name and description are independent of the repository. You can name the workspace whatever you like when creating it, or rename it later. Custom-named workspaces keep their name even if the underlying repository is renamed.
Connecting a repository requires a connected Git provider (GitHub or GitLab). If you haven’t connected one yet, see Connect GitHub or Connect GitLab.

Workspaces without a repository

Leaving Sources empty creates a plain workspace. Use it to run threat modeling locally with your coding agent via MCP and upload results to Oplane. It also suits threat models that aren’t tied to a single repository. This is the best fit for developers running threat models from their IDE (Cursor, GitHub Copilot, Claude Code, etc.).

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 under Sources when creating a 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 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, Oplane decides runtime access to its repositories 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, Oplane preserves the subscription row. Coverage resumes once anyone in the claiming organisation re-authenticates. Individual runs may still be skipped while the underlying token is unhealthy.
Claiming a namespace is a service-admin action performed by Oplane. If you need a namespace claimed for your organisation, transferred between Oplane organisations, or unclaimed, contact Oplane support.

Check failure threshold

Each repo-connected workspace has an opt-in Block merges on unresolved findings setting that controls when the Oplane Security Review check reports Fail. Turn on the switch for a linked repository in workspace settings, then pick a severity from Low to Critical on the slider. 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 number of threat models and member count at a glance. Repo-connected workspaces display a git-provider indicator with a Connected label; it turns into a red Access disabled state when Oplane loses access to the repository. Your personal workspace is marked with a Yours chip.