Risk Level (riskLevel) Complete Guide

This document explains the risk control mechanism in Rabetbase CLI (development mode). riskLevel is a built-in permission guardrail that prevents accidental irreversible changes, such as inadvertently deploying or deleting BFF scripts.

What is riskLevel

riskLevel is Rabetbase CLI's command execution permission guardrail. Every command has a predefined risk level. Before executing, the CLI compares the configured riskLevel against the risk level required by the command. If the configured permission is insufficient, the command is blocked with a clear error message.

Important security design:

riskLevel cannot be changed via CLI commands (including config set). It can only be set by manually editing the .rabetbase.json configuration file. This prevents AI Agents or automation scripts from escalating privileges on their own -- any permission change must be an intentional human action.
riskLevel has no environment variable override, preventing AI from temporarily modifying environment variables to bypass security controls.

Three-Tier Risk System

The CLI defines three risk levels, from lowest to highest:

Risk Level	Value	Meaning	Typical Commands
read	0	Read-only operations; no data is modified	dataset list/detail, sql list/detail/exec, bff list/detail/status, api list, codegen sql/sdk, doctor, run
write	1	Write operations that create or modify data	bff new, bff pull, sql save, api pull, app add/use, config set, project init/upgrade, menu sync/update
high-risk-write	2	Irreversible operations; once overwritten or deleted, data cannot be recovered	bff push (deploy and overwrite), bff delete (delete script)

Core Evaluation Logic

The CLI uses numeric comparison internally to determine whether permission is sufficient:

read(0) < write(1) < high-risk-write(2)

Rule: A command is allowed to execute only when its risk level value is less than or equal to the configured riskLevel.

Rabetbase CLI defaults riskLevel to high-risk-write (unrestricted). This is because the development mode targets developers who frequently push and delete BFF scripts. If you want to tighten permissions in AI Agent or CI scenarios, you need to set it manually in the configuration file.

Recommended configuration strategy:

Local development (human operation): Leave unset or set to high-risk-write for unrestricted access
AI Agent-assisted development: Set to write to prevent AI from directly pushing or deleting BFF scripts
CI/CD pipelines: Set according to pipeline needs; push operations require high-risk-write

How to Set riskLevel

Changing riskLevel via CLI is intentionally blocked: Running rabetbase config set --key riskLevel --value write will be rejected. The CLI will error: "riskLevel" cannot be changed via the CLI. This is an intentional security restriction.

The Only Way: Manually Edit the Configuration File

Open .rabetbase.json in the project root and edit the riskLevel field directly:

Single-app configuration:

{
  "appcode": "app-xxxxxxxx",
  "riskLevel": "write"
}

Multi-app configuration (recommended, differentiated by environment):

{
  "apps": {
    "prod": {
      "appcode": "app-xxxxxxxx",
      "env": "production",
      "riskLevel": "write"
    },
    "daily": {
      "appcode": "app-yyyyyyyy",
      "env": "daily",
      "riskLevel": "high-risk-write"
    }
  },
  "defaultApp": "prod"
}

Configuration precedence: riskLevel in app profile > top-level riskLevel > default value (high-risk-write). Recommended practice: set production environment profiles to write to prevent AI Agents from pushing directly to production; set local daily environment to high-risk-write for unrestricted development.

Viewing the Current riskLevel

rabetbase config get --key riskLevel

Or view the full configuration:

rabetbase config list

Permission Blocking in Detail

Scenario 1: Attempting to push a BFF script when riskLevel=write

When .rabetbase.json is configured with "riskLevel": "write":

rabetbase bff push --code my-bff-script

Output (interactive mode):

Command `rabetbase bff push` has risk level "high-risk-write", which exceeds the configured riskLevel "write".
  Edit the config file manually and set riskLevel to "high-risk-write".

A human must manually edit .rabetbase.json, change riskLevel to "high-risk-write", and re-run the command.

Scenario 2: Attempting to save SQL when riskLevel=read

rabetbase sql save --code my-sql --params {...}

Output (interactive mode):

Command `rabetbase sql save` has risk level "write", which exceeds the configured riskLevel "read".
  Edit the config file manually and set riskLevel to "write".

Scenario 3: Attempting to change riskLevel via CLI

rabetbase config set --key riskLevel --value high-risk-write

Output:

"riskLevel" cannot be changed via the CLI.

This is expected behavior. Even if an AI Agent or automation script discovers this command, it cannot escalate privileges. Only a human with direct file system access can modify riskLevel.

Scenario 4: Pushing a BFF script when riskLevel=high-risk-write

When riskLevel is set high enough, the push command is no longer blocked by riskLevel, but it triggers the high-risk operation confirmation mechanism (see the next section).

High-Risk Operation Confirmation Mechanism

Commands at the high-risk-write level (bff push, bff delete) have an additional confirmation layer. Even when riskLevel is already set to high-risk-write, explicit confirmation is still required.

Interactive Mode (Local Terminal)

