Code Workspaces applies Foundry's security and permissions model to hosted third-party integrated development environments (IDEs). A code workspace is a development environment with code execution and terminal access; third-party IDEs can run inside a code workspace. Code, extensions, and other developer tools in a workspace can initiate supported requests on behalf of the user. Organizations should therefore evaluate access to Code Workspaces as access to a general-purpose authoring environment.
There are three main principles to keep in mind around identity and platform permissions:
Each workspace session runs on behalf of the current user. Foundry provides the session with a user credential that is scoped to the operations and resources supported from Code Workspaces. Each Foundry service authorizes a request against the credential's operation and resource scope, as well as the user's permissions on the requested resource.
Code Workspaces defines the credential scope from the operations and resource constraints required for supported authoring workflows. Some operations are limited to specific resources associated with the workspace, such as its backing repository or container. Other operations support broader resource discovery and metadata access. The scope also supports repository development, branch-based change management, previews, and selected platform integrations. Operations unrelated to supported Code Workspaces workflows, including broad administrative operations, are omitted. Some capabilities are added to the scope only when they are enabled for the workspace. The credential is not read-only: selected write operations required for authoring remain available when the user has the corresponding permissions.
Data access that can affect security lineage is handled separately. Before supported data is loaded, Foundry registers the resource as an input to the workspace session and resolves access using credentials scoped to that input. This records provenance and propagates mandatory controls, such as markings, to the workspace and its supported outputs. Requests that would bypass this handling are not permitted through the workspace credential. Data imports and exports through supported Code Workspaces workflows therefore remain tracked in Foundry.
Resources in other projects are generally made available through Project references imported into the workspace's project. Code in a workspace may access such a resource only when the credential scope permits the operation on that resource and the user has access. A resource being in the same project as the workspace does not grant access by itself. Project roles, Organizations, markings, granular access controls, and resource permissions continue to apply.
Foundry validates requests to open or interact with a workspace against the user's permissions and the security controls propagated from registered inputs. If the user's access to the workspace is revoked, Foundry denies access to the application. Foundry also denies access to the workspace and its supported outputs if the user loses access to mandatory controls, such as markings, on any registered data input. Permission changes may take a short time to propagate.
Code Workspaces provides the following controls around the IDE session:
Developer tools available in a workspace, including IDE extensions, command-line tools, Model Context Protocol (MCP) servers, and AI coding assistants, operate within the workspace session. Depending on their capabilities and configuration, these tools may read workspace content, execute commands, or invoke enabled Foundry tools. They do not independently expand the user's Foundry permissions, but they can exercise the access available to the user within the operations supported by the workspace credential.
The tools, models, and approval flows available in a workspace may vary by enrollment and release. When evaluating the workspace, account for the complete set of enabled development tools and the data or actions that those tools can access.
Requests from a workspace to Foundry services are covered by the audit logging provided for those services and retain the available user and request context. Audit logs describe actions received by Foundry services; they are not a complete transcript of local editor, terminal, or AI conversation activity. An action initiated through an AI-assisted tool may result in multiple service requests. For more information, review the audit log overview and audit monitoring guidance.
Restricted outputs mode provides enhanced safeguards when working with sensitive data. Restricted outputs mode is a "read-only" mode that restricts write operations and external source connections to ensure that data cannot be exported from the code workspace. In particular, it allows you to load restricted views into a workspace.
You can read restricted views only in JupyterLab® workspaces.
When enabled, restricted outputs mode:
As described in the documentation on code checkpoints, it is your responsibility to ensure that code files you write while in restricted outputs mode do not contain data.
To enable or disable restricted outputs mode:
After enabling restricted outputs mode, your workspace will prompt you to restart. Your setting will persist across future workspace restarts until you explicitly disable it.
RStudio® and Shiny® are trademarks of Posit™.
Jupyter®, JupyterLab®, and the Jupyter® logos are trademarks or registered trademarks of NumFOCUS.
All third-party trademarks (including logos and icons) referenced remain the property of their respective owners. No affiliation or endorsement is implied.