All Products
Search
Document Center

Alibaba Cloud CLI:Safety policy

Last Updated:Jun 22, 2026

Safety policies provide client-side protection for Alibaba Cloud CLI operations. When enabled, the CLI matches each command against configured rules to allow, deny, or require manual confirmation for the operation.

Overview

Safety policies define a set of rules. Each rule consists of a pattern (matching criteria) and an action (response type):

  • allow (permit): Explicitly permit the operation and skip further rule evaluation. Place an allow rule before broader deny or confirm rules to create exemptions for specific operations.

  • deny (block): Block the operation entirely. The CLI rejects the command and does not send the API request.

  • confirm (require approval): In an interactive terminal, the CLI prompts you to type yes before proceeding. In a non-interactive environment, the CLI returns an error with instructions for the caller.

Safety policies apply to both OpenAPI calls (RPC and RESTful) and plugin commands. They complement server-side access control (RAM) but do not replace RAM permission policies.

Scenarios

  • AI agent safety guardrails: When an AI agent uses the CLI to manage cloud resources, a safety policy can intercept destructive operations (such as delete operations) and require human confirmation or block them entirely, providing a human-in-the-loop (HITL) mechanism.

  • Operational safeguards: Configure default rules for team CLI environments to prevent accidental execution of destructive operations such as deleting resources or stopping instances.

Prerequisites

  • Alibaba Cloud CLI v3.3.14 or later is installed. Run the following command to check your current version:

    aliyun version
  • CLI credentials are configured. If you have not configured credentials, run the following command:

    aliyun configure

Manage safety policies

Safety policies are managed through the aliyun configure safety-policy command family.

View current policy

Run the following command to view the safety policy configuration in JSON format:

aliyun configure safety-policy show

Sample output:

{
  "enabled": false,
  "rules": []
}

Enable and disable

# Enable safety policy
aliyun configure safety-policy enable

# Disable safety policy
aliyun configure safety-policy disable

Run aliyun configure safety-policy show to verify that the enabled field is true.

Add rules

Command syntax:

aliyun configure safety-policy add --pattern <pattern> --action <deny|confirm>

Example: Block all delete operations across all products:

aliyun configure safety-policy add --pattern '*:Delete*' --action deny

Example: Require human confirmation for ECS update operations:

aliyun configure safety-policy add --pattern 'ecs:Update*' --action confirm

Run aliyun configure safety-policy list to verify that the rule has been added.

Note

If you add a rule with a pattern that already exists, the CLI updates the action for that pattern instead of creating a duplicate entry.

Note

The add subcommand accepts only deny, confirm, and forbid as action values. To configure an allow rule, set the ALIBABA_CLOUD_SAFETY_POLICY_RULES environment variable or directly edit the configuration file.

Remove rules

Specify the exact pattern to remove a rule:

aliyun configure safety-policy remove --pattern '*:Delete*'

List rules

Run the following command to view all rules in a formatted list:

aliyun configure safety-policy list

Sample output:

Safety policy: enabled
Config file: /home/user/.aliyun/safety-policy.json

Rules:
  1. *:Delete* -> deny
  2. ecs:Update* -> confirm

Rule syntax

Pattern format

The --pattern parameter uses the format {product}:{operation} and supports the * wildcard to match any character sequence. Pattern matching is case-insensitive:*:Delete*, *:DELETE*, and *:delete* all match the same operations.

The CLI constructs different command identifiers depending on the API style:

API style

Pattern format

Example

RPC

{product}:{ApiName}

ecs:DeleteInstance

RESTful

{product}:{HTTP_METHOD}/path

cs:DELETE/clusters

Plugin

{product}:{subcommand}

fc:delete-function

Common pattern examples:

Pattern

Matches

*:Delete*

All operations containing "Delete" across all products (case-insensitive)

ecs:delete-instance

Only the ECS delete-instance operation

ecs:Update*

All ECS operations starting with "Update"

*:*

All operations across all products

Note

When you run commands in a shell, enclose pattern values in single quotes (for example, '*:Delete*') to prevent the shell from expanding the * wildcard.

Action values

Action

Behavior

allow

Explicitly permit the operation. In a first-match-wins rule system, place an allow rule before broader deny or confirm rules to create exemptions for specific operations.

deny

Block the operation and return an error. The CLI does not send the API request.

confirm

Prompt for confirmation in an interactive terminal. The user must type yes to proceed.

forbid is an alias for confirm. They produce identical runtime behavior.

If no rule matches, the operation is allowed by default (implicit allow). Explicit allow rules are used to create exemptions before broader deny or confirm rules.

Rule evaluation order

Rules are evaluated from top to bottom in the configured order, using a first-match-wins strategy: the first matching rule takes effect and subsequent rules are not checked. If no rule matches, the default is to allow execution.

