All Products
Search
Document Center

STAROps:Best Practices for STAROps Custom Permission Policies

Last Updated:Jun 22, 2026

Create custom permission policies for STAROps based on the principle of least privilege. The policy examples provided here help you quickly configure precise access permissions for roles such as operations administrators, general operations engineers, and Skill developers, reducing security risks from over-permissioning.

Solution overview

Applicable scenarios

This solution applies to the following scenarios:

  • Multi-user collaboration: Multiple team members use STAROps together and need different operation permissions based on their responsibilities.

  • Security compliance: You need to follow the principle of least privilege to ensure that each RAM user has only the minimum permissions required to complete their work.

  • Resource isolation: Multiple Digital Employees serve different business lines, and you need to isolate operation permissions at the Digital Employee level.

Prerequisites

  • You are familiar with how to create custom permission policies in the RAM console. For more information, see the RAM documentation.

  • You are familiar with how to grant permissions to RAM users. For more information, see the RAM documentation.

Minimum permission policy examples for typical scenarios

The following minimum permission policy examples cover common team roles. You can copy them directly or adjust them to suit your requirements.

STAROps permission policies require granting Actions with both cms: and starops: prefixes. For the complete Action list and resource ARN format, see the STAROps API reference and resource ARN documentation.

Operations administrator (full permissions for Digital Employees, sessions, and Skills)

Scenario: The operations administrator manages the full lifecycle of Digital Employees, including creating, configuring, and deleting Digital Employees, managing Skills and sessions, and chatting with Digital Employees.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cms:CreateDigitalEmployee",
        "cms:GetDigitalEmployee",
        "cms:ListDigitalEmployees",
        "cms:UpdateDigitalEmployee",
        "cms:DeleteDigitalEmployee",
        "cms:CreateDigitalEmployeeSkill",
        "cms:GetDigitalEmployeeSkill",
        "cms:ListDigitalEmployeeSkills",
        "cms:UpdateDigitalEmployeeSkill",
        "cms:DeleteDigitalEmployeeSkill",
        "cms:ListDigitalEmployeeSkillVersions",
        "cms:CreateThread",
        "cms:GetThread",
        "cms:GetThreadData",
        "cms:ListThreads",
        "cms:UpdateThread",
        "cms:DeleteThread",
        "cms:GetArtifact",
        "cms:ListArtifacts",
        "cms:CreateChat"
      ],
      "Resource": [
        "acs:cms:*:*:digitalemployee/*",
        "acs:cms:*:*:digitalemployee/*/skill/*",
        "acs:cms:*:*:digitalemployee/*/thread/*",
        "acs:cms:*:*:digitalemployee/*/artifact/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "acs:Service": "cloudmonitor.aliyuncs.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:ListWorkspaces",
        "cms:GetWorkspace",
        "cms:GetEntityStore",
        "cms:GetEntityStoreData"
      ],
      "Resource": [
        "acs:cms:*:*:workspace/*",
        "acs:cms:*:*:workspace/*/entitystore"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "starops:CreateDigitalEmployee",
        "starops:GetDigitalEmployee",
        "starops:ListDigitalEmployees",
        "starops:UpdateDigitalEmployee",
        "starops:DeleteDigitalEmployee",
        "starops:CreateDigitalEmployeeSkill",
        "starops:GetDigitalEmployeeSkill",
        "starops:ListDigitalEmployeeSkills",
        "starops:UpdateDigitalEmployeeSkill",
        "starops:DeleteDigitalEmployeeSkill",
        "starops:ListDigitalEmployeeSkillVersions",
        "starops:CreateThread",
        "starops:GetThread",
        "starops:GetThreadData",
        "starops:ListThreads",
        "starops:UpdateThread",
        "starops:DeleteThread",
        "starops:GetArtifact",
        "starops:ListArtifacts",
        "starops:CreateChat"
      ],
      "Resource": [
        "acs:starops:*:*:digitalemployee/*",
        "acs:starops:*:*:digitalemployee/*/skill/*",
        "acs:starops:*:*:digitalemployee/*/thread/*",
        "acs:starops:*:*:digitalemployee/*/artifact/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "acs:Service": "operation-platform.aliyuncs.com"
        }
      }
    }
  ]
}

General operations engineer (chat and view only, no management)

