Documentation menu

Docs Security and deployment

Access record

Verbiqo records every read it makes of the systems it is connected to: each statement, command, request and search, as it was sent. The record is on for everyone, kept on each computer, and can be sent on to your SIEM.

What each entry holds

FieldHolds
atWhen, in UTC.
system, connection, target, accountWhich system (pg, mysql, mssql, redis, es, k8s, prom, splunk), which saved connection, the host it reached, and the account used. For a Kubernetes context signed in through an exec plugin, the account is the plugin’s command, as aws (exec plugin).
action, textWhat was sent: query; plan (a statement only planned, never run); command; request (an API call, a Splunk search included); sign-in; probe (a request without credentials, to see what the server shows anyone); tls-handshake (the security review reading a certificate, no credentials sent); access-review (Kubernetes asking what Verbiqo’s own account may do). Prometheus records the API path it called. The text exactly as sent.
outcomeok, error, refused (stopped by Verbiqo before it was sent), limited (stopped by your limits) or sent.
originWho decided: model (the AI asked for it), verbiqo (Verbiqo’s own checks) or person (typed at the command line).
question, user, computerA random identifier for the question the read belonged to (never its text), so one question’s reads can be grouped; who asked, on which computer.
rows, durationMs, errorHow much came back, how long it took, and why it failed.

Never recorded: passwords, tokens and keys (a sign-in is recorded with its secret masked), and request bodies, which are recorded by size and fingerprint only.

Where it is kept

ComputerFile
Mac~/Library/Application Support/Verbiqo/access-log.jsonl
Windows%LOCALAPPDATA%\Verbiqo\access-log.jsonl
Linux (command line)~/.local/state/verbiqo/access-log.jsonl

One JSON object per line, readable only by the user. Rotated at 20 MB; five files are kept. verbiqo audit path prints the file in use. In a terminal, VERBIQO_ACCESS_LOG names another file; VERBIQO_ACCESS_LOG=off turns the record off for that command, unless the organization requires it.

Read, export and check it

verbiqo audit show --since 24h
verbiqo audit show --origin model --system mssql
verbiqo audit export --format csv --since 30d --output verbiqo-access.csv
verbiqo audit verify

Tamper-evident. Each entry carries the hash of the one before it. verify reports the first entry that was changed, removed or inserted.

Send it to your SIEM

Set Send the access record to (auditForward in the managed settings; in a terminal, VERBIQO_AUDIT_FORWARD), as JSON:

{
  "syslog": "tls://siem.example.com:6514",
  "ca": "/Library/Application Support/Verbiqo/company-ca.pem"
}
{
  "splunkHec": {
    "url": "https://splunk.example.com:8088",
    "token": "your-hec-token",
    "index": "verbiqo",
    "sourcetype": "verbiqo:access"
  }
}
  • Syslog over udp://, tcp:// or tls://: RFC 5424, facility log audit, each message the entry’s JSON. The port defaults to 6514 for TLS and 514 otherwise. ca, at the top level, is a private CA for the TLS connection.
  • Splunk HTTP Event Collector: index and sourcetype are optional; the sourcetype defaults to verbiqo:access. A HEC token can only send events, not read them.
  • Both may be set in one object; the keys are syslog, splunkHec and ca, and the generator refuses anything else.
  • Nothing is lost. Entries go at the end of each question. While the SIEM is unreachable they wait in the local file and go with the next question, or now with verbiqo audit forward.

Require it

Set Require the access record (auditRequired in the managed settings; in a terminal, VERBIQO_AUDIT_REQUIRED=1). Verbiqo then reads nothing it cannot record first. Without it, a record that cannot be written never stops a question.

Something missing or unclear? Email hello@verbiqo.app.