For example, given the following two rules:

  1. ecs:Delete* → confirm

  2. *:Delete* → deny

When you run aliyun ecs delete-instance, the first rule (ecs:Delete*) matches, and the confirm action is applied — not the second rule's deny.

Using allow to create exemptions:

  1. ecs:Describe* → allow

  2. ecs:* → deny

Running aliyun ecs DescribeInstances matches the first allow rule and the operation proceeds normally. Running aliyun ecs DeleteInstance matches the second rule and is blocked.

Important

Rule order matters. When adding rules, ensure that more specific rules appear before more general rules.

Non-interactive mode and AI agent scenarios

The --yes flag

When you specify the --yes (or -y) flag, confirm rules are automatically skipped (treated as approved). deny rules are not affected and still block execution.

# confirm rules are skipped, operation executes directly
aliyun ecs update-instance --InstanceId i-bp1xxxxx --yes

# deny rules are not affected, operation is still blocked
aliyun ecs delete-instance --InstanceId i-bp1xxxxx --yes
# Output: ERROR: operation blocked by safety policy: ecs delete-instance (rule: *:Delete*)

You can also set the ALIBABA_CLOUD_SAFETY_SKIP_CONFIRM environment variable to true to auto-approve all confirm rules for an entire session, equivalent to passing --yes on every command:

export ALIBABA_CLOUD_SAFETY_SKIP_CONFIRM=true
Warning

Neither --yes nor ALIBABA_CLOUD_SAFETY_SKIP_CONFIRM can bypass deny rules. Operations that match a deny rule are always blocked, regardless of flags or environment variables.

Non-interactive terminal behavior

The CLI detects whether standard input is a terminal device to determine the current environment. In non-interactive environments (such as scripts, CI/CD pipelines, and AI agent runtimes), if an operation matches a confirm rule and the --yes flag is not specified, the CLI returns the following error:

Safety policy requires confirmation for: ecs update-instance
This operation cannot run in non-interactive mode without explicit approval. If you are an agent, ask the user whether this operation is allowed; after they confirm (e.g. reply yes), re-run the same command with --yes.

Recommended AI agent workflow

When an AI agent manages cloud resources through the CLI, follow these steps to configure and use safety policies:

  1. Configure safety policies: Set deny for operations that should be completely forbidden, and confirm for operations that require approval.

  2. Handle confirm prompts: When the agent encounters a confirm block, present the operation details to the user and request approval.

  3. Re-execute with approval: After the user confirms, the agent re-runs the command with the --yes flag.

Example configuration: Block delete operations and require human confirmation for update operations:

aliyun configure safety-policy enable
aliyun configure safety-policy add --pattern '*:Delete*' --action deny
aliyun configure safety-policy add --pattern '*:Update*' --action confirm

Environment variables

In addition to command-line configuration, you can control safety policies through environment variables. Environment variables take precedence over the configuration file.

Environment variable

Description

Example

ALIBABA_CLOUD_SAFETY_POLICY_ENABLED

Override the enabled value in the configuration file. Accepts true, false, 1, 0.

export ALIBABA_CLOUD_SAFETY_POLICY_ENABLED=true

ALIBABA_CLOUD_SAFETY_POLICY_RULES

Override the rule list in the configuration file. Use the format pattern=action, with multiple rules separated by commas. When set, configuration file rules are completely replaced, not merged. Set to an empty string to clear all rules. If the format is invalid, file-based rules are retained.

export ALIBABA_CLOUD_SAFETY_POLICY_RULES="ecs:Describe*=allow,*:Delete*=deny,ecs:Update*=confirm"

ALIBABA_CLOUD_SAFETY_SKIP_CONFIRM

Set to 1 or true to skip confirmation prompts, equivalent to --yes.

export ALIBABA_CLOUD_SAFETY_SKIP_CONFIRM=1

Important

When the ALIBABA_CLOUD_SAFETY_POLICY_RULES environment variable is set, the rules in the configuration file are completely replaced, not merged.

Configuration file

Safety policy configuration is stored in ~/.aliyun/safety-policy.json. If you specify the --config-path option, the safety-policy.json file is located in that custom directory.

File format example:

{
  "enabled": true,
  "rules": [
    {
      "pattern": "ecs:Describe*",
      "action": "allow"
    },
    {
      "pattern": "*:Delete*",
      "action": "deny"
    },
    {
      "pattern": "ecs:Update*",
      "action": "confirm"
    }
  ]
}
  • If the configuration file does not exist, safety policy is disabled by default and the rule list is empty. The file is automatically created when you first run the enable or add subcommand.

Note

Safety policy uses a fail-open design: if the configuration file cannot be loaded (for example, due to corruption), the CLI skips safety checks and does not block command execution.