Databases

Create a read-only user. In mongosh, against the database the tickets are about:

db.getSiblingDB("admin").createUser({
  user: "triagic",
  pwd: "…",
  roles: [{ role: "read", db: "orders" }]
})

Note which database the user is defined in: that is the authSource, and it's the commonest cause of a rejected login.

Assemble the connection string, including that auth source: mongodb+srv://triagic:…@cluster0.abc.mongodb.net/orders?authSource=admin. For Atlas, add the machine's egress IP to the cluster's IP access list first.

Put TLS in the URI too. There are no separate certificate fields, because the driver reads all of it from the connection string:

Paths are on the machine running Triagic, not the portal's host.

Fill the form.

Verify. The desktop proves the credential with list-databases before reporting running.

Create a read-only role.

CREATE ROLE triagic LOGIN PASSWORD '…';
GRANT CONNECT ON DATABASE billing TO triagic;
GRANT USAGE ON SCHEMA public TO triagic;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO triagic;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO triagic;

The last line is the one people forget: without it, tables created later are invisible.

Put certificates in the URL. There are no separate certificate fields: the driver reads these from the connection string and loads each file from disk when it connects.

Paths are on the machine running Triagic, not the portal's host.

Know that this driver reads sslmode more strictly than psql does.

Without uselibpqcompat=true in the URL, it treats sslmode=prefer, require and verify-ca as aliases for verify-full: all three verify the certificate chain and the hostname. libpq's require means "encrypt, don't verify", so a URL copied out of an RDS or Supabase console that connects fine with psql can fail here on certificate verification, with nothing pointing at the difference.

Two ways out: add uselibpqcompat=true to get libpq's meanings back, or turn off Verify TLS certificate, which replaces the sslmode entirely.

Fill the form.

Verify. Health check is SELECT 1.

Create a read-only user. The user's grants decide which databases and tables the agent can see at all: information_schema only shows a user what they hold a privilege on.

CREATE USER 'triagic'@'%' IDENTIFIED BY '…';
GRANT SELECT ON shop.* TO 'triagic'@'%';

Repeat the GRANT for each database the agent should reach. MySQL grants are per host, so 'triagic'@'%' and 'triagic'@'localhost' are different users.

Decide how much the connection should check the server's certificate.

Leaving TLS mode on Driver default encrypts the connection whenever the server offers TLS, and does not check the certificate. Fine inside a private network, not enough across one. Required also checks the certificate, against the trust store of the machine running Triagic.

For a server whose certificate comes from a private CA, put that CA's bundle on the machine and choose Verify CA, or Verify CA and hostname if the name you connect to is the name on the certificate. Those two modes are the only ones that read CA certificate path; under Required it is ignored. Checking the hostname needs a hostname in Host: with a bare IP address the name check is skipped.

Fill the form. This one takes the parts, not a URL.

Verify. Health check is a list_databases call. It connects, authenticates and reads information_schema, so a wrong password, an unreachable host and a user with no grants all fail it.

Create a restricted ACL user so the guarantee holds server-side too, not only in the allowlist:

ACL SETUSER triagic on >… ~* +@read +@keyspace

+@read grants every read command and nothing else; +@keyspace adds SCAN, TYPE and DBSIZE, which the tools and the health check use. On a managed Redis without ACLs, the shared default user works; the allowlist is then the only boundary.

Fill the form. This one takes the parts, not a URL.

Verify. Health check is dbsize, a single DBSIZE, cheap and read-only. It fails on a wrong password where merely starting the server would not.

Create a read-only user.

CREATE USER triagic IDENTIFIED BY '…' SETTINGS readonly = 1;
GRANT SELECT ON events.* TO triagic;

Optionally create a role, and name it on the form.

A role is applied with SET ROLE before every query, which makes it a per-statement bound rather than a description of the account. That is the strongest read-only control ClickHouse offers here. It holds even where the user's own grants are wider, and you can tighten it later without touching the user.

CREATE ROLE readonly_analyst;
GRANT SELECT ON events.* TO readonly_analyst;
GRANT readonly_analyst TO triagic;

For a private CA, install its certificate in this machine's OS trust store. There is no CA path to set on the form: the server reads the operating system's trust store directly, so a certificate installed there is honoured and one sitting in a file is not.

Fill the form.

Verify. Health check is list_databases.

Create a role that can only read, and a service user for it.

