snowflake v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-snowflake-keypair-jwt

Custody

customer_vault

Injection

header (Authorization)

A bearer token for a dedicated least-privilege Snowflake service user, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. The reviewed token process is Snowflake key-pair authentication: an external deployment process holds the RSA private key, generates the JWT Snowflake documents (RS256; iss = <account_identifier>.<user>.SHA256:<public_key_fingerprint> with account and user uppercased; sub = <account_identifier>.<user>; iat; exp), and writes the complete header value under this reference. Snowflake states the JWT is valid for at most one hour after issue even if a longer exp is set, so renewal is a scheduled external process — the executor injects the stored value verbatim and performs no token lifecycle itself. Revocation is removing or rotating the public key on the user (Snowflake documents key-pair rotation); an expired or unregistered key fails closed. Snowflake OAuth bearer tokens are a documented alternative; if the deployment chooses OAuth instead, the token-type header (X-Snowflake-Authorization-Token-Type: OAUTH) and the refresh path are that deployment's review, not this pack's. Least privilege: the service user's role should carry only the grants needed to read and cancel the statement this pack is bound to — the role's grants are the real access boundary. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• snowflake-account-sql-api (api, internal): https://snowflake-account.invalid/api/v2/statements

The endpoint host 'snowflake-account.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own account host (the documented shape is https://<account_identifier>.snowflakecomputing.com) before enabling, in the endpoints, the resource locator and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. Note that allowlisting the reserved .invalid host does not make an unsubstituted pack safe: an unsubstituted pack fails closed at DNS, but it also has no reviewed destination, so it is not a registration of anything. STATEMENT_HANDLE in the status and cancel endpoint paths is a placeholder the deployment substitutes with a concrete statement handle before enabling: the gate requires the request path to exactly equal the registered path, so a caller cannot name a handle per request and each enablement of these capabilities targets exactly one statement. WHY STATEMENT SUBMISSION IS NOT REGISTERED: POST /api/v2/statements takes the SQL statement text in the request body, and Snowflake documents the SQL API as executing standard queries and most DDL and DML statements. The http connector injects a credential; it does not constrain the request body, so no registration of that endpoint can pin the statement field, and no tier can be honestly claimed for arbitrary caller-supplied SQL — a read-tiered label would not prevent a DML or DDL statement. For the same reason this pack does not register a SHOW-only metadata capability: it would share the submission endpoint and nothing in the registration could pin the body to SHOW statements. If a deployment needs statement execution, that is a separate, purpose-built review (restricting the Snowflake role's grants, statement timeouts, and policy over the capability), not a variant of this pack. Documented exclusions: this pack does not register statement submission (POST /api/v2/statements), multi-statement submission (the multi_statement_count request shape), stored-procedure creation or calls through the API, explicit transaction control requests, or any Snowflake administration surface outside the SQL API. Every call here is a status or cancel call against the one statement handle bound at registration; there is no collection endpoint in this API.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://docs.snowflake.com/en/developer-guide/sql-api/index (retrieved 2026-09-21)
• https://docs.snowflake.com/en/developer-guide/sql-api/reference (retrieved 2026-09-21)
• https://docs.snowflake.com/en/developer-guide/sql-api/authenticating (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.