Protect your systems

Verbiqo only reads, and every read is bounded. If your systems need more protection than that, you can set limits on how hard Verbiqo works them. Nothing changes until you do.

What Verbiqo always does

System	On every read
PostgreSQL	Read-only transactions, closed at once. 15-second statement timeout, 2-second lock timeout. Each statement is planned first and refused if it would be costly or read many rows. Superuser accounts are refused.
MySQL	Read-only session. 15-second execution limit, 2-second lock wait. Each statement is planned first and refused if it would read too many rows. Accounts that can write are refused.
SQL Server	Sessions named `verbiqo`, with a 2-second lock timeout, low deadlock priority and a 15-second request timeout. Each statement’s estimated plan is read first and the statement refused if it would be costly or read many rows. Logins in an administrative server role, or holding any permission beyond reading, are refused.
Redis and Valkey	Only commands on a read-only list (INFO, SLOWLOG GET, LATENCY, MEMORY STATS, CLIENT LIST, CONFIG GET and the like); never a key. 10-second command timeout. The slow log is read 128 entries at most. Users that can administer are refused.
Elasticsearch and OpenSearch	Monitoring and metadata requests only, never documents. 15-second timeout. Accounts that can write or manage are refused.
Kubernetes	Lists only, 500 objects a page, at most 5,000 of a kind (3,000 events and replica sets), three requests at a time, 20-second request timeout. Never Secrets or ConfigMaps, nothing watched. Accounts that can change the cluster are refused.
Prometheus and Thanos	10-second query timeout (Thanos 30). At most 1,000 series a query and 7 days a range. It stops when the server says it is overloaded.
Splunk	Every search has a time window of at most 7 days, a 120-second limit and at most 10,000 events. Write commands and subsearches are refused.

Within one question, the model asks for a handful of reads (six for the databases, Redis and Elasticsearch; eight for Kubernetes) besides the checks Verbiqo runs itself, and reads one at a time; Prometheus reads up to three at once, Kubernetes up to three pages at once.

Limits you can add

Each applies to every system ("all") or to one: "pg", "mysql", "mssql", "redis", "es", "k8s", "prom", "splunk".

Limit	Caps	Range
`queriesPerQuestion`	Queries or requests to a system for one question, Verbiqo’s own checks included	1 to 1000
`questionSeconds`	Time spent reading a system for one question	10 to 3600
`queryTimeoutSeconds`	How long any one query may run	1 to 600
`parallelQueries`	Queries to a system at the same time	1 to 16
`questionsPerHour`	Questions to a system per hour, on each computer	1 to 10000

Only ever tighter. A limit never raises Verbiqo’s own: a query timeout of 60 still leaves PostgreSQL at 15 seconds.
Off unless you set it. A limit you leave out is not applied.
The lower wins. Set in both the privacy policy and managed settings, the lower applies.

Where to set them

In the privacy policy, signed, so nobody at the computer can change them. Needs "schemaVersion": 5:

"limits": {
  "all": { "queriesPerQuestion": 40, "questionsPerHour": 60 },
  "pg": { "queryTimeoutSeconds": 10 }
}

Or in managed settings, with no signing: extensionLimits in the Mac profile, ExtensionLimits (JSON text) in the Windows registry. verbiqo policy settings writes both from the same object (Make the files). A running Verbiqo picks either up within half a minute.

What people see

A question that reaches a limit keeps what it read. Each read it could not make shows as refused, with your organization’s limit as the reason, and the answer is written from what was read.
A question over the hourly limit is not started, and says when the next can be.

The hourly count is kept on each computer. It spreads load; it is not a security control.

Try it on one computer

Without deploying anything, set the limits for one command in a terminal:

VERBIQO_EXTENSION_LIMITS='{"prom":{"queriesPerQuestion":5}}' verbiqo prom ask prod "why did cpu spike today"

The first five reads run; the rest show as refused with the limit as the reason. Without the variable, the same question runs as before.

Cap the total load at each system

Limits in Verbiqo apply to each computer. Most organizations give Verbiqo one read-only account per system, so capping that account caps everyone at once:

System	Cap
PostgreSQL	`ALTER ROLE verbiqo CONNECTION LIMIT 5;` Verbiqo sets its own statement timeout on each session, so cap time with `queryTimeoutSeconds` above.
MySQL	`ALTER USER 'verbiqo'@'%' WITH MAX_USER_CONNECTIONS 5 MAX_QUERIES_PER_HOUR 2000;`
SQL Server	Resource Governor: a workload group for the login (its sessions carry the application name `verbiqo`), with `REQUEST_MAX_CPU_TIME_SEC` and `MAX_DOP`. Verbiqo sets its own 15-second request timeout, so cap time with `queryTimeoutSeconds` above.
Redis and Valkey	No limit per user: use the limits above.
Kubernetes	API Priority and Fairness: a `FlowSchema` matching Verbiqo’s service account, bound to a low `PriorityLevelConfiguration`.
Elasticsearch and OpenSearch	No limit per account: use the limits above.
Prometheus	Server-wide: `--query.max-concurrency` and `--query.timeout`. Thanos Query: `--query.max-concurrent` and `--query.timeout`.
Splunk	On the role Verbiqo’s account has, in `authorize.conf`: `srchJobsQuota` (searches at once per user), `cumulativeSrchJobsQuota` (for everyone with the role), `srchMaxTime`, `srchDiskQuota`.

Different limits for different teams: give each its own policy or managed settings (Different rules for different groups).