Analyst Data Sources

The ThinkWork Analyst lets the agent answer questions from your PostgreSQL data — live counts, revenue breakdowns, trend reports — by writing and executing SQL through a read-only query broker. The agent never receives database credentials: every query passes through a ThinkWork-hosted broker that connects with a least-privilege, SELECT-only role, enforces budgets, and writes an audit event for every statement.

Use data sources when you want reports and answers grounded in real database rows, refreshable on a schedule, and safe to expose to an LLM query author.

How it works

Operator registers a data source (internal browse or external form)
    -> ThinkWork verifies the credential is read-only (posture check)
    -> The schema is introspected AS that role and rendered to SCHEMA.md
    -> A connector row is created on the broker route /mcp/analyst/<slug>
    -> Connection folders materialize into every agent workspace
    -> The agent reads SCHEMA.md before writing SQL for that source
    -> Queries execute via the broker: read-only, time-limited, audited

Each registered source is an ordinary MCP server row — it appears on the Datasource MCPs tab of Settings → MCP Servers, shows its source type (Internal or External), cluster instance, database, and schema, and can be enabled or disabled like any other server.

Caution

The schema is a security boundary, not a label. Every PostgreSQL source is scoped to exactly ONE schema, and the source’s read surface is that schema’s tables as they existed at registration (or the last refresh). Tables created afterwards are not readable and not modeled until an operator explicitly refreshes the source — there are no automatic future-table grants.

Registering a data source

Open Settings → MCP Servers, then the database icon in the page header. The dialog offers two paths:

Internal — browse the environment’s own clusters

For databases on clusters your ThinkWork environment owns, registration is a two-dropdown flow with zero credential entry:

1. Cluster — ThinkWork enumerates the environment’s RDS clusters. When there is exactly one, it is pre-selected.
2. Database — the cluster’s databases are listed live. The workspace database itself appears as “Workspace database (built-in)” and routes to the built-in connector provisioning.
3. Schema — the database’s user schemas are listed with their current table counts. Exactly one schema is selected per source; empty schemas are shown but not selectable (so an empty public is explained rather than hidden), and a schema that is already registered is disabled while other schemas in the same database remain available. Two schemas of one database can be registered as two independent sources.
4. Pick a schema, accept or edit the suggested display name and slug, and register.

Behind the scenes ThinkWork provisions a hardened read-only role on that database automatically: LOGIN only, no superuser/createdb/createrole attributes, default_transaction_read_only = on, a 15-second statement timeout, a 30-second idle-transaction timeout, and SELECT granted on the current ordinary tables of the selected schema only — never ALL TABLES and never default privileges for future objects. search_path is narrowed to the selected schema, and the role’s access to every other user schema is revoked. The generated password goes directly to the platform’s secret store and is never displayed or logged.

External — databases outside the environment

For customer- or team-owned PostgreSQL that ThinkWork does not administer, choose External and fill in host, port, database, schema (prefilled public; exact catalog case), DB user, password (write-only), and TLS mode (Verify full is the default; Required is available for hosts without a verifiable certificate chain).

The credential you supply must be a read-only role provisioned by your DBA, scoped to exactly the selected schema’s ordinary tables. Registration connects as that role and refuses to proceed if the role’s effective surface (including role membership and PUBLIC grants) holds any write privilege, can create schemas, can read another user schema, or can read views/materialized/foreign tables — ThinkWork never expands or narrows an external role’s grants, so remediation is always a DBA change. The write barrier is enforced in the database, not in application code.

Tip

The role’s grant surface is also the agent’s visible surface: registration introspects the schema as the supplied role, so tables the role cannot SELECT simply do not exist in the agent’s schema reference.

What registration produces

• A per-source semantic model — the introspected tables and columns are stored and rendered into a SCHEMA.md the agent is instructed to read before writing any SQL against that source. Each source has its own; the agent only loads the schema for the source it is querying, so registering many databases does not pollute the model’s context.
• A born-approved connector row at /mcp/analyst/<slug> with its configuration hash pinned — any later change to the URL requires an explicit operator re-approval.
• Connection folders in every agent workspace, carrying the connection instructions, the schema reference, and a signed policy sidecar with the source’s default query budgets.

Safety posture

Layer	Enforcement
Database role	SELECT-only grants; read-only transactions; statement and idle timeouts set at role level
Broker auth	Every call carries a signed, per-invocation caller context bound to the tenant and delegation — sourced routes reject anything else
Tenant isolation	On the workspace database, row-level security scopes analyst queries to the calling tenant’s rows
Budgets	Signed per-source budgets (queries per day, rows, bytes). Exceeding one blocks further queries and the agent reports the block instead of inventing numbers
Audit	Every executed or rejected statement writes a data.query_executed compliance event with the source, row counts, and outcome
Drift	A scheduled reconciler probes each source (reachability, credential validity, read-only posture, schema drift). A failing probe withholds only that source, with a visible reason

Note

When a budget blocks a query mid-report, the agent renders the affected items as “could not query (budget exceeded)” rather than estimating. Budgets are operator-editable per source.

Refreshing a source after schema changes

New tables never become readable on their own. When tables are added to (or dropped from) the source’s schema, an operator runs Refresh source on the source’s detail page:

1. The source is withheld from the agent for the duration — dispatch stops offering it, and even already-issued broker access is re-authorized against the source’s current state, so a session that started before the refresh cannot keep querying through it.
2. For internal sources, ThinkWork reconciles the reader role’s grants to the schema’s current tables (the credential itself is never rotated). For external sources, ThinkWork models whatever the DBA has granted — the supported sequence is DBA grant first, operator refresh immediately after.
3. The schema reference regenerates, connection folders rematerialize, and an immediate health probe must pass before availability is restored. The confirmation reports exactly which qualified tables were added and removed.

If any step fails, the source stays withheld with a visible, durable failure reason on the detail page (it survives reloads); retrying the refresh converges from where the source identity is stored — no manual artifact cleanup or credential rotation is ever needed.

Note

The scheduled drift probe also detects out-of-band changes: a table granted but not yet modeled (or access reaching outside the source’s schema) withholds the source with an actionable reason until an operator refresh — or a DBA fix — resolves it.

Managing sources

Open a source from the Datasource MCPs list to see its detail page:

• Source type, cluster, database, and schema for at-a-glance identification.
• Refresh source — adopt schema changes (registered sources only; see above).
• Re-approve connection — restamps the approval and re-pins the configuration hash after a deliberate change; optionally rotates the broker token (built-in connector).
• Enable/disable — withdrawal from the agent without deleting the registration.

Registered sources are available to the analyst immediately; asking the agent a question that names the source (or its data) routes queries through it, and several sources can be used in a single conversation.