Skip to content
Help Center Back to AgenticObjects

Connections

Connect AgenticObjects to your databases and cubes, test each connection end to end, and keep secrets write-only.

Console 5 min read Updated

Connections are the doors your data comes through. Each one tells AgenticObjects where a database or cube lives and how to reach it, and every data model reads through exactly one of them. This page is where you add those doors, test them, and see at a glance whether each one is working.

What this screen is for

An agent never reaches your data directly. It asks a question of a data model, and the model reads through a connection. Setting up connections well — read-only accounts, the right workload profile, a tested path — is what makes every answer downstream safe and fast.

Relational databases (MariaDB and SQL Server) are reached with a host, a database and a read-only account. SSAS Tabular cubes are reached through the Microsoft SSAS Gateway Service, which you run on your own server: your cube credentials stay there, and AgenticObjects holds only the pairing key that proves it is talking to your gateway service.

What you see

  1. Connections with a workspace-wide badge, and the line Guardrails · read-only enforcement.
  2. Add connection — opens the form for a new connection.
  3. The connection list — one row per connection: its name, a badge for the Driver, a badge for the mode of the Microsoft SSAS Gateway Service on cube connections, and the last test result — ✓ or ✗ with tested 2 hours ago, or Never tested. Technical detail expands to the address the connection uses.
  4. Workload profile — the column showing whether a source is a warehouse, a transactional system or a replica.
  5. Test connection — on every row, runs a live test and shows the result in a card below the list.

How to …

Add a database connection

  1. Press Add connection.
  2. Choose the Workspace — the workspace selected in the Console comes preselected, and only workspaces where you may create a connection are listed. Every data model and agent of that workspace can use the connection, whatever their project. Then enter a Connection name, and pick MariaDB or SQL Server as the Driver. The Port fills in with the driver's default.
  3. Enter the Host, the Database and the Database user. Use an account that can only read.
  4. Enter the Password. You can show it while typing; once saved it is never shown again.
  5. Choose the Workload profile and press Save.

Add an SSAS Tabular cube through the Microsoft SSAS Gateway Service

  1. Install and run the Microsoft SSAS Gateway Service on a server that can reach your cube. Its setup wizard shows you a pairing key.
  2. Press Add connection, choose the Workspace, and choose SSAS Tabular as the Driver.
  3. Pick the Microsoft SSAS Gateway Service mode: Direct (HTTPS + fingerprint pinning) or Cloudflared tunnel.
  4. Enter the Microsoft SSAS Gateway Service address (the gateway service, not the cube server), the SSAS model name and the Pairing key — the five dashed blocks the wizard shows.
  5. Press Save. No cube password is asked for, because it never leaves your server.

Test a connection

  1. Press Test connection on the row.
  2. For a database, read three lines: Connectivity, Read-only verification and Server version.
  3. For a cube, read the two stages in order: Microsoft SSAS Gateway Service reachable + pairing key, then Microsoft SSAS Gateway Service → SSAS. When both pass, the card names the Model and its number of Measures.
  4. The result is recorded, and the row's badge shows it the next time the page loads.

How to read it

  • A ✓ badge is the last test, with its time. Hover over it for the exact moment. Never tested means nobody has run a test yet.
  • ⚠ on Read-only verification means the account can do more than read. On MariaDB queries are still held to read-only statements and the database itself opens every session read-only, so a read-only account is the recommended setup. On SQL Server there is no such second safeguard: the read-only statement check is the only barrier, so a SQL Server connection must use an account that can only read (for example a login that holds only the db_datareader role). A ⚠ on a SQL Server connection means: replace the account before agents use it.
  • The cube test runs in two stages, the Microsoft SSAS Gateway Service first. If the first stage fails, the problem is between AgenticObjects and your gateway service — the service, the port or tunnel, or the pairing key. If only the second fails, the gateway service is fine and the message points at the cube server, model name or permissions.
  • A fingerprint message is a security signal. In Direct mode the certificate of the Microsoft SSAS Gateway Service is recorded on the first successful test and checked on every later one. If it changed on purpose, edit the connection to pin it again; if not, investigate.

Good to know

  • Secrets are write-only. A password or pairing key is stored one way and masked, and no screen can read it back.
  • Your cube credentials stay on your own server. AgenticObjects reaches the cube only through your Microsoft SSAS Gateway Service, authenticated by the pairing key.
  • Every query runs as a read-only statement, whatever the account's rights — and the connection test tells you when the account itself could do more.
  • In Cloudflared tunnel mode traffic passes through Cloudflare. For data with residency requirements, the form reminds you to check the mode against your contract.
  • The driver list offers exactly the sources the product can serve: MariaDB, SQL Server and SSAS Tabular.