rabetbase bff push --code my-bff-script

Output:

High-risk operation: rabetbase bff push
   Deploy BFF script to production (overwrites existing)
   Affected: code=my-bff-script
   Continue? [y/N]:

Type y or yes to confirm execution. Any other input (including pressing Enter) cancels the operation.

Non-Interactive Mode (CI/CD, Scripts, Piped Output)

In non-interactive mode, you must use the --yes flag:

rabetbase bff push --code my-bff-script --yes

If --yes is omitted:

High-risk operation `rabetbase bff push` requires --yes in non-interactive mode.

Conditions That Trigger Non-Interactive Mode

The CLI enters non-interactive mode when any of the following conditions is true:

The --non-interactive or --ci flag is used
The environment variable RABETBASE_CI=true is set
The environment variable CI=true is set (automatically set by GitHub Actions / GitLab CI)
stdout is not a TTY (piped or redirected output)
stdin does not support raw mode

--dry-run Preview: A Safety Net Before Execution

For commands that support dry-run, you can use --dry-run to preview what will be executed without actually running it.

rabetbase bff push --code my-bff-script --dry-run

Output:

{
  "ok": true,
  "command": "rabetbase bff push",
  "risk": "high-risk-write",
  "dryRun": true,
  "data": {
    "method": "POST",
    "url": "/api/bff/deploy",
    "body": { "code": "my-bff-script" }
  }
}

Recommended workflow: Run with --dry-run first to verify parameters, then execute for real. This is especially important in production environments.

Complete Command Risk Level Reference

read (read-only, always allowed)

Command	Description
dataset list / detail / operations / links	View datasets
sql list / detail / exec / validate	View and execute SQL queries
bff list / detail / status	View BFF scripts
api list	View API list
codegen sql / sdk	Generate code
app list / remote	View app profiles
config list / get	View configuration
auth login	Browser-based login (read-only authentication)
logs list	View command logs
doctor	Environment diagnostics
run	Execute package.json scripts

write (write operations, requires riskLevel >= write)

Command	Description
bff new	Create a new BFF script
bff pull	Pull BFF script to local
sql save	Save SQL to the platform
api pull	Pull API definitions to local
api doc	Generate API documentation
app add / use / remove	Add, switch, or remove app profiles
config set	Modify configuration fields
project init / upgrade	Project initialization and upgrade migration
menu sync / update	Menu sync and update
auth logout	Log out
logs clear	Clear command logs
update	Upgrade the CLI
skill	Install/manage Skills

high-risk-write (high risk, requires riskLevel = high-risk-write)

Command	Confirmation Required	Supports dry-run	Description
bff push	Yes (interactive or `--yes`)	Yes	Deploy BFF script to platform (irreversible overwrite)
bff delete	Yes (interactive or `--yes`)	No	Delete BFF script (irreversible)

Four-Layer Security Defense Summary

Rabetbase CLI applies four progressive layers of protection for dangerous operations:

Layer 1: riskLevel can only be set manually riskLevel cannot be changed via CLI commands; it must be manually edited in .rabetbase.json by a human. AI Agents and automation scripts cannot escalate privileges. This is the most fundamental defense line.

Layer 2: riskLevel blocking Configuration-level permission control. Commands are rejected outright when their risk exceeds the configured riskLevel. Applies to: all write and high-risk-write commands.

Layer 3: High-risk confirmation prompt Interactive mode displays a confirmation prompt; non-interactive mode requires the --yes flag. Applies to: bff push, bff delete.

Layer 4: --dry-run preview Preview the full request content before execution without actually sending it. Applies to: high-risk commands that support dry-run, such as bff push.

Practical Scenarios

Scenario 1: AI Agent-Assisted Development (Recommended Configuration)

// .rabetbase.json
{
  "apps": {
    "prod": { "appcode": "app-xxxxxxxx", "env": "production", "riskLevel": "write" },
    "daily": { "appcode": "app-yyyyyyyy", "env": "daily", "riskLevel": "high-risk-write" }
  },
  "defaultApp": "daily"
}

# AI Agent can: query, create BFF, pull code, save SQL (unrestricted in daily environment)
rabetbase bff list
rabetbase bff new --code my-feature
rabetbase sql save --code my-query

# AI Agent cannot (blocked by riskLevel=write in prod environment):
rabetbase bff push --code my-feature  # Blocked; requires human to manually change config

Scenario 2: Complete Security Workflow for BFF Deployment

# 1. Human manually sets riskLevel to "high-risk-write" in .rabetbase.json

# 2. Check current BFF status
rabetbase bff status --code my-feature

# 3. Dry-run to preview deployment
rabetbase bff push --code my-feature --dry-run

# 4. After confirming everything looks correct, deploy for real (interactive mode will prompt for confirmation)
rabetbase bff push --code my-feature

Scenario 3: Secure Configuration in CI/CD Pipelines