CREATE ROLE triagic_reader;
GRANT USAGE ON WAREHOUSE analytics_wh TO ROLE triagic_reader;
GRANT USAGE ON DATABASE prod TO ROLE triagic_reader;
GRANT USAGE ON ALL SCHEMAS IN DATABASE prod TO ROLE triagic_reader;
GRANT SELECT ON ALL TABLES IN DATABASE prod TO ROLE triagic_reader;
CREATE USER triagic TYPE = SERVICE DEFAULT_ROLE = triagic_reader;
GRANT ROLE triagic_reader TO USER triagic;

Put triagic_reader in the Role field as well. The form sends it with every statement, so the queries run read-only even if someone later changes the user's default role.

Pick how it signs in. An account password does not work: Snowflake's SQL API takes a token or a key pair only.

Programmatic access token. Create one for the user under Settings → Authentication → Programmatic access tokens, scoped to triagic_reader. Snowflake only accepts a token from a user covered by a network policy, even though creating the token needs none:

CREATE NETWORK POLICY triagic_np ALLOWED_IP_LIST = ('0.0.0.0/0');
ALTER USER triagic SET NETWORK_POLICY = triagic_np;

Scope ALLOWED_IP_LIST to the egress range of the machine running Triagic where you can.

Key pair. No network policy needed. Generate a PKCS#8 key, register the public half, and point the form at the private half:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_rsa_key.p8 -nocrypt
openssl rsa -in snowflake_rsa_key.p8 -pubout -out snowflake_rsa_key.pub

ALTER USER triagic SET RSA_PUBLIC_KEY = '<contents of snowflake_rsa_key.pub without the BEGIN and END lines>';

Fill the form.

Verify. Health check is list_databases.

Create a service account with exactly two roles: BigQuery Data Viewer (roles/bigquery.dataViewer) to read, and BigQuery Job User (roles/bigquery.jobUser) to run queries. Nothing else.

Download its JSON key and place it on the machine that runs Triagic, at an absolute path readable by the desktop app, e.g. /opt/triagic/bigquery-sa.json. Skip this if that machine already has Application Default Credentials configured.

For impersonation or workload-identity federation, switch to Application Default Credentials.

The key-file path accepts a plain service-account key and nothing else. It's read by a loader that refuses impersonated_service_account and external_account JSON outright. If your organization issues either of those, choose Application Default Credentials and give the same file under Credentials file path, where it is read by the general Google credentials loader that understands all three formats.

Leaving that path blank uses whatever gcloud auth application-default login already left on the machine.

Decide which datasets the agent may see. Naming them is the one least-privilege control this server offers that does not mean minting a narrower service account: nothing outside the list is visible, whatever the account could otherwise reach. Leave it blank and every dataset in the project is exposed.

Fill the form.

Verify. Health check is list-tables.

Create an IAM user with AmazonDynamoDBReadOnlyAccess, or a policy granting dynamodb:List*, dynamodb:Describe*, dynamodb:Query, dynamodb:Scan and dynamodb:GetItem on the tables you need. Generate an access key for it.

Or point at a named profile instead. Choosing Named profile reads the credential from the ~/.aws/config of the machine running Triagic, which is the only way to reach assume-role, IAM Identity Center (SSO), credential_process or MFA. See AWS CloudWatch for the profile shapes.

This server also injects --profile <name> into every CLI command it generates, so the profile is what the command itself runs as, not only what the SDK signs with.

Fill the form.

Verify. No health check runs for this one: the underlying tool returns AWS errors as successful results with an error field, so a check could not tell a working credential from a denied one. It is start-checked only; the first real tool call is what proves the credential.

Generate a personal access token at supabase.com/dashboard/account/tokens. It inherits its owner's organization access, so create it from an account that is a member of the organization owning the project, ideally a dedicated one.

The project's anon and service_role keys are a different credential and are not accepted here.

Find the project ref. Project Settings → General → Reference ID, a 20-character string. It is also the subdomain of the project's …supabase.co URL.

Fill the form.

Verify. Health check is list_tables, which runs real SQL through the platform API, so it fails on both a bad token and a project the token cannot reach.

Create an API key at console.neon.tech → Account settings → API keys. An organization API key scopes access to that organization's projects. Prefer it over a personal key, which sees everything the account can.

A database password or connection string is a different credential and is not accepted here.

Optionally find the project ID. Project Settings → General → Project ID, e.g. wispy-salad-12345678. Setting it scopes the session to that one project; leaving it blank reaches every project the key can see.

Fill the form.

Verify. Health check is list_projects, a cheap authenticated read that fails on a bad or revoked key.