Skip to main content

Security & Automation

This page is mainly for skill maintainers, delivery teammates, and automation integrators. Business users usually only need to remember two things: say “read-only” for read scenarios, and say “preview first” for write scenarios.

What this safety model is protecting​

Lovrabet CLI can both read and write business data.
Without guardrails, an Agent that misunderstands a request could send a real write into a real system.

So the runtime CLI focuses on three simple rules:

  • permissions cannot be raised casually
  • high-risk actions cannot run silently
  • writes should usually be previewed first

Layer 1: riskLevel​

Every command has a built-in risk level:

read < write < high-risk-write
LevelTypical actions
readdata filter, data getOne, data aggregate, dataset list
writedata create, data update, config set, app use
high-risk-writedata delete

If the configured riskLevel is too low, the CLI blocks the command immediately.

riskLevel cannot be changed through CLI commands

This is intentional. Permission changes must be made by a human editing the config file, not by an Agent raising its own privilege.

Layer 2: high-risk confirmation​

For high-risk actions such as data delete, riskLevel is not the only protection.
There is also an explicit confirmation step.

Interactive mode:

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

Non-interactive mode:

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

Layer 3: --dry-run​

For write commands, previewing first is the safer path:

lovrabet data create --code <datasetCode> --params '{"name":"test"}' --dry-run

Why this matters:

  • you can see what the CLI is about to do
  • you can catch wrong parameters early
  • you can confirm the target object is really the one you want to change

This is especially important in Agent-driven flows.

When the CLI switches to non-interactive mode​

The CLI treats these cases as non-interactive:

  • --non-interactive or --ci
  • LOVRABET_CI=true
  • CI=true
  • stdout is not a TTY, such as redirected or piped output

Once that happens, high-risk actions cannot rely on an interactive prompt.
They must use --yes.

Safer CI and Agent automation​

Recommended setup:

  1. log in with an AccessKey
  2. decide the default app candidate, environment, and risk boundary in advance
  3. use --dry-run before normal writes whenever possible
  4. require --yes for high-risk writes
  5. use --format json or compress for downstream automation

Example:

script:
  - lovrabet data filter --code $DATASET_CODE --format json > backup.json
  - lovrabet sql exec --sqlcode $SQL_CODE --params '{"date":"2026-04-20"}' --format json > report.json

The most useful wording for business users​

If a business user is talking to an Agent, the two most practical phrases are:

  • Read-only. Do not write data.
  • Preview first, then execute after confirmation.

Those two lines reduce a lot of avoidable mistakes.

The most useful rule for maintainers​

If a flow should not reach a real write by default, do not rely only on verbal rules.

The safer pattern is:

  • let the skill default to read-only commands
  • add an explicit confirmation step before writes
  • wait for human approval before continuing

That is much cheaper than investigating why an Agent changed real data.