Generic CLI connector

Generic CLI connector: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.

How-to · Updated 2026-10-23 · Describes release 0.1.164

Generated from the connector catalog (scripts/docs_integration_stubs.py); the long form of every step is Connect a datasource.

Overview

Any binary on PATH; the listed read verbs run freely, everything else is approval-gated.

Connector type key generic-cli, kind cli, listed under Custom & generic in the catalog.

Setup

Before you start

Installation

Prepare the credential on the vendor side first, scoped to reads: the platform's read gate is a floor, not a substitute for a read-only identity. The connect dialog's Connection guidance column names the vendor-side steps and the exact read permissions for this type.

Configuration

  1. Open Settings · Data in → Data sources and select Connect datasource.
  2. Under Type, choose Generic CLI connector; the list groups the types by category.
  3. Enter a Connection name; the connected list shows it, and per-connection agent tools are named after it.
  4. Fill the fields in the table below.
  5. Optionally, open Optional · describe this environment and say in What should AIOps know about it? what this system is and what matters; the agent reads it as the connection's description.
  6. Under Use this connection for, choose Investigate only and select Connect and verify.

The form shows these fields, in this order; the API key column is the key to send through the REST API.

Field (portal label) API key Stored as
Binary on PATH command plain

The same connection through the API (POST /api/aiops/{tenant_id}/datasources, datasources.manage; secret fields go in secret_values, which are stored write-only and never echoed):

{
  "type_key": "generic-cli",
  "name": "<name>",
  "description": "<what this is and what matters, for the agent>",
  "config": {
    "command": "<command>"
  },
  "role": "read",
  "enabled": true
}

Validation

Connect and verify looks for the binary on the host's PATH (binary '<name>' not found on PATH otherwise) and tries --version; this type defines no probe command, so a found binary passes.

You should see a dialog titled <connection name> is connected with Connected — verified from the control plane (Connected — verified by your private-network agent when your agent ran the check). Test on the row later writes ok · binary found: <path> — <first line of --version> into Last test. A green result proves the operation named in its detail and nothing more; Audit perms on the row reads what the credential can actually do where the vendor exposes that.

If something fails

The dialog shows Needs a fix, what to fix and the check's own detail; the row is saved either way. Select Edit, correct the field the detail names and save again, or select Retry once a cause outside the form (network, vendor-side permission) is fixed. The verdict strings Test can show (failed · SSRF guard: '<host>' resolves to non-public address …, failed · reachable but auth rejected (HTTP 401/403), failed · HTTP <code> <path>, failed · <field> not configured, failed · <ExceptionName>: …) and what to do about each are in Test a connection and read the failure, and every connection status word is in the status and error reference. A connected datasource the agent never uses is disabled, write-role, allow-listed to other pillars, or of a type platform staff disabled.

Data collected

What the agent gets from a read connection of this type:

An investigation refuses a write through any connection tool, whatever the credential allows (Investigation connections are read-only. This operation was not executed; prepare an incident change using a write connection and obtain approval.); a fix runs through a write-role connection after approval. The exact rule table is under The read/write gate in detail in Connections and remediation access.

Next steps