Security

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.

Identity and platform permissions

There are three main principles to keep in mind around identity and platform permissions:

  • Foundry authorizes workspace-initiated requests on behalf of the current user.
  • Access requires both an operation’s inclusion in the workspace credential scope and the user’s permission on the requested resource.
  • Data imported and exported through supported workflows retains provenance and mandatory controls.

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.

Session isolation and data controls

Code Workspaces provides the following controls around the IDE session:

  • Each user who opens a workspace receives an isolated session. Foundry validates requests from the session against that user's identity and permissions. Session state and data checkpoints are not shared between users.
  • Data loaded through Code Workspaces is tracked by Foundry. Data downloads and uploads are restricted except through methods governed by Foundry's data governance and access controls.
  • Data written from Code Workspaces is tracked by Foundry. Permissions and lineage controls apply to supported outputs.
  • External network access is limited by the sources and egress policies configured for the workspace. Foundry validates access to these resources against the user's permissions. Where supported, sources hold credentials for external systems separately from code.

Developer tools and AI-assisted features

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.

Audit and usage visibility

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

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:

  • Prevents write operations to all Foundry outputs, including datasets, models, and tables.
  • Disables telemetry collection and logs, as well as data checkpoint uploads, while still preserving code checkpoints.
  • Disables network policies and sources that have been added to the workspace. These resources remain in the workspace but are inactivated while in 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:

  1. Open the Settings side panel in your code workspace.
  2. Locate the Restricted outputs mode toggle.
  3. Toggle the setting on or off as needed.
  4. Save your changes and restart your workspace when prompted.

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.