Best practices for custom STAROps permission policies - STAROps

Design principles

When configuring STAROps permissions, follow these principles:

Grant permissions by role. Administrators, regular O&M users, Long-Term Mission operators, and auditors should use different policies.
Separate user permissions from Digital Employee runtime permissions. A RAM user's ability to use STAROps does not mean that a Digital Employee can access all data. Similarly, a Digital Employee's data access does not mean the user can view data in the console.
Restrict ram:PassRole. Specify the scope to service roles or custom roles dedicated to STAROps. Do not use Resource: "*" long term.
Isolate Digital Employees by business line. Different business lines should use different Digital Employees, different RAM roles, and different data access scopes.
Prefer read-only access. For inspections, reports, alert analysis, and similar scenarios, prefer granting read-only permissions.
Be cautious with write operations. For operations that involve cloud resource changes, alert modifications, configuration deployments, or script execution, use manual confirmation, auditing, and rollback mechanisms.

Template selection

Template	Target audience	Description
Template 1: O&M administrator	Administrators who manage Digital Employees, sessions, Skills, and artifacts	High privileges. Restrict `ram:PassRole` scope in production environments.
Template 2: Regular O&M user	Users who converse with Digital Employees and view sessions and artifacts	Requires `ram:PassRole` for the target Digital Employee's RAM role.
Template 3: Per-Digital Employee authorization	Team members who can only use or manage specific Digital Employees	Requires `ram:PassRole` for the specified Digital Employee's RAM role.
Template 4: Long-Term Mission operator	O&M users who create and maintain Long-Term Missions	Requires `ram:PassRole` for the Mission's Digital Employee RAM role.
Template 5: Long-Term Mission read-only	Auditors and reviewers	View-only access to tasks, sessions, and artifacts.
Template 6: Deny high-risk delete operations	Production environments that need additional protection against delete operations	Use in combination with allow policies.

Note

The following templates can be copied directly into RAM custom permission policies. The ram:PassRole in these templates uses the service role AliyunServiceRoleForSTAROps as an example. If a Digital Employee is bound to a custom RAM role, replace the Resource value with the corresponding RoleArn.

Template 1: O&M administrator (full permissions for Digital Employees, sessions, and Skills)

Designed for O&M administrators who manage STAROps daily. Covers Digital Employee, Skill, session, and artifact management, and includes a ram:PassRole example.

Do not grant this template to all O&M users directly. In production environments, further restrict permissions by business line, Digital Employee ID, Workspace, and RoleArn.

{
  "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": [
            "operation-platform.aliyuncs.com",
            "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:CreateArtifactUploadToken",
        "starops:GetArtifactDownloadUrl",
        "starops:CreateChat"
      ],
      "Resource": [
        "acs:starops:*:*:digitalemployee/*",
        "acs:starops:*:*:digitalemployee/*/skill/*",
        "acs:starops:*:*:digitalemployee/*/thread/*",
        "acs:starops:*:*:digitalemployee/*/artifact/*"
      ]
    }
  ]
}

Template 2: Regular O&M user (conversation and view only)

Designed for SREs, DevOps engineers, or application owners who use STAROps daily. Allows viewing Digital Employees, initiating conversations, and viewing sessions and artifacts, but not creating, modifying, or deleting Digital Employees. Because conversations require the RAM role bound to the custom Digital Employee, you must also grant ram:PassRole.

{
  "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:CreateArtifactUploadToken",
        "starops:GetArtifactDownloadUrl",
        "starops:CreateChat"
      ],
      "Resource": [
        "acs:starops:*:*:digitalemployee/*",
        "acs:starops:*:*:digitalemployee/*/thread/*",
        "acs:starops:*:*:digitalemployee/*/artifact/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "acs:Service": [
            "operation-platform.aliyuncs.com",
            "cloudmonitor.aliyuncs.com"
          ]
        }
      }
    }
  ]
}

Template 3: Per-Digital Employee authorization

Designed for scenarios where Digital Employees are isolated by business line, application, or team. In this example, a user can only access a specific Digital Employee and its Skills, sessions, and artifacts, and can only pass the RAM role bound to that Digital Employee.

After copying, replace the Digital Employee ID, Workspace, and resource scope in the example with your actual values.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cms:ListDigitalEmployees",
        "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: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:CreateArtifactUploadToken",
        "starops:GetArtifactDownloadUrl",
        "starops:CreateChat",
        "starops:ListDigitalEmployeeSkillMounts"
      ],
      "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/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "cms:ListDigitalEmployees"
      ],
      "Resource": [
        "acs:cms:*:*:digitalemployee/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "starops:ListDigitalEmployees"
      ],
      "Resource": [
        "acs:starops:*:*:digitalemployee/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "acs:Service": [
            "operation-platform.aliyuncs.com",
            "cloudmonitor.aliyuncs.com"
          ]
        }
      }
    }
  ]
}

Template 4: Long-Term Mission operator (Mission management)

Designed for operators who create, update, and monitor Long-Term Missions. A Long-Term Mission requires a custom Digital Employee bound to a RAM role, which determines what data and resources the mission can access. Long-Term Mission operators therefore need ram:PassRole for the Digital Employee's RAM role.

{
  "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/*"
    },
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "acs:Service": [
            "operation-platform.aliyuncs.com",
            "cloudmonitor.aliyuncs.com"
          ]
        }
      }
    }
  ]
}

Template 5: Long-Term Mission read-only

Designed for security auditing, management reviews, and task result inspections. Allows viewing Long-Term Missions, task statuses, Digital Employees, sessions, and artifacts, but not creating, updating, or deleting Long-Term Missions.