Scenario: General operations engineers use Digital Employees for intelligent conversations in daily work (for example, fault diagnosis and log analysis), but do not need to create or modify Digital Employees or Skill configurations.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cms:GetDigitalEmployee",
        "cms:ListDigitalEmployees",
        "cms:CreateChat",
        "cms:CreateThread",
        "cms:GetThread",
        "cms:GetThreadData",
        "cms:ListThreads",
        "cms:GetArtifact",
        "cms:ListArtifacts"
      ],
      "Resource": [
        "acs:cms:*:*:digitalemployee/*",
        "acs:cms:*:*:digitalemployee/*/thread/*",
        "acs:cms:*:*:digitalemployee/*/artifact/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:ListWorkspaces",
        "cms:GetWorkspace",
        "cms:GetEntityStore",
        "cms:GetEntityStoreData"
      ],
      "Resource": [
        "acs:cms:*:*:workspace/*",
        "acs:cms:*:*:workspace/*/entitystore"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "starops:GetDigitalEmployee",
        "starops:ListDigitalEmployees",
        "starops:CreateThread",
        "starops:GetThread",
        "starops:GetThreadData",
        "starops:ListThreads",
        "starops:GetArtifact",
        "starops:ListArtifacts",
        "starops:CreateChat"
      ],
      "Resource": [
        "acs:starops:*:*:digitalemployee/*",
        "acs:starops:*:*:digitalemployee/*/thread/*",
        "acs:starops:*:*:digitalemployee/*/artifact/*"
      ]
    }
  ]
}
Note

This policy allows users to view the Digital Employee list, initiate conversations, and view session records, but does not allow creating, modifying, or deleting Digital Employees, Skills, or sessions. The starops: permissions ensure users can log in to the STAROps console.

Permission scoped to a specific Digital Employee

Scenario: Different business lines each have a dedicated Digital Employee. For example, Team A is allowed to operate only the Digital Employee named ops-agent-a and cannot access other teams' Digital Employees.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cms:GetDigitalEmployee",
        "cms:UpdateDigitalEmployee",
        "cms:CreateChat",
        "cms:CreateThread",
        "cms:GetThread",
        "cms:GetThreadData",
        "cms:ListThreads",
        "cms:UpdateThread",
        "cms:DeleteThread",
        "cms:GetDigitalEmployeeSkill",
        "cms:ListDigitalEmployeeSkills",
        "cms:ListDigitalEmployeeSkillVersions",
        "cms:GetArtifact",
        "cms:ListArtifacts"
      ],
      "Resource": [
        "acs:cms:*:*:digitalemployee/ops-agent-a",
        "acs:cms:*:*:digitalemployee/ops-agent-a/skill/*",
        "acs:cms:*:*:digitalemployee/ops-agent-a/thread/*",
        "acs:cms:*:*:digitalemployee/ops-agent-a/artifact/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:ListDigitalEmployees",
        "cms:ListWorkspaces",
        "cms:GetWorkspace",
        "cms:GetEntityStore",
        "cms:GetEntityStoreData"
      ],
      "Resource": [
        "acs:cms:*:*:workspace/*",
        "acs:cms:*:*:workspace/*/entitystore"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "starops:GetDigitalEmployeeSkill",
        "starops:ListDigitalEmployeeSkills",
        "starops:ListDigitalEmployeeSkillVersions",
        "starops:CreateThread",
        "starops:GetThread",
        "starops:GetThreadData",
        "starops:ListThreads",
        "starops:UpdateThread",
        "starops:DeleteThread",
        "starops:GetArtifact",
        "starops:ListArtifacts",
        "starops:CreateChat"
      ],
      "Resource": [
        "acs:starops:*:*:digitalemployee/ops-agent-a",
        "acs:starops:*:*:digitalemployee/ops-agent-a/skill/*",
        "acs:starops:*:*:digitalemployee/ops-agent-a/thread/*",
        "acs:starops:*:*:digitalemployee/ops-agent-a/artifact/*"
      ]
    }
  ]
}

Replace the wildcard * in the Resource field with a specific Digital Employee name (for example, ops-agent-a) to achieve resource-level isolation. Both the cms: and starops: Resource fields must specify the same Digital Employee name. The ListDigitalEmployees action requires authorization on all Digital Employee resources; otherwise, users cannot see the Digital Employee list in the console.

Long-running Mission operator (Mission management)

