Skip to main content

Lovrabet CLI Risk Level (riskLevel) Complete Guide

This page is mainly for skill maintainers, delivery teammates, and automation integrators. Business users usually only need to know one thing: reads and writes have different safety boundaries, and writes should usually be previewed first.

What riskLevel is for​

riskLevel is the permission guardrail of Lovrabet Runtime CLI.

It does not answer:

Do you want to run this command?

It answers:

Is this command allowed under the current configuration?

If a command’s risk is higher than the configured riskLevel, the CLI blocks it.

There are only three levels​

Risk LevelValueMeaningTypical Commands
read0read-onlydataset list, data filter, data getOne, data aggregate, sql exec, bff exec
write1normal writesdata create, data update, config set, app use
high-risk-write2irreversible writesdata delete

Core comparison:

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

Why you cannot change riskLevel through CLI​

This is a deliberate safety boundary.

If an Agent could run:

lovrabet config set riskLevel high-risk-write

then it could raise its own permission first and delete or batch-write data afterward.
That would defeat the whole guardrail.

So the current rule is:

  • you can read riskLevel through the CLI
  • you cannot change riskLevel through the CLI
  • a real change must be made by a human editing the config file

How to set it now​

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

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

The current runtime CLI is centered on a top-level intent-focused config.
Do not treat the old local multi-app profile model as the main path anymore.

What the default is​

The current default is:

write

That means:

  • reads are allowed by default
  • normal writes are allowed by default
  • deletes and similar high-risk actions still require a higher level

Typical blocked scenarios​

Scenario 1: current level is read, but you try to update data​

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

The CLI blocks it because the current permission only allows reads.

Scenario 2: current level is write, but you try to delete data​

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

The CLI also blocks it because deletion is high-risk-write.

riskLevel and --dry-run are not the same thing​

People often mix them together, but they solve different problems:

  • riskLevel decides whether you are allowed to run the command
  • --dry-run decides whether the command should really execute now

So:

  • if you have permission but want to preview first, use --dry-run
  • if you do not have permission, fix riskLevel first

Why deletion still needs one more confirmation​

Because riskLevel only says:

this kind of action is allowed

It does not say:

this exact record is definitely the one you intended to delete

So data delete still has an extra protection layer:

  • interactive mode asks for confirmation
  • non-interactive mode requires --yes

That combination is much closer to the level of safety needed in real production work.

Practical advice for maintainers​

If you mainly touch production​

Be conservative:

{
  "riskLevel": "read"
}

That means the Agent can inspect, but not write by default.

If you mainly do routine delivery or test-environment maintenance​

This is usually reasonable:

{
  "riskLevel": "write"
}

That allows backfills and fixes, but still does not allow direct deletion.

If you really need to delete​

Make sure all of these are true:

  1. riskLevel already allows it
  2. you checked the target record carefully
  3. you preferably previewed first
  4. in non-interactive mode, you explicitly added --yes

The simplest explanation for business users​

If someone asks:

Why can’t the Agent just delete it directly?

The shortest answer is:

Because the system treats deletion as a high-risk action, so a human must explicitly allow it and confirm it first.

That is not unnecessary friction. It is protection for real business data.

FAQ​

Q: Why can't riskLevel be changed via lovrabet config set?

To prevent AI Agents or automation scripts from escalating privileges on their own. If the CLI were allowed to modify it, an Agent would only need a single command to escalate from read to high-risk-write, bypassing all protections. Forcing manual configuration file editing ensures that only a human with direct file system access can change permissions.

Q: What is the default riskLevel?

The default is write. This means that after installation, you can perform read and write operations, but deletion operations require manually changing riskLevel to high-risk-write in the configuration file.

Q: How do I set different riskLevels for different environments in a multi-app configuration?

Set riskLevel individually for each profile in the apps section of .lovrabet.json. The recommended practice is to set production environments to read and testing environments to high-risk-write.

Q: What is the relationship between --dry-run and riskLevel?

They are independent mechanisms. --dry-run is a preview (does not execute); riskLevel is a permission check (controls whether execution is allowed). Even if riskLevel is set to read, using --dry-run on a write command will still be blocked by riskLevel.

Q: How can I quickly check the current riskLevel?

lovrabet config get riskLevel

Q: What should an AI Agent do when it encounters insufficient permissions?

The Agent should prompt the human to manually edit the .lovrabet.json file and change riskLevel to the required level. The Agent itself should not — and cannot — modify this configuration.

Key Takeaways​

  • riskLevel has three tiers: read < write < high-risk-write, with permissions determined by numeric comparison
  • riskLevel can only be changed by manually editing .lovrabet.json; CLI commands are prohibited from modifying it
  • This is designed to prevent AI Agents and automation scripts from escalating privileges
  • Configuration priority: app profile > top-level configuration > default value (write)
  • The CLI has four layers of security: manual setting → riskLevel enforcement → high-risk confirmation → dry-run preview
  • Production environments should be set to read; testing environments can be set to high-risk-write
  • In CI environments, riskLevel should be pre-configured in the configuration file, and high-risk operations must include --yes