Security and Automation — CI Integration Guide

This page is mainly for Skill maintainers, delivery teams, and automation integrators. Business users usually only need to know two things: state "read-only" explicitly for read-only requests, and ask for a preview first for write requests.

---

What this security model protects

The Lovrabet CLI can query data — and write it. Without guardrails, an Agent that misunderstands a request could fire a write straight into a production system.

So the runtime CLI's security focuses on three things:

• Permissions can't be raised arbitrarily
• High-risk actions can't run silently
• Writes should be previewed first

---

Layer 1: riskLevel

Every command has a preset risk level:

read < write < high-risk-write

Level	Typical actions
read	data filter, data getOne, data aggregate, dataset list
write	data create, data update, config set, app use
high-risk-write	data delete

If the configured riskLevel isn't sufficient, the CLI blocks the command outright — it does not proceed.

riskLevel cannot be changed through CLI commandsThis is intentional. Permission changes must be made by a human editing the config file; an Agent must never escalate its own permissions.

---

Layer 2: high-risk confirmation

High-risk actions like data delete require an extra confirmation even when riskLevel already allows them.

In interactive mode, a confirmation prompt appears:

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

In non-interactive mode you must pass --yes explicitly:

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

---

Layer 3: --dry-run

Always preview write commands first:

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

The value of --dry-run is direct:

• See exactly what would be executed
• Catch malformed parameters
• Confirm the target object is really the one you intend to change

For Agent scenarios, this step matters even more.

---

When non-interactive mode kicks in

The CLI treats these situations as non-interactive:

• --non-interactive or --ci passed explicitly
• LOVRABET_CI=true in the environment
• CI=true in the environment
• stdout is not a TTY — for example, redirected or piped output

Once in non-interactive mode, high-risk actions can no longer be confirmed via prompts — only via --yes.

---

Running CI / Agent automation safely

Recommended practices:

1. Log in with an AccessKey — no browser session dependency
2. Configure the default app, environment, and permission boundaries up front
3. Run --dry-run first for regular writes whenever possible
4. Require an explicit --yes for high-risk writes
5. Prefer --format json or compress for easier downstream processing

For 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

---

Advice for business users

If you make requests through an Agent, the two most useful phrases are:

• Read-only: read-only, don't write anything
• Writes: preview first, execute only after I confirm

These two phrases significantly reduce the chance of Agent misoperations.

---

Advice for maintainers

If a workflow should never end in a real write, don't rely on verbal conventions alone. Safer approaches:

• Make the skill default to read-only commands
• Force a confirmation step into write workflows
• Proceed only after explicit approval from the business user

This is far cheaper than investigating "why did the Agent change the data" after the fact.