Scenario: Operators are responsible for creating and managing long-running Missions.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "starops:CreateMission",
        "starops:GetMission",
        "starops:ListMissions",
        "starops:UpdateMission",
        "starops:DeleteMission",
        "starops:ListTasks",
        "starops:ListDigitalEmployees",
        "starops:ListThreads"
      ],
      "Resource": [
        "acs:starops:*:*:mission/*",
        "acs:starops:*:*:digitalemployee/*",
        "acs:starops:*:*:digitalemployee/*/thread/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "starops:GetArtifact",
        "starops:ListArtifacts"
      ],
      "Resource": "acs:starops:*:*:digitalemployee/*/artifact/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:CreateMission",
        "cms:GetMission",
        "cms:ListMissions",
        "cms:UpdateMission",
        "cms:DeleteMission",
        "cms:ListTasks",
        "cms:ListDigitalEmployees",
        "cms:ListThreads"
      ],
      "Resource": [
        "acs:cms:*:*:mission/*",
        "acs:cms:*:*:digitalemployee/*",
        "acs:cms:*:*:digitalemployee/*/thread/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:GetArtifact",
        "cms:ListArtifacts"
      ],
      "Resource": "acs:cms:*:*:digitalemployee/*/artifact/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:ListWorkspaces",
        "cms:GetWorkspace"
      ],
      "Resource": "acs:cms:*:*:workspace/*"
    }
  ]
}

Long-running Mission read-only (view only, no create or modify)

Scenario: Team members need to view the execution progress of long-running Missions, task details, and artifact reports, but are not allowed to create, modify, or delete any Missions or tasks.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "starops:GetMission",
        "starops:ListMissions",
        "starops:ListTasks",
        "starops:ListDigitalEmployees",
        "starops:GetDigitalEmployee",
        "starops:ListThreads"
      ],
      "Resource": [
        "acs:starops:*:*:mission/*",
        "acs:starops:*:*:digitalemployee/*",
        "acs:starops:*:*:digitalemployee/*/thread/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "starops:GetArtifact",
        "starops:ListArtifacts"
      ],
      "Resource": [
        "acs:starops:*:*:digitalemployee/*/artifact/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:GetMission",
        "cms:ListMissions",
        "cms:ListTasks",
        "cms:ListDigitalEmployees",
        "cms:GetDigitalEmployee",
        "cms:ListThreads"
      ],
      "Resource": [
        "acs:cms:*:*:mission/*",
        "acs:cms:*:*:digitalemployee/*",
        "acs:cms:*:*:digitalemployee/*/thread/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:GetArtifact",
        "cms:ListArtifacts"
      ],
      "Resource": [
        "acs:cms:*:*:digitalemployee/*/artifact/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:ListWorkspaces",
        "cms:GetWorkspace"
      ],
      "Resource": [
        "acs:cms:*:*:workspace/*"
      ]
    }
  ]
}

Security hardening recommendations

Follow these security hardening recommendations to reduce the risks of over-permissioning.

Avoid wildcard authorization

Using the * wildcard in the Action and Resource fields grants overly broad permissions. Always explicitly list the required Actions and specify concrete resource ARNs in Resource.

Practice

Example

Risk level

Not recommended

"Action": "cms:*"

High: Grants all CMS operations, including Cloud Monitor operations unrelated to STAROps.

Not recommended

"Action": "cms:*DigitalEmployee*"

Medium: Wildcards may match unknown Actions added in the future.

Recommended

Explicitly list each Action

Low: Precise control with a clear and auditable permission scope.

Use Deny policies to restrict high-risk operations

For irreversible delete operations such as DeleteDigitalEmployee and DeleteMission, use explicit Deny policies to restrict them. Even if a user has been granted other broad permission policies, they will not be able to perform delete operations.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cms:DeleteDigitalEmployee",
        "cms:DeleteDigitalEmployeeSkill",
        "cms:DeleteThread",
        "cms:DeleteMission"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "starops:DeleteDigitalEmployeeSkill",
        "starops:DeleteThread",
        "starops:DeleteDigitalEmployeeSkill",
        "starops:DeleteMission"
      ],
      "Resource": "*"
    }
  ]
}

Create this Deny policy as a standalone permission policy (for example, named starops-deny-delete-policy) and attach it to the RAM users or user groups that need to be restricted. Deny always takes precedence over Allow and serves as a security safety net. Make sure to deny delete operations for both cms: and starops: prefixes to prevent deletion through either path.

Regularly audit permission policies

Regularly review your custom permission policies to ensure that permission assignments match the actual responsibilities of team members.

  • Audit frequency: Audit at least once per quarter, or immediately when team members join, leave, or change roles.

  • Focus areas:

    • Whether former employees or transferred staff still have write permissions.

    • Whether any policies use the * wildcard without a Deny safety net.

    • Whether any RAM users hold multiple permission policies that result in excessive combined permissions.

  • Audit tool: Use ActionTrail to view the actual operation records of STAROps resources and assess whether permissions are reasonable.