Skip to main content
Bag of words connects to Snowflake with the standard Snowflake driver, reads the tables, views, and semantic views in the schemas you point it at, and runs SQL against a warehouse you choose. You can authenticate with a username and password, or with key pair (RSA) authentication, which is the option most Snowflake accounts require once MFA is enforced on human users.

​
How it works

Bag of words opens a connection scoped to one database and one or more schema values, using the warehouse you specify for compute (and the role you specify, if any). During indexing it reads:
  • Tables and views from INFORMATION_SCHEMA, including table and column comments where they exist.
  • Semantic views — discovered with SHOW SEMANTIC VIEWS and described with DESC SEMANTIC VIEW. These are exposed to the agent alongside regular tables, and the agent knows to query them through the SEMANTIC_VIEW() function rather than as ordinary tables.
Schema names are normalized to uppercase, matching Snowflake’s INFORMATION_SCHEMA behavior. Queries are read-only.

​
Before you start

  • A Snowflake account identifier, in the organization-account form (for example ABCDEF-GHIJKL). This is the identifier from your account URL, not the full hostname.
  • A warehouse the connecting user can use, and a database to query.
  • The names of the schemas you want indexed. One schema, or several as a comma-separated list.
  • A user for Bag of words to connect as. A dedicated service user with a read-only role is the usual pattern.
  • Network access from the Bag of words host to your Snowflake account. If your account restricts access by network policy, allow the Bag of words egress IP.
Create a dedicated role with USAGE on the warehouse, database, and schemas, plus SELECT on the objects you want available, and grant it to the service user. Then set that role in the Role field so the connection can never see more than intended.

​
Step 1 — Generate a key pair (key-pair auth only)

Skip this step if you are using a username and password. Snowflake key-pair authentication uses a 2048-bit RSA key. You generate the pair yourself, register the public key on the Snowflake user, and paste the private key into Bag of words.
1

Generate the private key

For an encrypted key (recommended — openssl prompts you for a passphrase):
For an unencrypted key:
Either form works. Bag of words accepts a PKCS#8 PEM private key and decrypts it with the passphrase you provide.
2

Derive the public key

If the private key is encrypted, openssl asks for the passphrase here.
3

Register the public key on the Snowflake user

Open rsa_key.pub, and copy the body without the -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- lines and without line breaks. Then, as a user with SECURITYADMIN (or ownership of the target user):
Verify it registered:
4

Keep the private key safe

rsa_key.p8 is a credential. Store it in your secret manager and delete any working copies. Never register the private key with ALTER USER — only the public key goes to Snowflake.

​
Step 2 — Add the connection in Bag of words

Go to Data Sources → Add data source → Snowflake and fill in the form. Then choose an authentication method (below), click Test Connection, and select the tables the agent may use.

​
Authentication modes

Snowflake supports two modes. Both can be used as a shared credential for the whole workspace (system scope) or as a per-user credential where each person supplies their own (user scope).
Straightforward, but not usable for a user on which your account enforces MFA. For service accounts, prefer key pair.
Using per-user credentials on a database connector — every person authenticating as themselves rather than through one shared login — requires an Enterprise license. See Authentication.

​
Troubleshooting

The PEM did not parse. Check that you pasted the whole file including both -----BEGIN/-----END lines, that no lines were reflowed or truncated, and that the passphrase field matches how the key was generated. An encrypted key with a blank passphrase, or an unencrypted key with a passphrase set, both fail here.
The public key registered on the Snowflake user does not match the private key you supplied. Re-derive the public key with openssl rsa -in rsa_key.p8 -pubout, re-run ALTER USER ... SET RSA_PUBLIC_KEY='...', and confirm DESC USER shows a new RSA_PUBLIC_KEY_FP. Also confirm the user field is the Snowflake login name, not an email address, unless they are the same.
The role in use has no USAGE on the database or schema, or no SELECT on the objects. Check the role field — with it blank, the user’s default role applies, which may be more restrictive than you expect. Also confirm the schema names are spelled as they appear in Snowflake; they are matched in uppercase.
The connecting role lacks USAGE on the warehouse named in the warehouse field, or the warehouse is suspended and the role cannot resume it. Grant USAGE (and OPERATE if auto-resume is off).