Lovrabet CLI riskLevel: The Complete Guide

This page is mainly for Skill maintainers, delivery teams, and automation integrators. Business users generally only need to know: reads and writes have boundaries, and writes should be previewed first.

---

What riskLevel does

riskLevel is the permission guardrail of the Lovrabet Runtime CLI.

It doesn't decide "do you want to run this" — it decides "is this allowed under the current configuration".

If a command's risk level is higher than the current riskLevel, the CLI blocks it outright.

---

There are only three levels

read < write < high-risk-write

Level	What it means	Typical commands
read	Read-only	dataset list, data filter, data getOne, data aggregate, sql exec, bff exec
write	Regular writes	data create, data update, config set, app use
high-risk-write	Irreversible writes	data delete

---

Why riskLevel can't be changed through the CLI

This is a deliberate security boundary.

If the Agent could just run:

lovrabet config set riskLevel high-risk-write

it could escalate its own permissions first and then delete or batch-write — the guardrail would be meaningless.

So the current design is:

• You can read riskLevel through the CLI
• But you cannot modify riskLevel through the CLI
• Real changes must be made by a human editing the config file manually

---

How to set it now

Edit the top-level field in .lovrabet.json directly:

{
  "accessKey": "ak_xxx",
  "env": "production",
  "defaultApp": "crm",
  "riskLevel": "write"
}

The runtime CLI's main model is the top-level user-intent config. Don't build your setup around the old local multi-app profile model.

---

What the default is

The current default is:

write

This means:

• Read operations run by default
• Regular writes run by default
• High-risk actions like deletion still require a higher risk level

---

Typical blocked scenarios

Scenario 1: riskLevel is read, but you try to update data

lovrabet data update --code <datasetCode> --params '{"id":123,"status":"completed"}'

The CLI refuses to execute — the current permission only allows reads.

Scenario 2: riskLevel is write, but you try to delete data

lovrabet data delete --code <datasetCode> --params '{"id":123}'

The CLI refuses again — deletion is high-risk-write.

---

riskLevel and --dry-run are two different things

People often mix them up, but their responsibilities differ:

• riskLevel: decides whether you're qualified to run this at all
• --dry-run: decides whether it actually executes this time

Put together:

• You have permission but don't want to execute yet → use --dry-run
• You don't have permission → fix riskLevel first

---

Why high-risk deletes need one more confirmation

riskLevel only says "this class of action is allowed" — it doesn't guarantee "the record being deleted this time is really the one you mean".

So delete commands carry a second layer of protection:

• Interactive mode shows a confirmation prompt
• Non-interactive mode requires --yes

Combined, these two layers come much closer to what real production environments need.

---

Practical advice for maintainers

If you mostly face production

Lean conservative:

{
  "riskLevel": "read"
}

The Agent can then query by default, but not write.

If you do day-to-day delivery or maintain test environments

This usually works:

{
  "riskLevel": "write"
}

You can backfill and correct, but still can't delete data outright.

If you really must run a delete

Make sure at least all of these hold:

1. riskLevel already allows it
2. You've looked closely at the target records
3. Ideally run --dry-run first
4. In non-interactive mode, pass --yes explicitly

---

A one-line explanation for the business side

If a business user asks:

Why can't the Agent just delete it for me?

The simplest answer:

Because the system treats deletion as a high-risk action by default — a human must explicitly grant the permission and confirm.

That's not red tape; it's protection for real business data.