API-Level Permissions for Sandboxes

Review access and authorization information for the OCI Generative AI sandbox resource type, and grant sandbox workloads the OCI resource access they need.

For specific permissions for this resource type, review this page. For a list of all resource types available in OCI Generative AI, see User Access to Individual Resources.

The sandbox operations listed on this page are data plane operations in the Generative AI Sandbox API. Project configuration uses separate control plane operations. See API-Level Permissions for Projects.

Resource Type


Resource Type for IAM Permissions	Documentation Reference	API Reference
`generative-ai-sandbox`	Sandboxes in OCI Generative AI	Generative AI Sandbox API

Inspect Permission

Grant user groups inspect permission to run the following operation:

GET ListSandboxes

Read Permission

Grant user groups read permission to run the following operations:

GET ListSandboxes
GET GetSandbox

Use Permission

Grant user groups use permission to run the following operations:

GET ListSandboxes
GET GetSandbox
PUT UpdateSandbox
POST RunSandboxCommand

The GENERATIVE_AI_SANDBOX_USE permission allows active interaction with an existing sandbox, such as running a command. It doesn't grant permission to create or delete a sandbox.

Manage Permission

Grant user groups manage permission to run the following operations:

GET ListSandboxes
GET GetSandbox
PUT UpdateSandbox
POST RunSandboxCommand
POST CreateSandbox
DELETE DeleteSandbox

Note

The manage permission includes all actions allowed by use, read, and inspect.
The use permission includes all actions allowed by read and inspect.
The read permission includes all actions allowed by inspect.

Tip

The generative-ai-sandbox resource type is part of generative-ai-family. If you have permission to the family, you have the same permission for this resource type. For example:

allow group <your-group-name> to manage generative-ai-family
in compartment <your-compartment-name>

1-1 Permissions for APIs

Note

We recommend using the higher-level IAM verbs, manage, use, read, and inspect. For example, permission to delete a sandbox doesn't also grant permission to list sandboxes.

If a use case requires access to a specific API operation, use the individual permissions listed here.

`generative-ai-sandbox`


Permission	API Operation	Operation Type	Verb
`GENERATIVE_AI_SANDBOX_INSPECT`	`ListSandboxes`	`GET`	`inspect`
`GENERATIVE_AI_SANDBOX_READ`	`GetSandbox`	`GET`	`read`
`GENERATIVE_AI_SANDBOX_UPDATE`	`UpdateSandbox`	`PUT`	`use`
`GENERATIVE_AI_SANDBOX_USE`	`RunSandboxCommand`	`POST`	`use`
`GENERATIVE_AI_SANDBOX_CREATE`	`CreateSandbox`	`POST`	`manage`
`GENERATIVE_AI_SANDBOX_DELETE`	`DeleteSandbox`	`DELETE`	`manage`

Policies for Projects and Sandbox Workloads

User Access

An administrator can use these compartment-scoped policies for a group that creates and manages sandboxes and their projects. Replace the placeholders with your group and compartment names.

Allow group <group-name> to manage generative-ai-sandbox in compartment <compartment-name>
Allow group <group-name> to manage generative-ai-project in compartment <compartment-name>

The first policy permits sandbox operations. The second permits project configuration. See API-Level Permissions for Projects and IAM Policies for OCI Generative AI.

Access from a Sandbox to OCI Services

Code running inside a sandbox can use its resource principal to call OCI services. Scope policies to the project and target resources. For example, the following policy permits sandboxes from one project to read objects in one bucket:

Allow any-user to read objects in compartment <target-compartment-name>
where all {
  request.principal.type = 'generativeaisandbox',
  request.principal.project_id = '<project-ocid>',
  target.bucket.name = '<bucket-name>'
}

The permission applies to sandboxes from the specified project. To give different workloads different OCI access, use separate projects or policies scoped to their required resources. For the object permissions and bucket condition, see Details for Object Storage and Archive Storage.

Inside the sandbox, use --auth resource_principal with the OCI CLI, or a resource principal signer with the OCI Python SDK:

import oci

signer = oci.auth.signers.get_resource_principals_signer()
client = oci.object_storage.ObjectStorageClient(
    config={"region": "us-chicago-1"},
    signer=signer,
)

Reading a Vault Secret

For a workload that needs a Vault secret, grant access to the specific secret bundle:

Allow any-user to read secret-bundles in compartment <secret-compartment-name>
where all {
  request.principal.type = 'generativeaisandbox',
  request.principal.project_id = '<project-ocid>',
  target.secret.id = '<secret-ocid>'
}

Use the resource principal signer with the OCI Secrets client to retrieve the secret at runtime. Keep secret values out of command output and logs. For secret bundle permissions, see Details for Vault, Key Management, and Secret Management Service.

Other Permissions

Custom networking requires permission to use the selected subnet and any network security groups (NSGs) that you attach. NSGs use security rules to control inbound and outbound traffic for associated resources. Custom images require permission to read the image repository and, when vulnerability scan enforcement is enabled, scan results. See Networking for Sandboxes and Using a Custom Image for a Sandbox.

Oracle Cloud Infrastructure Documentation