> ## Documentation Index > Fetch the complete documentation index at: https://www.oplane.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Workspaces for organising threat models > What a workspace is in Oplane, how repo-connected and standalone workspaces differ, and how namespace claims decide which organisation owns a repository. Workspaces organise your threat models by project, team, or repository. Each workspace has its own members, access controls, and threat model history. This page explains the kinds of workspace and how they behave. To create and manage them, see [Manage workspaces](/docs/administration/workspaces). Oplane Workspaces overview ## Kinds of workspace When you [create a workspace](/docs/administration/workspaces#creating-a-workspace), the **Sources** section decides which kind it is. ### 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. See [How reviews work](/docs/how-it-works/reviews). 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](/docs/connect/github) or [Connect GitLab](/docs/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](/docs/find/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 blocks the merge. A blocking check reports **Action required** on GitHub or **Failed** on GitLab. 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 [Merge gating](/docs/prove/merge-gating) for the full setup. ## Read next * [Manage workspaces](/docs/administration/workspaces), to create workspaces and track progress. * [Roles and permissions](/docs/administration/roles#workspace-permissions), for who can change workspace settings. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.