Register and approve connectors

How to register a company database as a connector, and approve who can query how much of it with grants.

This is how you open a database your company uses so apps can query it.
Do two things — register the connection and approve access — and from then on approved people pull the data from their own apps.

AxHub holds the credentials, so app code never contains the company DB password.

What you need

Company admin rights — only admins can register connectors and approve access
CLI login — the command tool whose commands start with axhub

Registering the connection

axhub connectors google start        # get the browser authorization URL
axhub connectors google finalize     # create the connector after authorizing

Running discovery builds the list of tables and resources the connector holds. You need that list before you can approve a scoped grant.

axhub connectors discover <connector_id> --execute

For <connector_id>, pass the .data[].id (UUID) from axhub connectors list --json. A connector you just registered has no grant yet, so it doesn't appear in axhub connectors mine.

An AxHub app's own DB can be opened as a connector too. Use it when you want others to query the data one app has accumulated.

axhub connectors app-db eligible-apps        # apps that can be opened
axhub connectors app-db create --app <app> --execute

Approving access (grants)

A connector alone gets you nothing: without approval, nobody can query it. You approve by deciding four things in a grant.

What you decide	Detail
Who	subject — a person, a group, an org unit
Which connector	one of the connectors you registered
Which action set	preset — read-only, for instance
(Optional) Which table scope	with a scope set, everything outside it is unreachable

Setting a scope blocks free-form SQL. A scoped grant can't run arbitrary queries (403 scope_requires_target), and reaching outside the scope gives 403 scope_out_of_range. It's the switch between opening things wide and locking them down.

Confirm the grant landed from the account you approved.

axhub authz grants mine                    # their active grants
axhub connectors mine                      # connectors they can query (name · engine)
axhub connectors mine --json               # the same list — .data[].id is the connector ID (UUID)
axhub connectors resources <connector_id>  # that connector's resource tree

For <connector_id>, pass the .data[].id (UUID) from axhub connectors mine --json — not the name. The human-readable axhub connectors mine output doesn't show IDs. From an admin account, axhub connectors resources <connector_id> --admin reads any connector regardless of grants — pass it the .data[].id from axhub connectors list --json instead.

A connector without a grant doesn't even appear in the list. When a developer says "I can't see the connector," approval hasn't happened yet.

Locking down rows and columns (access policies)

A grant decides "which tables". An access policy goes further and decides "which rows, which columns" inside the same table.
For example, "the sales team sees only rows for their region in the orders table, with the contact column hidden" is one policy.

Creating and attaching

Create policies in the console under Connectors & Policies › Access policies › Data scope (rows & columns).
Attach them on the connector's Permissions tab. When granting new access, pick them in the add-member dialog; for an existing grant, use the Edit policies button on its row.

The CLI only has read commands (axhub authz policies list · show). Creating and editing happen in the console.

The two rules a policy can hold

One policy holds a row filter and a column policy. Either one alone is fine.

A row filter is a single condition of the form column operator value. Only seven operators work: = != < <= > >= in. Subqueries, functions, and combined conditions are not supported. To add more conditions, attach more policies. Attached policies all combine with AND.

A column policy is one of three modes.

Mode	What it does
`allow`	Only the listed columns show. An empty list allows everything
`deny`	Removes the column from responses
`mask`	Hides values as `***`

Always set the target table when creating a policy. A policy without a target applies to every query on that grant, so queries on other tables without the filter column fail with column "..." does not exist (fail-closed).

Behavior worth knowing

A row filter works by wrapping your query, so three behaviors are worth knowing.

The filter column must be in the SELECT list. SELECT * is always safe. With multiple policies, every policy's filter column is required; missing one fails with column not found.
LIMIT and ORDER BY run before the filter. Requesting LIMIT 10 can return fewer rows than that after filtering.
Masking (***) only hides the display. Sorting, comparing, and aggregating on a masked column still use the real values. To block the value itself, use deny.

Three axes narrow together

When the preset, the grant scope, and access policies apply at once, they all combine with AND. A policy never opens more than the grant allows.

Axis	What it decides
preset	which actions (SELECT and so on)
grant scope	which tables
access policy	which rows and columns in those tables

Queries covered by a row filter reject UPDATE and DELETE, because they could touch rows outside the filter. And a policy attached to a grant can't be deleted ("an active grant is using it"). Detach it from the grant first.

How queries stay controlled

After approval, three layers of protection sit on every query.

Safeguard	What it does
Allowed actions only	Only actions the grant's preset allows run at all. The default read-only preset lets through read queries like `SELECT`, `WITH`, and `EXPLAIN`
Safe queries	Values travel separately from the SQL, and every query is written to the audit log along with whether it was allowed or denied
Temporary sessions	Queries only run inside a gateway session, and sessions close automatically after 8 hours

You've succeeded when

axhub connectors mine shows the connector from the account you approved. From there, each person queries it from their own app following Connect company data with a connector.

CLI reference

Full command listing — connectors, sessions, safe queries, grants