# .gitlab-ci.yml
deploy:
  script:
    # riskLevel is pre-set to high-risk-write in .rabetbase.json
    # This file was reviewed and committed by a human; AI Agents cannot dynamically escalate via CLI
    - rabetbase bff push --code $BFF_CODE --yes --non-interactive

In CI environments, CI=true is automatically set by GitLab/GitHub, which puts the CLI into non-interactive mode. High-risk operations require --yes. riskLevel should be pre-configured in the CI environment's configuration file rather than dynamically modified in scripts.

Frequently Asked Questions

Q: Why can't I change riskLevel via rabetbase config set? To prevent AI Agents or automation scripts from escalating privileges on their own. If the CLI could modify riskLevel, an Agent would only need a single command to elevate from write to high-risk-write, bypassing all protections. Requiring manual file editing ensures only humans with direct file system access can change permissions.

Q: What is the default riskLevel? The default is high-risk-write (unrestricted). This is because the development mode targets developers who perform frequent operations. If you need restrictions, set it manually in the configuration file.

Q: What should an AI Agent do when it encounters insufficient permissions? The Agent should prompt the human to manually edit .rabetbase.json and change riskLevel to the required level. The Agent itself should not (and cannot) modify this configuration.

Q: How do I set different riskLevel values for different environments in a multi-app configuration? Set riskLevel individually for each profile in the apps section of .rabetbase.json. Recommended: set production environment profiles to write and daily environment to high-risk-write.

Q: Why are bff push and bff delete classified as high-risk-write? bff push directly overwrites scripts running on the platform -- a bad deploy can affect live production. bff delete removes scripts with no way to recover them. Both operations are as irreversible as a database deletion, so they are assigned the highest risk level.

Q: How do I quickly check the current riskLevel?

rabetbase config get --key riskLevel

Key Takeaways

riskLevel has three tiers: read < write < high-risk-write, evaluated via numeric comparison
riskLevel can only be changed by manually editing .rabetbase.json; CLI commands cannot modify it
This is to prevent AI Agents and automation scripts from escalating privileges
Default value is high-risk-write (unrestricted); the development mode targets developers and imposes no restrictions by default
Configuration precedence: app profile > top-level config > default value (high-risk-write)
The CLI has four layers of security defense: manual setting -> riskLevel blocking -> high-risk confirmation -> dry-run preview
For AI Agent scenarios, set production profiles to write to prevent accidental pushes
In CI environments, riskLevel should be pre-configured in the configuration file; high-risk operations require --yes

What is riskLevel​

Three-Tier Risk System​

Core Evaluation Logic​

How to Set riskLevel​

The Only Way: Manually Edit the Configuration File​

Viewing the Current riskLevel​

Permission Blocking in Detail​

Scenario 1: Attempting to push a BFF script when riskLevel=write​

Scenario 2: Attempting to save SQL when riskLevel=read​

Scenario 3: Attempting to change riskLevel via CLI​

Scenario 4: Pushing a BFF script when riskLevel=high-risk-write​

High-Risk Operation Confirmation Mechanism​

Interactive Mode (Local Terminal)​

Non-Interactive Mode (CI/CD, Scripts, Piped Output)​

Conditions That Trigger Non-Interactive Mode​

--dry-run Preview: A Safety Net Before Execution​

Complete Command Risk Level Reference​

read (read-only, always allowed)​

write (write operations, requires riskLevel >= write)​

high-risk-write (high risk, requires riskLevel = high-risk-write)​

Four-Layer Security Defense Summary​

Practical Scenarios​

Scenario 1: AI Agent-Assisted Development (Recommended Configuration)​

Scenario 2: Complete Security Workflow for BFF Deployment​

Scenario 3: Secure Configuration in CI/CD Pipelines​

Frequently Asked Questions​

Key Takeaways​

What is riskLevel

Three-Tier Risk System

Core Evaluation Logic

How to Set riskLevel

The Only Way: Manually Edit the Configuration File

Viewing the Current riskLevel

Permission Blocking in Detail

Scenario 1: Attempting to push a BFF script when riskLevel=write

Scenario 2: Attempting to save SQL when riskLevel=read

Scenario 3: Attempting to change riskLevel via CLI

Scenario 4: Pushing a BFF script when riskLevel=high-risk-write

High-Risk Operation Confirmation Mechanism

Interactive Mode (Local Terminal)

Non-Interactive Mode (CI/CD, Scripts, Piped Output)

Conditions That Trigger Non-Interactive Mode

--dry-run Preview: A Safety Net Before Execution

Complete Command Risk Level Reference

read (read-only, always allowed)

write (write operations, requires riskLevel >= write)

high-risk-write (high risk, requires riskLevel = high-risk-write)

Four-Layer Security Defense Summary

Practical Scenarios

Scenario 1: AI Agent-Assisted Development (Recommended Configuration)

Scenario 2: Complete Security Workflow for BFF Deployment

Scenario 3: Secure Configuration in CI/CD Pipelines

Frequently Asked Questions

Key Takeaways