{
  "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/*"
      ]
    }
  ]
}

PassRole authorization path

ram:PassRole controls whether a RAM user can pass a specific RAM role to STAROps. It does not grant data access permissions. When granting this permission, follow this path:

Identify the RoleArn bound to the Digital Employee.
If the Digital Employee uses the service role AliyunServiceRoleForSTAROps, set Resource to acs:ram::*:role/aliyunserviceroleforstarops.
If the Digital Employee uses a custom RAM role, set Resource to the RoleArn of that role, such as acs:ram::*:role/starops-production-sre.
Create a custom permission policy in the RAM console and attach the policy to the RAM users or user groups that need to use the Digital Employee.

Templates 2, 3, and 4 all need to include this type of PassRole authorization. Template 5 is read-only for auditing and typically does not require it.

PassRole example for the service role AliyunServiceRoleForSTAROps:

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "acs:ram::*:role/aliyunserviceroleforstarops",
      "Condition": {
        "StringEquals": {
          "acs:Service": [
            "operation-platform.aliyuncs.com",
            "cloudmonitor.aliyuncs.com"
          ]
        }
      }
    }
  ]
}

Digital Employee best practices

Custom permission policies only address what RAM users can do. Digital Employees must also follow the least-privilege principle. Otherwise, a single high-privilege agent may end up being shared across multiple teams.

Split Digital Employees by scenario

Split Digital Employees by responsibility instead of creating a single all-purpose Digital Employee:

Read-only inspection Digital Employee: Used for log queries, metric analysis, alert diagnosis, and report generation.
Change execution Digital Employee: Used for controlled execution of cloud product configuration updates, resource changes, or script operations.
Long-Term Mission Digital Employee: Used for periodic inspections, reports, and continuous analysis.
Business line Digital Employee: Isolates data and operation scopes by business lines such as payment, search, and logistics.

Bind different Digital Employees to different RAM roles. For read-only scenarios, prefer the service role AliyunServiceRoleForSTAROps. For cloud product configuration updates or resource changes, use a custom RAM role and grant only the necessary write permissions.

Restrict runtime permissions by RAM role

The RAM role bound to a Digital Employee determines what data and resources it can access at runtime. Follow these guidelines:

Use an independent RAM role for each production Digital Employee.
Name roles to reflect business lines and responsibilities, such as starops-payment-readonly and starops-payment-change.
Restrict authorization by Workspace, log project, resource group, region, or cloud product resource scope.
Use different RAM roles for read-only and write operations.
Do not use the account administrator role or full production O&M role as the Digital Employee runtime role.

Restrict PassRole by user

Grant only to users who need to create, update, or use custom Digital Employees.
Specify the Resource to service roles or custom roles dedicated to STAROps.
Use acs:Service to restrict role passing to STAROps-related services only.
Do not grant ram:PassRole to regular read-only auditors.

Manage Long-Term Missions separately

Long-Term Missions execute asynchronously and require custom Digital Employees bound to RAM roles. Follow these guidelines:

Use dedicated Digital Employees and RAM roles for Long-Term Missions.
For inspection and report tasks, prefer read-only RAM roles.
For Long-Term Missions that need to perform changes, use independent Digital Employees, independent RAM roles, and manual confirmation processes.
Periodically review the Digital Employees and RoleArns bound to Long-Term Missions to prevent tasks from retaining excessive runtime permissions over time.

Evaluate MCP and AliyunCLI configurations separately

System built-in employees do not support extended configurations such as MCP and AliyunCLI. Before enabling these capabilities for custom Digital Employees, verify the following:

Whether the tool capability must be enabled.
Whether the cloud products and resource scopes that the tool can access are restricted by the RAM role.
Whether high-risk tools have manual confirmation, execution logging, and rollback mechanisms.
Whether a separate RAM role needs to be created for tool-capable Digital Employees.

Policy verification and troubleshooting

After configuration, verify permissions in the following order:

Verification item	Verification method	Key check points
Whether the user can see target Digital Employees	Log on to STAROps and check the Digital Employee list	Get/List Digital Employee permissions
Whether the user can initiate a session	Converse with the target Digital Employee	CreateChat, CreateThread, and GetThread permissions
Whether the user can create a Long-Term Mission	Create a test Long-Term Mission	Mission Create/Update permissions
Whether PassRole fails when creating or updating a Digital Employee	Save a Digital Employee with a bound RoleArn	RAM user `ram:PassRole` and RoleArn scope
Whether the Digital Employee can read target data	Query target Workspace, logs, or cloud resources	Digital Employee RAM role permission policy
Whether the user can view reports and artifacts	Open a task report or session artifact	Artifact Get/List permissions

When troubleshooting, first determine whether the issue occurred during user operations or during Digital Employee runtime. If a user operation fails, check RAM user permissions. If role binding or usage fails, check ram:PassRole. If the Digital Employee runtime fails, check the RAM role trust policy and permission policy.

Pre-launch checklist

Before deploying to production, verify the following:

You have replaced the Digital Employee IDs, RoleArns, Workspaces, and log projects in the examples with actual values.
You have removed unnecessary Actions and Resources.
You have avoided using Resource: "*" for ram:PassRole in production environments.
You have separated read-only Digital Employees from change execution Digital Employees.
You have confirmed that Digital Employees with write capabilities have manual confirmation, auditing, and rollback processes.
You have selected custom Digital Employees bound to RAM roles for Long-Term Missions.
You have completed a real-world scenario verification using a RAM user.