Restricting Digital Twin Access by Model

Use model conditions in IAM policies to grant read access to digital twin resources associated with a selected model.

Digital twin resources associated with an IoT domain share its compartment. Model conditions let you narrow a group's access within that compartment. An administrator creates the policies; users access the resources through the Console, CLI, SDK, or API.

The examples below grant read access only. They do not grant permission to create, update, delete, or send commands to digital twins. Replace the group, compartment, and model placeholders with your own values.

Read Resources Associated with One Model

Use target.digital-twin-model.id to match the associated model OCID. Grant each resource type separately, according to the user's needs:

Allow group <group-name> to read iot-digital-twin-model in compartment <compartment-name> where target.digital-twin-model.id = '<model-OCID>'
Allow group <group-name> to read iot-digital-twin-adapter in compartment <compartment-name> where target.digital-twin-model.id = '<model-OCID>'
Allow group <group-name> to read iot-digital-twin-instance in compartment <compartment-name> where target.digital-twin-model.id = '<model-OCID>'

The adapter and instance conditions refer to their associated model, not to the adapter or instance OCID. An unstructured instance without an associated model doesn't match this model-scoped grant.

Read Instances by Model Specification URI

Use target.digital-twin-model.spec-uri to match the model specification identifier. For an exact match:

Allow group <group-name> to read iot-digital-twin-instance in compartment <compartment-name> where target.digital-twin-model.spec-uri = 'dtmi:com:example:hvac;1'

To match a family of specification identifiers, use an IAM pattern. This example includes every version matched by the pattern, rather than only version 1:

Allow group <group-name> to read iot-digital-twin-instance in compartment <compartment-name> where target.digital-twin-model.spec-uri = /dtmi:com:example:hvac;*/

Choose the narrowest match that meets your access requirements.

Read One Digital Twin Model by Resource OCID

To grant read access to one specific digital twin model, use target.resource.id with that model's OCID:

Allow group <group-name> to read iot-digital-twin-model in compartment <compartment-name> where target.resource.id = '<model-OCID>'

This condition matches the requested model itself, rather than granting access to its associated adapters or instances. With a test identity that has no broader grant, retrieve the permitted model and verify success, then make the same request for a different model and verify denial. This example does not grant create permission or filter list results.

List Visibility and Other Permissions

These conditions do not filter list results. If users must browse resources, grant the required inspect permission separately. For example:

Allow group <group-name> to inspect iot-digital-twin-instance in compartment <compartment-name>

This separate grant can expose names of instances outside the permitted model scope. Listing an instance does not grant access to retrieve its content or send it commands.

A read-only model policy does not grant create permission or authorize changing an instance's model association. Treat those operations as separate access requirements; don't broaden these examples to manage to resolve a failed read.

These examples govern IAM access to digital twin resources. They do not replace device certificates or secrets, configure direct database access, or turn ordinary application metadata into an authorization rule.

For the permissions associated with each resource type and verb, see Policy Details for the Internet of Things Platform.

Validate Both Allowed and Denied Access